容器化场景中性能调优面对哪些挑战?

4回答

zzhengleizzhenglei  技术经理 , 太平洋保险
于爽yinxinzhuhaiqiang赞同了此回答
一共会有六个方面的难点,如下:1.    VM级别的调优方式在容器中实现难度较大在VM级别我们看到的即是所有,网络栈是完整暴漏在我们面前的,CPU、内存、磁盘等也是完全没有限制的。性能调优老司机的工具箱安个遍,诊断流程走一趟基本问题就查个八九不离十了,但是在容器中,很多时候...显示全部

一共会有六个方面的难点,如下:
1.    VM级别的调优方式在容器中实现难度较大
在VM级别我们看到的即是所有,网络栈是完整暴漏在我们面前的,CPU、内存、磁盘等也是完全没有限制的。性能调优老司机的工具箱安个遍,诊断流程走一趟基本问题就查个八九不离十了,但是在容器中,很多时候,都是默认不自带诊断、调优工具的,很多时候连ping或者telnet等等基础命令都没有,这导致大部分情况下我们需要以黑盒的方式看待一个容器,所有的症状只能从VM层的链路来看。但是我们知道容器通过namespace的隔离,具备完整网络栈,CPU、内存等通过隔离,只能使用limit的资源,如果将容器当做黑盒会导致很多时候问题症状难以快速发现。排查问题的方式变难了。

2.    容器化后应用的链路边长导致排查问题成本变大
容器的场景带来很多酷炫的功能和技术,比如故障自动恢复,弹性伸缩,跨主机调度等等,但是这一切的代价是需要依赖容器化的架构,比如Kubernetes网络中需要FullNat的方式完成两层网络的转发等等,这会给排查问题带来更复杂的问题,当你不清楚编排引擎的架构实现原理的时候,很难将问题指向这些平时不会遇到的场景。例如上面这个例子中,FullNat的好处是降低了网络整体方案的复杂性,但是也引入了一些NAT场景下的常见问题,比如短连接场景中的SNAT五元组重合导致包重传的问题等等。排查问题的方位变大了。

3.    不完整隔离带来的调优复杂性
容器技术本质是一种虚拟化技术,提到虚拟化技术就离不开隔离性,虽然我们平时并不需要去考虑隔离的安全性问题,但是当遇到性能调优的时候,我们发现内核的共享使我们不得不面对的是一个更复杂的场景。举个,由于内核的共享, 系统的proc是以只读的方式进行挂载的,这就意味着系统内核参数的调整会带来的宿主机级别的变更。在性能调优领域经常有人提到C10K或者C100K等等类似的问题,这些问题难免涉及到内核参数的调整,但是越特定的场景调优的参数越不同,有时会有彼之蜜糖,我之苦的效果。因此同一个节点上的不同容器会出现非常离奇的现象。

4.    不同语言对cgroup的支持
这个问题其实大多数场景下我们是不去考虑的,但是在此我们把他列在第四位的原因是期望能够引起大家的重视。一次在和Oracel Java基础库的负责同学聊天中了解到Java针对与Cgroup的场景做了大量的优化,而且时至今日,在Java的标准库中对于Cgroup的支持还是不完全的,好在这点在大多数的场景中是没有任何影响,也就不过多的讨论。排查问题的脑洞更大了。

5.    网络方案不同带来的特定场景的先天缺欠
提到容器架构我们逃不掉的话题是网络、存储和调度,网络往往是一个容器架构好坏的最根本的评判标准,不同的网络方案也会有不同的实现方式与问题。比如在阿里云的Kubernetes中我们使用了Flannel的CNI插件实现的网络方案,标准Flannel支持的Vxlan的网络方案,Docker的Overlay的macVlan,ipvlan的方案等等。这些不同的网络方案无一例外都是分布式的网络方案而存储的数据都会存放在一个中心存储中,因此越大型的集群对网络中心存储的压力也就越大,出错的可能性就越大。此外跨宿主机的二层网络很多都会通过一些封包解包的方式来进行数据传输,这种方式难免会增加额外的系能损耗,这是一种先天的缺欠,并不是调优能够解决的问题。有的时候排查出问题也只能绕过而不是调优。

6.    镜像化的系统环境、语言版本的差异
应用容器化是一个需要特别值得注意的问题,很多公司其实并没有严格的配管流程,比如系统依赖的内核版本、语言的小版本等等,进行应用容器化很多时候都是选择一个大概的版本,这会带来很多语言层级的BUG,比如PHP7.0中php-fpm的诡异行为,而这个现象在客户原本的5.6版本上已经修复过了。环境的问题本是一个严肃的问题,需要严格个管控,但是当遇到了容器,很多时候我们会分不清哪些不经意的行为会带来严重的问题。警惕性因为容器镜像能够正常启动而降低。

收起
 2020-02-17
浏览563
于爽于爽  产品经理 , 青云QingCloud
如果是在一层虚拟化之上构建的容器平台,而虚拟化节点之间如果是跨物理机的,那跨hyper之间的服务访问性能downgrade是比较明显的,这个时候,尽量选择虚拟化厂商/平台提供的网络直通cni解决方案,可以带来一定的改善。 另外容器平台天然需要分布式存储,当然local volume能满足一些...显示全部

如果是在一层虚拟化之上构建的容器平台,而虚拟化节点之间如果是跨物理机的,那跨hyper之间的服务访问性能downgrade是比较明显的,这个时候,尽量选择虚拟化厂商/平台提供的网络直通cni解决方案,可以带来一定的改善。

另外容器平台天然需要分布式存储,当然local volume能满足一些场景的需求,但随着各种服务应用向容器平台迁移,分布式存储是个逃不掉的话题,有些客户选择利旧使用NAS通过nfs对接,但测出来的IO数据相较于分布式块存储还是有一定差距的。

收起
 2020-03-18
浏览64
lewolilewoli  系统架构师 , qingcloud
容器场景和VM模式的最大差异在于Pod的弹性,所有的POD的地址都是随机的,不像传统监控面对的都是稳定的对象,更多是对应用的端到端的性能进行监控,定位瓶颈,从而确定性能调优的重点。在容器化场景中需要APM来作为调优的基础工具。如可以采用skywalking等开源软件,以及Dynatrace等...显示全部

容器场景和VM模式的最大差异在于Pod的弹性,所有的POD的地址都是随机的,不像传统监控面对的都是稳定的对象,更多是对应用的端到端的性能进行监控,定位瓶颈,从而确定性能调优的重点。在容器化场景中需要APM来作为调优的基础工具。如可以采用skywalking等开源软件,以及Dynatrace等商业软件来进行。

收起
 2020-03-13
浏览104
匿名用户匿名用户
IO速度显示全部

IO速度

收起
 2020-02-14
浏览581

提问者

乃伊组特系统管理员, 平安银行

问题状态

  • 发布时间:2020-02-14
  • 关注会员:5 人
  • 问题浏览:2262
  • 最近回答:2020-03-18