稳定性、效率和成本

《互联网企业容器技术实践》第3章美丽联合容器云实践，本章首先介绍美丽联合集团基于Kubernetes和Docker容器云平台的技术方案、架构演进的三个阶段，以及在稳定性、效率和成本三方面所做的工作；然后介绍关键技术方案及创新点；最后谈一下个人三年多来的体会、思考和解决过的问题，以及分享一些优秀开源工具和项目。本节为大家介绍稳定性、效率和成本。

3.1.4 稳定性、效率和成本

1. 稳定性

稳定性对于容器云这样的基础平台而言是最重要的。面对各种来自硬件故障、软件问题、安全漏洞、人为事故等不同方面的挑战，如图3-18所示。通过努力，我们的私有云平台经历了十几次大促活动，包括每年的“双11”。大促期间从来没有出过任何大的事故，日常的稳定性也一直能保持在99.95%以上。

1）硬件故障。因为我们的容器是直接运行在物理机上的，硬件的故障会直接影响业务的可用性。而硬件的故障是没有办法避免的，因此需要通过各种技术手段或非技术手段保障业务是可用的。

针对硬件最有效的监控方式是syslog日志监控。比较常用的硬盘坏道、内存故障，都可以通过监控/var/log/messages中的内核关键字提前发现问题。

我们在日志监控中增加了很多syslog内核关键字的监控，比如hung_task、out of memory、segfault、Machine Check Exception。后续更好的做法是设置/etc/rsyslog.conf，把内核日志写入专门的文件中，比如/var/log/kernel.log中，监控该文件即可，如图3-19所示。

2）软件问题。除了硬件故障，更多遇到的是软件问题。解决软件问题的一个重要手段是不断完善基础软硬件的监控和针对容器的监控。

基础监控增强。Docker v1.13以前在CentOS6和CentOS7上默认的存储后端是Device mapper。Device mapper实际是一个虚拟的存储设备抽象层，实际的物理存储空间可能会小于虚拟存储设备的空间，也就是存在“超配”的可能性。实时监控存储空间的使用情况就显得很有必要，如图3-20所示。

TCP重传率监控。

TCP重传率反映了一台主机的网络处理繁忙情况，通过该指标可以快速地定位很多与网络有关的疑难问题，比如网络大面积抖动、应用无故RT升高等。

假设每隔1分钟采样一次重传率，TCP重传率的计算公式，可以写成：

如图3-21所示为TCP重传率。重传率是在指定时间段内，发生重传的TCP包占总发送包的百分比。

如果TCP重传率大于1%，一般意味着网络上已经出现了网络抖动，需要进一步排查分析。

图3-22所示为通过tcpretrans工具抓取到的问题现场数据，可以直接推断出由于服务器端10.50.185.79上6001端口的应用处理能力不足，客户端10.50.152.242一直在尝试给服务器端重发数据，而本质问题往往是出现在与这台客户端连接的对端服务器上。

主动事件通知

应用oom事件告警。我们会在计算节点部署监控的agent，通过捕获Docker的事件监听oom的发生，然后给相应应用负责人发送告警。Docker底层会定期监控/sys/fs/cgroup/ memory/docker/docker pid/memory.oom_control中的under_oom字段，发生oom时，内核会自动将under_oom标志从0设成1。

1. $ cat memory.oom_control  
2. oom_kill_disable 0  
3. under_oom 0 

通过命令行docker events -f event=oom，也能观察到oom事件的发生。

Pod迁移（eviction）通知。在默认情况下，Kubernetes发生Pod迁移时并不会主动发出通知。我们定制了Kubernetes源码，对接内部IM工具，实现Pod迁移时主动通知，如图3-23所示。

健康巡检。线上集群的配置必须统一，但由于各种升级变更、程序漏洞，甚至故障恢复，会导致各种脏数据残留在Kubernetes和CMDB里，定期的健康巡检就显得尤为必要了。

健康巡检脚本每天会自动核对Kubernetes和CMDB中的容器信息，统计搜集剩余可用计算、网络、存储资源、节点上不正常容器等信息，这样日常值班的同事可以***时间处理，避免潜在问题的发生。

3）安全漏洞。安全漏洞是我们一直比较重视的方面，通过主动和集团安全团队合作，定期评估业界的CVE漏洞报告，及时修复开源组件如openssl、dhclient等潜在漏洞。

4）人为事故

由于经常需要进行容器云平台的发布，协助业务方进行问题定位，线上的操作难以避免，在发展的早期，也发生过一些人为的误操作。要避免这些线上事故的发生，必须要约束和加强操作流程的规范化和体系化，为此制订了专门的线上操作规范，明确了操作的红线。尤其重要的是自身发布的标准化，既能提高生产效率，又能降低线上变更导致的事故发生概率。

2. 效率

除了稳定性，效率的提升也是很重要的一方面。效率可以包含机器使用的资源效率，也就是成本，也可以包含人员投入的效率，这里主要的投入是指定位和解决线上疑难问题的工作。除不断地增强基础监控的能力，完善主动通知能力以外，我们还做了以下事情：

1）Chatops提升定位效率。在日常排查问题的过程中，往往需要登录Docker宿主机进行操作。我们在内部的IM工具上集成了一个小T自动应答机器人，背后通过CMDB根据Docker IP查询到宿主机的IP地址，极大地提升了排查问题的效率，如图3-24所示。

2）建立业务答疑群。充分利用IM工具的能力，通过创建答疑账号和答疑群，可以更高效地与业务方沟通，快速解决问题。

3）形成问题排查指南。在帮助业务方从系统层面定位各种业务问题的过程中，我们总结了不少经验和方法，把这些思路分门别类地整理汇总，最终形成了一个《系统问题定位排查指南》。

我们面向全公司发布了这一指南，最终是希望业务方能够自助式地快速定位系统问题。

同时，通过建设一套系统问题分析定位平台，来沉淀问题定位排查工具，如图3-25所示。

3. 成本

降低机器成本和运维成本是一项长期而艰苦的工作。在业务高速发展的过程中，很可能会忽视机器成本给公司运营带来的压力。一旦开始降低成本，会发现有很多降低的空间，在这个过程中，我们也总结了几条降低成本的***实践和经验。

1）资源池化。各个项目组的开发人员往往习惯为各自的项目预留一定的缓冲空间。这些缓冲的机器池往往会变成业务方的自留地。将业务接入PaaS平台的一大好处是通过容器的动态申请和调度，把小池子逐个消除，形成统一的资源池。

2）混部和调度。提升容器部署密度以后，对业务带来的风险是硬件故障对业务稳定性的影响会比之前更高。根据业务基线属性的不同，将资源消耗不同类型的业务混部在一台宿主机上，可以很好地提升单机的资源利用率。

3）弹性能力。电商的行业特征决定了每年都会出现618、双11、双12等大促的峰值流量。因此，需要购买大量的机器应对这些峰值，峰值压力过后，机器资源有很大的闲置和浪费。因此，在大促期间动态地租用部分公有云资源，在平时只需保留满足日常流量的机器池即可。

3.1.4 稳定性、效率和成本 - 51CTO.COM