前言
性能调优的“望闻问切”
容器化性能调优的难点
- VM级别的调优方式在容器中实现难度较大
在VM级别我们看到的即是所有,网络栈是完整暴漏在我们面前的,CPU、内存、磁盘等也是完全没有限制的。性能调优老司机的工具箱安个遍,诊断流程走一趟基本问题就查个八九不离十了,但是在容器中,很多时候,都是默认不自带诊断、调优工具的,很多时候连ping或者telnet等等基础命令都没有,这导致大部分情况下我们需要以黑盒的方式看待一个容器,所有的症状只能从VM层的链路来看。但是我们知道容器通过namespace的隔离,具备完整网络栈,CPU、内存等通过隔离,只能使用limit的资源,如果将容器当做黑盒会导致很多时候问题症状难以快速发现。排查问题的方式变难了。 - 容器化后应用的链路边长导致排查问题成本变大
容器的场景带来很多酷炫的功能和技术,比如故障自动恢复,弹性伸缩,跨主机调度等等,但是这一切的代价是需要依赖容器化的架构,比如Kubernetes网络中需要FullNat的方式完成两层网络的转发等等,这会给排查问题带来更复杂的问题,当你不清楚编排引擎的架构实现原理的时候,很难将问题指向这些平时不会遇到的场景。例如上面这个例子中,FullNat的好处是降低了网络整体方案的复杂性,但是也引入了一些NAT场景下的常见问题,比如短连接场景中的SNAT五元组重合导致包重传的问题等等。排查问题的方位变大了。 - 不完整隔离带来的调优复杂性
容器技术本质是一种虚拟化技术,提到虚拟化技术就离不开隔离性,虽然我们平时并不需要去考虑隔离的安全性问题,但是当遇到性能调优的时候,我们发现内核的共享使我们不得不面对的是一个更复杂的场景。举个,由于内核的共享, 系统的proc是以只读的方式进行挂载的,这就意味着系统内核参数的调整会带来的宿主机级别的变更。在性能调优领域经常有人提到C10K或者C100K等等类似的问题,这些问题难免涉及到内核参数的调整,但是越特定的场景调优的参数越不同,有时会有彼之蜜糖,我之毒药的效果。因此同一个节点上的不同容器会出现非常离奇的现象。 - 不同语言对cgroup的支持
这个问题其实大多数场景下我们是不去考虑的,但是在此我们把他列在第四位的原因是期望能够引起大家的重视。一次在和Oracel Java基础库的负责同学聊天中了解到Java针对与Cgroup的场景做了大量的优化,而且时至今日,在Java的标准库中对于Cgroup的支持还是不完全的,好在这点在大多数的场景中是没有任何影响,也就不过多的讨论。排查问题的脑洞更大了。 - 网络方案不同带来的特定场景的先天缺欠
提到容器架构我们逃不掉的话题是网络、存储和调度,网络往往是一个容器架构好坏的最根本的评判标准,不同的网络方案也会有不同的实现方式与问题。比如在阿里云的Kubernetes中我们使用了Flannel的CNI插件实现的网络方案,标准Flannel支持的Vxlan的网络方案,Docker的Overlay的macVlan,ipvlan的方案等等。这些不同的网络方案无一例外都是分布式的网络方案而存储的数据都会存放在一个中心存储中,因此越大型的集群对网络中心存储的压力也就越大,出错的可能性就越大。此外跨宿主机的二层网络很多都会通过一些封包解包的方式来进行数据传输,这种方式难免会增加额外的系能损耗,这是一种先天的缺欠,并不是调优能够解决的问题。有的时候排查出问题也只能绕过而不是调优。
最后
这篇文章中我们主要讨论了基础的性能调优的方式以及容器化场景中性能调优的难点,在下篇文章中我们会来套路下不同的性能瓶颈现象对应的诊断和调优方法。