当前位置:首页 > 云计算 > PAAS > Kubernetes漏洞搞垮了应用程序!瘫痪 1 个小时

Kubernetes漏洞搞垮了应用程序!瘫痪 1 个小时

Monzo的技术负责人详细描述了这次故障的具体原因。

Kubernetes漏洞搞垮了应用程序!瘫痪 1 个小时

由于四个月前就已存在的一个Kubernertes漏洞(https://github.com/kubernetes/kubernetes/issues/47131),英国网上银行初创公司Monzo上周五的服务中断了一个多小时。

据Monzo的工程负责人奥利弗•贝蒂(Oliver Beattie)声称,“由于一连串不幸的事件”,这个漏洞导致整个生产集群瘫痪,著名作家莱蒙尼•斯尼克特(Lemony Snicket)也许会将这起事件取“致命缺陷”(Fatal Flaw)这个标题。

客户们在此期间看到收款延迟、付款失败。 Monzo作为一家基于互联网的银行来运作,客户通过其智能手机应用程序来访问,它提供活期存款账户、预算编制工具和开支警告等服务。

周一,贝蒂公布了分析这起事件的结果(https://community.monzo.com/t/current-account-payments-may-fail-major-outage/26296/95),归咎于Kubernetes及其与相关软件不兼容。

贝蒂解释道,Monzo的架构依赖Kubernetes用于集群编排、分布式数据库etcd以及管理集群路由和负载均衡的软件linkerd。

出现故障前两周,Monzo的平台团队刚将其etc集群升级到了新版本,并将规模从三个节点扩展到了九个节点。没想到这么一来,他们实际上为故障埋下了隐患。周四,一个工程团队为账户持有人部署了一项新功能,但是开始看到问题随之出现,于是相应缩减了服务,以便该服务不在任何副本上运行,但仍作为一项Kubernetes服务而运行。

周五大约14:10(英国标准时间)前后,工程团队对用于处理付款的一项服务进行了更改。这时,客户开始遇到付款失败。两分钟后,恢复了这一更改,但问题依然存在。

到14:18,Monzo的工程师们查明了问题原来出在linkerd上。这个软件没有收到Kubernetes发来的关于新的pod在网络上何处运行的最新消息,因而将请求路由至不再有效的IP地址。

14:26,他们决定重新启动在后台运行的数百个linkerd实例,觉得这么做有望全面解决问题。但是计划落空了,原因是运行集群节点的Kubelet(每个节点上运行的主要“节点代理”)无法从Kubernetes apiserver获取配置数据。

工程师们怀疑另外的问题在影响Kubernetes或etcd,于是重启了三个apiserver进程。到15:13,所有的linkerd pod已重新启动。不过银行应用程序的服务没有收到任何请求。到这个时候,平台完全瘫痪了。

15:27,工程师们注意到:试图读取来自apiserver的服务发现响应时,linkerd将NullPointerException(空指针异常)记入日志。他们意识到之所以无法解析空的响应,正是由于运行的Kubernetes和linkerd的版本彼此不兼容。

为了恢复服务,他们改而使用在该公司的过渡环境(又译登台环境,staging environment)中测试的更新版linkerd。进行了必要的版本升级后,他们认识到:只要删除没有副本的服务,就可以避免试图解析这类服务引起的错误。这让linkerd得以恢复其服务发现,平台开始恢复如初。

贝蒂表示,他的团队“在Kubernetes和etcd客户端发现了一个漏洞,在重新配置集群(就像我们在上一周执行的那种操作)后,这个漏洞会导致请求超时。由于这种超时,服务部署后,linkerd无法从Kubernetes收到关于可以在网络上何处找到它的最新消息。”

他表示,重新启动linkerd实例让问题更复杂化,因为它揭露了特定版本的linkerd和Kubernetes之间的不兼容性。

贝蒂总结道:“我想要对每个人保证,我们非常重视这起事件;这是我们公司有史以来发生的最严重的技术事件之一,我们的目标是经营一家客户可以永远依赖的银行。我们知道我们让大家失望了,对此深表歉意。”

真诚的道歉似乎受到了客户的好评,许多客户对详细披露和解释原委的做法表示了赞赏。

 

Kubernetes漏洞搞垮了应用程序!瘫痪 1 个小时:等您坐沙发呢!

发表评论

表情
还能输入210个字