Netflix 如何处理其容器平台 Titus上 的孤儿 Pod 问题

Netflix 工程团队介绍了他们如何调查、识别和解决 Titus 的“孤儿”pod 问题，揭示了从内核恐慌到 Kubernetes（k8s）的整个过程，并最终为操作人员提供了可用于理解节点消失原因的工具。

Netflix Titus 是 Netflix 开发的容器管理平台，于 2018 年开源。按照设计，它主要是用于在云中大规模运行容器，并专门针对 Netflix 的动态、高流量大型流媒体服务的独特需求和挑战而量身定制。

虽然孤儿 pod 在系统中占少数，但对批处理用户来说是一个很大的问题，因为他们会面临不确定性，缺少明确的返回代码可以指导他们做重试决策。孤儿 pod 是由于底层 Kubernetes Node 对象消失造成的。当一个节点消失时，将触发一个垃圾收集（GC）进程，删除相关的 pod。为了增强用户体验，Titus 使用了一个自定义控制器来维护 pod 和 Node 对象的历史记录，以保证信息透明度。然而，由于对于丢失原因缺乏令人满意的解释，他们决定对根本原因做进一步调查。

Node 可能因为各种原因消失，尤其是在云环境中。通常，云供应商会使用 Kubernetes 云控制器来检测底层服务器的丢失，并随后删除 Kubernetes 节点对象。然而，这并没有回答节点消失的关键问题。为了解决这个问题，Netflix 工程团队引入了一个注解来捕获终止原因，为理解节点消失的原因提供信息。

{     "apiVersion": "v1",     "kind": "pod",     "metadata": {          "annotations": {               "pod.titus.netflix.com/pod-termination-reason": "Something really bad happened!",...

添加“pod-termination-reason”注解是其中一个关键的步骤。通过将该注解加入垃圾收集器控制器，并将其包含在可能意外终止 pod 或节点的进程中，Titus 实现了一种可以统筹兼顾的方法。与修正状态不同，使用注解可以兼顾历史考量而保留 pod 的完整性。现在，Titus 可以捕获各种终止原因，如抢占作业、硬件故障、用户干预或内核恐慌，并提供人类可读的消息。

考虑到 Linux 内核出现故障时可用的选项有限，处理内核故障是一项独特的挑战。受 Google Spanner“最后喘息”概念（节点在致命故障时发送 UDP 数据包）的启发，Titus 使用 netconsole 模块实现了一个解决方案。配置 netconsole，将 Linux 内核设置为在内核恐慌时发送 UDP 数据包，从而使平台在发生灾难性故障时也能捕获重要的信息。

最后一步是连接到 Kubernetes 并实现一个控制器：

1. 监听 netconsole UDP 数据包。

2. 识别内核恐慌，并将它们与 k8s 节点对象关联起来。

3. 标注并删除与恐慌节点关联的 pod。

4. 标注并删除恐慌节点。

该进程可以确保在检测到内核恐慌时立即采取行动，而不必等待垃圾收集器进程。注解充当文档，使操作人员能够清楚地了解节点和相关 pod 发生了什么。

Titus 显示 pod 在一个内核恐慌的节点上丢失的过程

他们引入的措施不仅直接解决了孤儿 pod 的问题，还为操作人员提供了重要的观察工具。现在，Titus 用户可以收到有关作业失败原因的详细信息，即使在内核恐慌的情况下也是如此。虽然标记由于这种严重事件而导致的作业失败可能并不是最理想的方法，但令人满意的是，这种方法增强了可观察性以及主动处理和纠正内核恐慌的能力。由于所有这些改进，Titus 显著增强了其功能，确保工程师和批处理用户都能获得更流畅的体验。

原文链接：

https://www.infoq.com/news/2023/12/orphaned-pods-netflix-titus/

声明：本文由 InfoQ 翻译，未经许可禁止转载。