如何在Openshift中让Router-Pod独占Router节点
概念
什么是Router Pod?
Router Pod是Openshift中管理外部流量访问集群服务的重要的入口,它是通过一个haproxy的Pod实现的。由于Router Pod的独特性,几乎所有的流量都过Router中的Pod代理到真正的服务,所以它是一个非常非常重要的服务。
什么是Router节点
因为集群中的Router Pod数量是有限的,外部流量通过负载均衡器到达Router的Pod,所以对于Router Pod必须固定在负载均衡器下的节点上。这些运行Router Pod的节点,我们叫做Router节点。它有两个特点:
运行default/router的pod;
被外部负载均衡器监听
为什么需要让Router Pod独占Router节点上几乎所有的外部访问集群服务的流量都通过Router Pod代理,所以它是非常重要。在正式使用时,需要对它进行保护。让它独占节点,防止其它Pod抢占Router Pod的资源,以确保集群下服务的可用性。
具体实施Router Pod独占绑定Router节点
Router节点上添加label1oc label node ...
应用日志方案
原生方式
DaemonSet方式
Sidecar方式
集日志类型
标准输出
标准输出
文件
部署运维
低,原生支持
一般,需维护DaemonSet
较高,需要为每个容器采集日志的
日志分类存储
无法实现
可通过容器、路径映射实现
每个Pod可单独配置,灵活性高
支持集群规模
本地存储无限制,若使用syslog/fluentd会有单点限制
取决于配置数
无限制
资源占用
低,docker引擎提供
较低,每个节点运行一个容器
较高,每个Pod运行一个容器
查询便捷性
低,grep原始日志
较高,自定义查询、统计
高,根据业务特点定制
适用场景
测试、POC等非生产环境
日志分类明确的集群
大型、混合型集群
快速使用SonarQube对应用进行静态代码扫描
1、启动SonarQube服务
12$ mkdir -p /sonar/{conf,data,extensions}$ docker run -v /sonar/conf:/opt/sonarqube/conf -v /sonar/data:/opt/sonarqube/data -v /sonar/extensions:/opt/sonarqube/extensions -p 9000:9000 xhuaustc/sonarqube:7.9.1
本地目录为~/Downloads/sonar/2、登录SonarQube服务端:http://127.0.0.1:9000/projects,登录用户名:admin,密码:admin3、创建新的项目,获得projectKey与token值4、下载对应版本的sonar scanner工具:SonarScanner下载地址5、请在代码目录中执行扫描工具
123456/xx/bin/sonar-scanner \ -Dsonar.projectKey=test \ -Dsonar.sources=. \ -Dsonar.h ...
技术中台
金融机构中台战略之路
在传统金融机构体系中,系统往往由各个项目组独立建设,每个机构中有成百上千套复杂的系统,它们相互调用,形成复杂的网状结构,很难进行管理。随着银行数字化转型的深入,大量业务以互联网的形式向用户开放,对系统高并发、大数据量、强一致性等需求越来越高。与此同时,为了满足用户多样化的需求,银行必须从以业务为中心向以人为中心转变,并做出快速响应。中台建设正是目前解决这些问题的新兴平台型企业架构。
企业中台为业务而生,快速敏捷地响应业务变化,以服务的形式为业务提供支撑,服务接入层以统一的路由适配转发。在整个技术构架上需要考虑可拓展性、敏捷性、轻量化,并注重与前台的交互,灵活地通过服务编排实现应用功能,满足前台需求。因此中台融合分布式、微服务、容器云、DevOps、大数据处理及高可用高性能高并发架构,遵循“高内聚、松耦合”设计原则。业务中台需要微服务、云原生、分布式事务体系支撑,并设计业务模型和微服务边界,最终形成业务单元;数据中台汇聚企业内外割裂的数据,并通过统一治理、建模加工,消除数据孤岛,实现数据资产化,为企业提供客户画像、商品智能推荐、业务实时监控,达到数据驱动业务能力。中 ...
数据库写测试
先出结果数据库Mysql 5.7数据
NetApp
Ceph
NFS-SSD
NFS-SAS
HOST PATH
写(qtps)
33333
888
20000
3000
延时(us)
1029
40488
1184
NetApp
12345678910111213141516171819202018-06-27 17:56:45 ======================== mysql_test ========================2018-06-27 17:56:45 SQL01 exe=5000 fail=0 row=5000 ela=5180 ms avg=1036 us2018-06-27 17:56:45 SQL01 1 ms exec= 2853, ela= 2530 ms, avg= 886 us, pct= 57, 572018-06-27 17:56:45 SQL01 2 ms exec= 2122, ela= 2443 ms, avg= 1151 u ...
某股份制银行:容器云平台建设实践
容器云平台建设行业背景
当前银行业普遍的共识之一是要以金融科技为依托,通过科技创新引领银行的转型升级。云计算、大数据、人工智能成为各银行科技部门重点的投资建设领域。云计算领域的建设主要集中在IaaS和PaaS,目标是降低数据中心成本的同时,为上层应用的创新、快速迭代和稳定运行提供有效支撑。传统的IaaS调度的是虚拟机或者物理机,粒度较大,相对传统的虚拟化技术,在资源使用率、灵活性和弹性方面提升度并不高。依托传统IaaS建设而成的PaaS,也会面临同样的问题。而容器技术恰好可以比较好的解决这些问题,并且在微服务、DevOps、分布式等方面天生具备优势,因此成为数据中心新一代云基础架构的选择。
建设容器云平台的意义
1.让应用真正意义上弹性扩缩容
传统方式下应用和基础环境资源(计算、网络、存储、监控等) 是紧耦合的关系,应用的扩容、缩容意味着基础环境资源的扩容和缩容。基础环境的扩、缩容耗时会非常长,因为涉及到非常多需要人工介入的环境,而且都是串行的,比如创建主机、分配存储、网络接入、操作系统安装、网络访问关系开通、应用部署、监控审计部署、接入负载均衡等等。整个流程走下来通常需要数天到数周的 ...
混沌工程详细介绍——Netflix持续交付实践探寻
本篇来自于本人6月-7月参加的“DevOps案例深度研究”活动Netflix案例研究的第五部分,详细介绍了Netflix的混沌工程。经过一个月的战斗,四个版本的迭代,Netflix战队最后交付了让所有人满意的战果,并获得了全场唯一的案例研究最佳小组奖杯。感谢我们的战友,还有指导老师,姚冬老师和徐磊老师。
Netflix实施混沌工程的背景
08年Netflix决定把它的业务迁移到aws上,从自身运维的角度考虑,它有很多担忧的地方。
很长时间内有两套系统在同时运行,运维的复杂度更高了。
NetFlix的用户量已经达到了1亿,对应用稳定性依赖很高,如果出现故障对用户的影响非常大,甚至是致命的。
它的业务不断复杂,引入微服务架构,对应用的高可用性要求越来越高。
生产环境非常复杂,是多样性的,很难在测试环境中完全模拟生产的状态。
因此Netflix决心探索一种在生产环境验证应用高可用性的一种方法,这就是现在大家所熟知的混沌工程。
混乱工程的发展
2010年,捣乱猴子诞生
2011年,猴子军团,有了更多场景下的工具集
2012年,开源了捣乱猴子的代码,建立社区,影响了越来越多的 ...
查看Java应用状态
jps查看123$ jps16 jar547 Jps
jmap -heap1$ jmap -heap 16
jstat -class pid1$ jstat -class 16
玩转Openshift中Pod调度
大部分情况下,Openshift中的Pod只是容器的载体,通过Deployment、DaemonSet、RC、Job、Cronjob等对象来完成一组Pod的调度与自动控制功能。Pod调度也是由Scheduler组件完成的。
Deployment/RC:全自动调度
Deployment/RC主要是自动部署应用的多个副本,并持续监控,以维持副本的数量。默认是使用系统Master的Scheduler经过一系列算法计算来调度,用户无法干预调度过程与结果。
12345678910111213141516171819202122apiVersion: apps/v1kind: Deploymentmetadata: name: nginx labels: app: nginxspec: replicas: 1 template: metadata: name: nginx labels: app: nginx spec: containers: - name: nginx ...
白化Kubernetes网络
引自:http://www.10tiao.com/html/217/201708/2649694873/1.html
容器的网络是在CaaS集群中无法避免的话题,作为当下最主流的一种容器集群解决方案,Kubernetes对网络进行了合理的抽象,并采用了开放的CNI模型。面对各种容器网络实现,他们有什么不同,应该如何选择?本文将带大家回顾Kubernetes各种主流网络方案的发展历程,并透过现象清本质,用形象的例子展示Weave、Flannel、Calico和Romana等网络解决方案背后的原理。
这次讲一讲容器集群中的网络。其实不同的容器集群解决方案,在网络方面的核心原理都是相似的,只不过这次我们将以Kubernetes为线索,来窥斑见豹的一睹容器网络的发展过程。
我是来自ThoughtWorks的林帆,我们从Docker的0.x版本开始就在对容器的应用场景进行探索,积累了一线的容器运用经验。这次分享会用简洁易懂的方式告诉大家我们对容器网络方面的一些知识归纳。
初入容器集群的人往往会发现,和单节点的容器运用相比,容器的网络和存储是两个让人望而却步的领域。在这些领域里,存在大量的 ...