[译] Kubernetes 1.23 到 1.24：一次让 Reddit 宕机超 5 小时的升级踩坑

可爱的异常朋友们
还记得这个 500 错误页面吗？似乎是好久以前的事了。那时候的它既可爱又有趣。而现在，我们那只可怜的 Snoo 正被如山的点赞压得喘不过气来。不幸的是，如果你在美国时间 3 月 14 日下午尝试浏览 Reddit，你可能已经在这次 314 分钟的宕机事故 中看到了那只倒霉的 Snoo（而且还是在 Pi Day！）。或许你只看到了空空如也的主页，或者一个报错信息。不管怎样，Reddit 确实挂了。但这并不是你的网络问题，而是我们的锅。
今天我们将聊聊这次 Pi Day 宕机事件，但在此之前，我想先肯定我们团队的付出。在过去的几年里，我们一直致力于提高系统的可用性。事实上，我们的 CTO 写过一篇很棒的博文，详细介绍了我们这几年来的改进。按照 Reddit 的传统艺能，我就直接把那张图偷来贴在这儿了。

Reddit 的每日可用时间与当前 SLO 目标
正如你所见，我们在提升 Reddit 可用性方面取得了显著进展。虽然我们一直在强调改进并努力降低变更风险，但我们尚未在所有领域达到预期目标，因此我们深知某些变更仍然存在不合理的风险。Kubernetes 版本和组件升级对我们来说，依然是一个容易“搬起石头砸自己脚”（footgun）的巨大隐患。事实上，这也正是导致我们 3.14 宕机的主要诱因。
太长不看版

• 升级必要与风险：升级工作（尤其是 Kubernetes 集群升级）存在一定风险，但又是必须推进的任务。我们将通过充分的测试与验证尽可能降低风险，尽管如此，后续仍有大量工作等待完成；
  
• 隐蔽的升级深坑：在我们操作的特定集群上，从 Kubernetes 1.23 升级到 1.24 的过程中，我们踩到了一个前所未见且极其隐蔽的坑。我们花了几个小时才最终决定回滚（而回滚本身也是一个高风险操作）；
  
• 备份恢复的痛点：备份恢复令人讨厌。我们现有的流程有大量问题需要改进。但幸运的是，这次它奏效了；
  
• 后知后觉的根因：直到我们恢复完成数小时后，才发现了那个极其隐蔽的根本原因；
  
• 还没有全军覆没：并非所有服务都中断了。我们的现代服务 API 层都保持弹性运行，但这影响了依赖关系中最关键的遗留节点，因此影响范围仍然包括大多数用户流，我们的现代化进程中仍需更多工作；
  
• 将危机化为动力：我们决心利用这次宕机事件，彻底改变我们长期以来的一些主要架构和流程决策，确保未来的集群升级安全无恙。
  

故障的开始

这事说起来有点讽刺意味。我们团队刚完成了一次之前不太成功的 Kubernetes 升级经验总结，那次问题并不严重，而且根因也已经完全解决了。所以我们又开始对同一个集群进行另一次升级了。
今年我们一直在大力进行内部整顿，试图让系统处于更加易于维护的状态。管理 k8s 集群在很多方面都很痛苦。Reddit 自 2009 年起就在云上运行，并且较早地采用了 k8s。在此过程中我们积累了一堆使用 kubeadm 工具构建的定制化集群。其中一些集群甚至大到无法通过各种云托管服务来支持。这段历史导致了升级节奏的不一致以及集群间配置的分裂。用 DevOps 的话说，我们养了一群需要精心照料的宠物，而不是管理一群标准化的牛。

译者注：其中 “宠物与牛” 对应 DevOps 中的 “Pets vs Cattle”。我没有想出更好的简化翻译方式，可以参考此文章进行理解。

计算团队（Compute Team）负责管理与运行工作负载相关的基础设施，并花费了大量时间来定义和完善我们的升级流程来改善现状。升级会先在专用的集群集上测试，然后按照优先级从低到高的顺序发布到生产环境。这次升级是我们团队本季度的重点任务之一，而作为公司最重要的集群之一：运行着我们技术栈中“遗留部分”（社区亲切地称为 Old Reddit）的集群，已准备好升级到下一个版本。负责此项工作的工程师在 UTC 时间 19:00 刚过就启动了升级，起初的 2 分钟一切正常。然后混乱降临。

Reddit 边缘流量，按 RPS 统计
网站瞬间陷入瘫痪。我们立即创建了事故工单，并召集所有人手排查问题。在 T+3 分钟内已全员就位。我们发现的第一件事是：受影响的集群完全丢失了所有指标（上图显示的是我们 CDN 边缘的统计数据，这些数据特意与主数据分开展示）。我们完全摸不着头脑。唯一明显的线索是 DNS 解析失败了。我们无法解析 Consul（用于跨环境动态 DNS 的服务）中的记录，也无法解析集群内的 DNS 条目。但奇怪的是，公共 DNS 记录的解析却一切正常。我们顺着这条线索查了一会却一无所获。这是我们在之前的任何升级或测试中从未见过的新问题。
面对部署失败，立即回滚是首选方案，我们第一时间也考虑过这点。但亲爱的 Redditor 们，k8s 并没有官方支持的降级流程。因为在升级过程中，k8s 会自动执行许多架构、数据迁移操作，所以没有回头路。因此，降级意味着必须从备份中恢复并重新加载状态！
我们向来谨慎，备份当然是升级流程中的标准动作。然而这个备份和恢复程序是几年前写的。尽管它在我们的小型测试集群中经过了反复、全面的测试，但它并没有完全跟上生产环境的变化，而且我们从未在生产集群上使用过它，更别说在这个集群上了。这意味着我们不确定执行恢复操作需要多久，但初步估计至少是数小时的停机时间。因此我们决定继续调查并尝试找到解决方案。
故障的表现形式

大约过去了 30 分钟，我们仍然没有找到明确的线索。更多人加入了电话会议。来自不同值班轮换的六位工程师正在一线排查，而其他几十人则在观察并提供建议。又过了 30 分钟，我们有了一些眉目，但仍无定论。是时候启动应急预案了，我们分出了一部分计算团队成员去准备从备份中恢复系统的流程。
在此期间，我们几个人仔细查看了日志。尝试重启组件，心想或许有些组件陷入了无限循环或连接池泄漏。同时也注意到以下几点：
<ul>Pod 的启动和停止极慢；
容器镜像拉取极慢（在多千兆带宽下，拉取 100 时使用，而我们的节点数起码要在后面加个零）。然而 Calico 对路由反射器的配置比较晦涩难懂，难以追踪。这正是我们问题的根源所在。</p>路由反射器是几年前由前任团队设置的。随着时间的推移、人员流动和团队发展，所有了解其存在的人员都已离职或跳槽。只有我们规模最大、历史最悠久的集群还在使用它们。因此，没人意识到它可能存在问题。此外，Calico 的配置方式无法通过代码轻松管理。路由反射器配置的一部分需要下载 Calico 特有的数据（这些数据只能通过其 CLI 界面管理，而不是标准的 Kubernetes API），然后手动编辑并上传。要实现这一点，就需要编写自定义工具。不幸的是，我们当时并没有这样做。因此路由反射器的配置没有被提交到任何地方，导致我们没有任何记录，工程师也无法追踪问题。一位工程师碰巧记得我们曾使用过这个功能，并在这次事后分析过程中进行了研究，发现这才是真正影响我们并影响我们的方式。
故障总结

它究竟是如何崩溃的？这真是最出乎意料的事情之一。在研究过程中，我们发现路由反射器的配置方式是将控制平面节点设置为反射器，并让所有其他节点都使用这些反射器。这相当直接，而且在自动扩缩容集群中，控制平面节点是唯一始终可用的节点，这样做也合乎逻辑。然而，这种配置方式存在一个隐蔽的缺陷。请看下面的代码，看看你能不能发现它。提示一下：我们当时升级到的版本是 k8s 1.24。

一个令人毛骨悚然的 Kubernetes 对象在 YAML 中的内容
路由反射器的 nodeSelector 和 peerSelector 指向标签 node-role.kubernetes.io/master。在 k8s 1.20 版本中，将其术语从 master 更改为 control-plane。在 1.24 版本中，他们移除了对 master 的引用。这就是导致我们服务中断的原因：k8s 节点标签。
但这并非全部原因。实际上真正的根因更加系统性，也是我们多年来一直在努力解决的问题之一：不一致。
Reddit 的几乎每个 k8s 集群都以某种方式进行了定制。无论是仅在该集群上运行的独特组件、独特的工作负载、仅在单个可用区运行的开发集群，还是其他各种因素，都存在差异。这是自然增长的必然结果，也导致了我们难以追踪的频繁宕机。计算团队的一项重要任务就是简化这些定制化n欸容，使我们的环境更加同质化。
在过去两年里，我们投入了大量精力来打破原有模式，推动构建以可持续性为核心的基础设施。越来越多的组件正在实现标准化，并在不同环境间共享，而非到处采用定制配置。我们拥有更多可以进行可靠测试的预生产集群，而不是贸然投入生产环境。我们正在开发用于管理整个集群生命周期的工具，力求使所有集群尽可能保持一致，并可根据需要重新创建或复制。我们正朝着仅在绝对必要时才使用定制组件的方向发展，并努力在合理的情况下将这些定制组件打造为新的标准。尤为重要的是，我们在尽可能地对所有组件进行编码，以确保应用的一致性，并清晰地记录我们为实现当前目标所做的选择。对于无法编码的内容，我们也在详细记录，并评估如何用更好的替代方案来取代这些特殊情况。这是一条漫长而艰难的道路，但这是我们自己选择的路，这样才能为我们的工程师和用户提供更好的体验。
尾声

感谢你读到这里，在此我们也想衷心感谢社区每位成员一直以来的关注和支持。没有你们，就不会有今天的 Reddit。正是有了大家，我们才能始终充满热情地持续建设这个平台——尽管过程中难免经历起伏（值得高兴的是，随着我们对网站可靠性的持续投入，宕机的情况正变得越来越少！）。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！

感谢分享，下载保存了，貌似很强大

热心回复！