Kubernetes 集群故障案例

最近看到了一份收集 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，以保护端到端流量。