为何不使用Kubernetes:5个失败案例

作者:Bill Doerrfeld  编译:沈建苗

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

文章来源:https://containerjournal.com/editorial-calendar/best-of-2021/how-not-to-use-kubernetes-5-failure-stories/

K8S中文社区微信公众号

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址