Kubernetes 集群 5 个故障案例分析

最近看到了一份收集Kubernetes故障案例的资料，资料由ZalandoTech的高级首席工程师Henning Jacobs加以维护。这个由社区驱动的项目全面介绍了Kubernetes反模式以及为何导致Kubernetes运行错误的原因。

k8s.af上的案例由工程师和实施者编写，描述了许多糟糕的经历：比如导致高延迟的CPU限制、阻止自动扩展的IP上限、应用程序日志丢失、pod被终止、502 错误、部署缓慢和生产环境故障等。

愿通过分析这些失败案例，大家可以学会如何更好地配置和改进K8s环境。

1、CPU限制导致高延迟

设定CPU限制是把双刃剑。您不想浪费计算资源，然而设定人为限制又可能导致容器耗尽所有可用的CPU。这可能会导致一连串连锁反应事件，从而导致性能停滞、其他组件停运。

为了遏制容器，Kubernetes使用完全公平的调度程序配额（CFS Quota），以防止超出CPU限制。遗憾的是，Kubernetes中过于严格的遏制会导致性能问题。

Buffer的故事就是一个例子。在人为遏制导致性能不佳后，基础架构团队最终决定为面向用户的实例取消CPU限制和遏制，针对每个节点分配合适的CPU，留出>20%的余量。这么一来，该团队将所有容器的容器延迟至少缩短了一半。至于主登录页面，最终结果是快了22倍。

Buffer基础架构工程师Eric Khun写道：“我们在改用微服务架构的过程中不断反复试验。即使在运行k8s几年后，我们仍在学习其奥秘。”

应谨慎对待取消CPU限制。相反，Khun建议“升级内核版本，而不是消除CPU限制。如果您的目标是力求低延迟，应取消CPU限制，但在这么做时要非常小心。”他建议设置适当的CPU请求，并使用Datadog之类的解决方案，添加监控机制。

2、应用程序日志丢失

日志记录对于诊断错误和修复问题至关重要。但是如果您的应用程序未生成日志，会发生什么？

PrometheusKube讲述了一个奇怪的故障案例——有一天，某个节点莫名其妙地停止发送日志。工作团队使用fluent-bit来发送日志，注意到Elasticsearch未满足某些请求。

团队在开启调试日志功能后决定部署Fluentd，随后慢慢部署Fluentd，逐个节点地替换fluent-bit。团队称：“Kubernetes让您可以快速迭代部署新软件，这点很出色。”在编辑另一个配置后，他们终于能够准确无误地发送日志了。

PrometheusKube建议基于流量进行监控，并使用黑盒监控方法来发现类似的情况。

3、自动扩展因IP上限而受阻

云原生架构的优点在于能够快速高效地扩展。弹性计算模式可帮助应用程序自动响应新需求。然而，如果计算环境无法创建新的IP地址，就无法进行自动扩展。

Love Holidays的DevOps负责人Dmitri Lerko在个人博客中描述了这种情形。有人反映部署缓慢后，Love Holidays团队立即了解问题。后来发现，通常需要几分钟来部署的应用程序却需要几小时。集群中的一半pod像往常一样顺畅运行，而另一半陷入挂起状态。它们是如何用完IP地址的？

结果查明，默认情况下，谷歌Kubernetes引擎（GKE）使用的IP地址比预期的要多得多。Lerko说：“GKE为每个节点分配256个IP地址，这意味着如果运行256个节点，就连像/16这样的大型子网也会很快耗尽地址资源。”为了避免类似问题，Lerko建议减少每个节点的最大Pod数量，并考虑使用子网扩展以扩大可用IP的范围，或增加现有节点的大小。

4、负载均衡系统配置错误导致完全中断

生产环境中断、停运、甚至生产环境部分中断都会大大影响用户体验，并抑制业务增长。为DevOps Hof撰稿的Marcel Juhnke描述了在GKE中将工作负载从一个节点池迁移到另一个节点池时，错误配置如何导致某个集群中的入站（ingress）完全中断。解决这种情况只需删除旧的nginx-ingress-controller pod。不过Juhnke说：“在进行可能影响任何流量的变更之前，务必要仔细查看文档。”

5、Kubernetes开发集群上惊现加密货币挖矿软件

随着加密货币价值越来越高，黑客们伺机寻找易受攻击的计算能力，以窃取加密货币。JW Player DevOps团队的Brian Choy写道，JW Player就遇到了这档事。

在收到负载增加的大量自动警报后，DevOps团队深入挖掘，结果发现了一个进程在CPU利用率100%的状态下运行，这非常可疑。简而言之，黑客利用了Kubernetes监控工具Weave Scope存在的漏洞，该漏洞暴露了面向公众的负载均衡系统安全组和仪表板。利用该信息，黑客进而访问了JW Player的Kubernetes节点上的根目录。

虽然这次泄密事件没有影响任何生产服务，但确实浪费了计算能力；至少可以说，这令人震惊。团队立即删除了部署的Weave Scope，进行更新，并改进RBAC权限以限制Weave Scope的访问，最终解决了问题。

该团队还在考虑采用更深入的监控，用于行为分析、异常及入侵检测。Choy称，他们还在研究服务网格方案，比如Linkerd和Istio，以保护端到端流量。