Azure Kubernetes 惊魂记
默认
发布于: 2020-10-21

2020 年十一前夕,突发 P0 事故。

背景

晚上 9 点钟左右,突然接到接口访问告警,上线排查得知集群对外 Ingress 无法正常工作。

在尝试修复近 1 小时无果后,各方面压力铺面而来,我被要求在明早 8 点前必须修复问题!😃😃

排查过程

查询各节点工作正常,但是 ingress controller 无法沟通 API Server。

确认是否由于误更新导致的兼容性问题,检查了一下了下更新记录,但近期并未有关于 Ingress 的更新操作。

突然想到前天 Azure 发布的 AKS 更新公告,是否由于更新 API Server 引起的问题?尝试升级了 Ingress 到最新版本,但表现依旧一致。猜测是 AKS 更新有问题,登录到某一 Pod 得到详细日志,确定无法连接 API Server。

提交工单

在 Azure 上提交 A 级工单。

某小哥

首先一位小哥接入工单打来电话,表达 AKS 服务正常。

我请求检查复现问题,小哥答复当前我司的集群版本已经下线无法测试了???(无法创建这个版本的集群?还是已经将测试流程删除了?)这位小哥我比较熟悉,他基本无法解决问题。

无果,工单转移到相关网络工程师。

某小妹

此时大约 12 点钟附近,某小妹接入工单。

猜测是工单团队的 On Call 成员,通过电话再次详细沟通问题,小妹说看到报错日志。不确定她看到的是什么日志,按道理她没有权限可以直接看到客户 Pod 或者集群的日志。

工单再次转移。

小A 和 大哥

此时大约凌晨 1 点左右,这次工单终于派到后线(Azure 中国的工单首先会被分配给世纪互联,世纪互联无法解决才会真正沟通到 Azure China 团队) Azure 派到两位 On Call 的工程师又或者是负责人,其中明显有一位小兄弟和一位大哥。

小 A 和大哥相对就比较专业了,小 A 负责主要沟通协作和流程指导,要求通过屏幕共享直接进行排查。随后安装 Teams 接入通话和屏幕共享,真正的技术支持开始。

为排除 API Server Timeout 问题导致打断 Pod 启动过程,首先关闭了 Pod 的健康探针,长时间观察依旧是同样的报错。

两位工程师貌似没有更多头绪,接着我试着复现其他 Pod 的状态以便提供更完善的日志和信息给到支持人员,大哥决定查看 AKS 内部详细的日志,开始电话某相关人员开通查看日志权限,就这样又叫醒了一些人,接着陆陆续续排查几个小时一直持续到早晨 5 点钟。

小 A 好像已经回去睡觉了,大哥关闭了语音。马上天亮我非常着急,距离 8 点仅剩 3 个钟!我突然认识到此次决定的错误,不应该指望 Azure 立刻修复问题,短短一夜不可能 Commit 这么严重的事故代码和细致分析,8 点钟完成修复即是天方夜谭了。

紧迫感愈加强烈,我应另辟他法,思考如何不通过 Ingress 让核心服务的接口暴露出去,思考了几个方案:

  • 抛弃 Ingress 直接拉个 LB 将流量导入到 Pod 上
  • 下线有关 API Server 的服务
  • 新开一个 API 网关

下线 Ingress 则需要手动重建路由表,计算了一下工作量 8 点钟不可能完成。窗外已开始灰蒙蒙了,沉下心来,死马当活马医还是要升级集群。

升级集群

升级集群风险不可控,所以 Azure 工程师并没有建议。但是影响我做出升级集群的决定,是因为集群大约 1 年没有更新,再结合 AKS 如此高的更新频率,和前小哥回复测试环境下线的判断,我猜测他们升级 AKS 已经不考虑兼容旧的版本。

防止分心我静音了 Teams 着手更新集群,40分钟,更新渐渐完成。

首先展示的是集群更新失败,但好在大部分节点都更新到了最新版本,原因是有一个节点未能更新成功,万幸 Pod 恢复正常了🎉🎉 可以向用户提供服务了,再次看到接口日志蹦跶的感觉真好 😃

无眠之夜,赶紧洗刷乘坐地铁赶到公司。8 点钟 B 端客户顺利完成了活动,提着的心终于放下来了,可能由于长时间的神经紧绷,白天并没有明显的困意。

后续

Azure 确定了相关问题,由于更新的不够彻底,导致流量没有正确的转发到 API Server。在随后的工单和技术服务中,提供的文档和解决方案频繁出现问题,低级错误更是不忍直视令人大跌眼镜,Azure 在我心中的可靠性直线下降。

2021 年更新

在此之后 AKS 又相继出现了严重的宕机问题,今年无论是国区还是 Global 都出现过不小的事故,对 Azure 有些失望。在未来的选型中会多尝试 AWS 相关服务。

目前 typetype.io 在核心业务上大量使用了 AWS 整体感受非常好(Global),少量业务分布在 Azure 上。