故障分析之Kubernetes漏洞

共计 3269 个字符，预计需要花费 9 分钟才能阅读完成。

值得注意的是，我们上周有两个大的事故，而且很多用户受到影响（再次抱歉）。第一个事故持续将近一周时间，只影响了我们的预付费产品 -ie，Monzo Alpha 和 Beta 卡。第二个事故在周五上午持续影响 1.5 个小时，这次不仅影响了我们的预付费产品，而且还影响了我们的现金账户。这篇文章主要介绍的是后者。

通过我去年发布的这些博客（https://monzo.com/blog/2016/09/19/building-a-modern-bank-backend/），你可以更深入的了解下我们整体的后台架构设计，但是更重要的是要了解下我们技术栈中下面几个组件扮演的角色，这样才能更深度的了解这篇文章。

两周前：平台研发团队对我们的 etcd 集群做了变更，升级了一个新的版本，对集群做了扩容。以前，这个集群只包含了三个节点（每一个 zone 中一个节点），这次我们提升为 9 个节点（每个 zone 中三个节点分布）。因为 etcd 的依赖能够达到分布式的 Quorum，这意味着在这个设置我们可以容忍同时失去整个 zone 再加上另一个 zone 中的单个 node。

这次是按计划升级，并没有设计安排任何停机时间。我们可以确认这个集群是正确的，但是很重要的是这里触发了另一个系统的错误。

一天前：我们的一个团队对于目前的账户开发了一个新的功能，在生产环境部署了一个新的接口，但是注意到他正在经历的问题。作为防范措施，他们将服务缩减为没有运行副本，但 Kubernetes services 仍然存在。

工程师部署变更服务需要处理当前的支付账户。这种做法并非罕见，我们的工程师也经常做这样的事情：为了尽量减少变化的风险，我们以更小的粒度，更频繁的节奏，使用一个可重复的，明确定义的过程来发布这些功能。但是当服务部署完成时，所有对它的请求都开始失败。此时开始我们站点当前的账户开始支付失败。而与此同时，预付卡不受影响，因为它不使用失败的的服务。

我们回滚了发布的应用。这也是发布失败标准的操作流程，当接口被改变，他们应该通过回滚操作确保向前兼容。然而，这种情况下即使是回滚操作，错误依旧存在，支付仍然不能成功。

我们立即宣布内部故障。团队成员开始召集，以确定问题的影响，并开始调试。

工程师确定 linkerd 似乎处于不健康的状态，并试图使用一个内部工具来识别出现问题的单个节点并重新启动它们。如前所述，linkerd 是一个我们用来管理后端服务之间通信的系统。要知道发送特定请求的位置，需要从请求中获取一个逻辑名称，如 service.foo，并将其转换为 IP 地址 / 端口。在这种情况下，linkerd 没有收到 Kubernetes 关于新的 pods13 运行在网络上的更新。因此，它试图将请求路由到不再对应于正在运行的进程的 IP 地址。

我们认为，最好的方法是重启后端的所有 linkerd 实例，其中有几百个，假设它们都遇到同样的问题。当我们遇到问题时，许多工程师正试图通过激活旨在提供备份的内部流程来最小化客户对付款或接收银行转帐的影响。这意味着尽管持续不稳定，大多数客户仍然能够成功使用他们的卡。

替换 linkerd 无法启动，因为运行在我们每个节点上的 Kubelet 无法从 Kubernetes apiservers 检索适当的配置。此时，我们怀疑 Kubernetes 或 etcd 有其他问题，并重新启动三个 apiserver 进程。完成后，替换 linkerd 实例将能够成功启动。

所有 linkerd pod 都重新启动，但每秒处理数千个请求的服务现在没有收到任何流量。此时，客户完全无法刷新其 Monzo 应用程序中的 Feed 或余额，而我们的内部 COps（“客户操作”）工具停止工作。现在这个问题已经升级为全面的平台停机，没有任何服务能够满足要求。正如您可以想像的，几乎所有的自动警报都已经触发。

我们注意到，linkerd 在尝试解析来自 Kubernetes apiserver 的服务发现响应时正在记录 NullPointerException（http://t.cn/Rl086mW）。我们发现这是我们正在运行的 Kubernetes 和 Linkerd 版本之间的不兼容，特别是没有解析空服务。因为 linkerd 更新版本已经在我们的暂存环境中测试了几个星期，其中包含了对不兼容性的修复，平台团队的工程师开始部署新版本的 linkerd 以试图向前滚动。

在检查代码更改之后，工程师意识到他们可以通过删除不包含 endpoints 的 Kubernetes 服务（即前面提到的服务作为预防措施缩小到 0 个副本）来防止解析错误。他们删除违规服务和链接器 能够成功加载服务发现信息。此时，平台恢复正常，流量开始在服务之间正常转移，付款开始重新开始工作。事件结束！

分布式系统中的大规模失败可能是很难理解的，善意的人为行为有时会使问题复杂化，就像这里所发生的那样。当这样的事情发生时，我们希望尽可能地从事件中学习，以确保它不会重新出现。我们已经确定了我们将在短期内采取的几个步骤：

1. 修复 Kubernetes 中的错误，可以在集群重新配置后触发超时。
2. 推出修复解析错误的新版本的 linkerd。
3. 为受影响的组件创建更好的健康检查，仪表板和警报，以更清晰地显示有关错误的信号，并防止出现人为错误。
4. 改进我们的程序，以确保我们尽可能清楚，快速地在内部和外部传达中断。

我想向大家保证，我们非常认真地对待这件事。这是我们历史上发生的最严重的技术事件之一，我们的目标是经营一家客户可以依赖的银行。真的很抱歉，我们知道我们让您失望。我希望这个事件分析能清楚地说明发生了什么，以及我们正在做什么来确保未来不会再发生。我会确保我们发布类似的事情来处理这种严重的事件：如果我是一个客户，我想知道。而且我个人觉得这个帖子很有趣，可以作为对生产系统的深入了解。如果您有任何问题，请告诉我。

阿里云 2 核 2G 服务器 3M 带宽 61 元 1 年，有高配

腾讯云新客低至 82 元 / 年，老客户 99 元 / 年

代金券：在阿里云专用满减优惠券