本文发布已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

Kubernetes v1.28：引入原生边车容器

作者：Todd Neal (AWS), Matthias Bertschy (ARMO), Sergey Kanzhelev (Google), Gunju Kim (NAVER), Shannon Kularathna (Google) |

本文解释了如何使用新的 sidecar 功能，该功能支持可重启的 init 容器，并且在 Kubernetes 1.28 中以 alpha 形式提供。我们希望您能提供反馈，以便我们尽快使此功能毕业。

“sidecar” 的概念几乎从一开始就成为 Kubernetes 的一部分。在 2015 年，关于复合容器的博客文章中将 sidecar 描述为“扩展和增强‘主’容器”的附加容器。Sidecar 容器已成为一种常见的 Kubernetes 部署模式，通常用于网络代理或作为日志记录系统的一部分。到目前为止，sidecar 是 Kubernetes 用户在没有原生支持的情况下应用的概念。缺乏原生支持导致了一些使用摩擦，此增强功能旨在解决这些问题。

1.28 中的 sidecar 容器是什么？

Kubernetes 1.28 向 init 容器添加了一个新的 restartPolicy 字段，当启用 SidecarContainers 功能门时可以使用。

apiVersion: v1
kind: Pod
spec:
  initContainers:
  - name: secret-fetch
    image: secret-fetch:1.0
  - name: network-proxy
    image: network-proxy:1.0
    restartPolicy: Always
  containers:
  ...

该字段是可选的，如果设置，唯一有效的值是 Always。设置此字段会更改 init 容器的行为，如下所示

  • 如果容器退出，则会重启
  • 任何后续 init 容器会在 startupProbe 成功完成后立即启动，而不是等待可重启的 init 容器退出
  • Pod 的资源使用计算发生变化，因为可重启的 init 容器资源现在会添加到主容器的资源请求总和中

Pod 终止仍然仅取决于主容器。具有 restartPolicy 为 Always 的 init 容器（称为 sidecar）不会阻止 Pod 在主容器退出后终止。

可重启的 init 容器的以下属性使其成为 sidecar 部署模式的理想选择

  • 无论您是否设置 restartPolicy，Init 容器都具有明确定义的启动顺序，因此您可以确保 sidecar 在清单中 sidecar 声明之后的任何容器声明之前启动。
  • Sidecar 容器不会延长 Pod 的生命周期，因此您可以在短生命周期的 Pod 中使用它们，而无需更改 Pod 生命周期。
  • Sidecar 容器会在退出时重启，这提高了弹性，并允许您使用 sidecar 来提供主容器可以更可靠地使用的服务。

何时使用 sidecar 容器

您可能会发现内置的 sidecar 容器对以下工作负载很有用

  • 批处理或 AI/ML 工作负载，或其他运行至完成的 Pod。这些工作负载将体验到最显著的好处。
  • 网络代理，在清单中的任何其他容器之前启动。运行的每个其他容器都可以使用代理容器的服务。有关说明，请参阅 Istio 博客文章中的 Kubernetes 原生 sidecar。
  • 日志收集容器，现在可以在任何其他容器之前启动并运行到 Pod 终止。这提高了 Pod 中日志收集的可靠性。
  • Job，可以使用 sidecar 来实现任何目的，而 Job 完成不会被运行的 sidecar 阻塞。无需额外的配置即可确保此行为。

在 1.28 之前，用户如何获得 sidecar 行为？

在 sidecar 功能之前，以下选项可用于实现 sidecar 行为，具体取决于 sidecar 容器的所需生命周期

  • Sidecar 的生命周期小于 Pod 的生命周期：使用 init 容器，它提供明确定义的启动顺序。但是，sidecar 必须退出，其他 init 容器和主 Pod 容器才能启动。
  • Sidecar 的生命周期等于 Pod 的生命周期：使用与 Pod 中的工作负载容器一起运行的主容器。此方法不让您控制启动顺序，并允许 sidecar 容器在工作负载容器退出后可能阻塞 Pod 终止。

内置的 sidecar 功能解决了生命周期等于 Pod 生命周期的用例，并具有以下额外好处

  • 提供对启动顺序的控制
  • 不会阻塞 Pod 终止

将现有 sidecar 过渡到新模型

我们建议仅在 alpha 阶段的短生命周期测试集群中使用 sidecar 功能门。如果您现有的 sidecar 被配置为主容器，以便它可以运行到 pod 的生命周期，则可以将其移动到 pod 规范的 initContainers 部分，并为其指定 restartPolicy 为 Always。在许多情况下，sidecar 应像以前一样工作，并具有定义启动顺序和不延长 pod 生命周期的额外好处。

已知问题

内置 sidecar 容器的 alpha 版本存在以下已知问题，我们将在该功能升级到 beta 版本之前解决这些问题

  • CPU、内存、设备和拓扑管理器不知道 sidecar 容器的生命周期和额外的资源使用，并且会像 Pod 的资源请求低于实际请求一样运行。
  • 使用 sidecar 时，kubectl describe node 的输出不正确。输出显示的资源使用量低于实际使用量，因为它没有使用 sidecar 容器的新资源使用量计算。

我们需要您的反馈！

在 alpha 阶段，我们希望您在您的环境中使用 sidecar 容器，并在遇到错误或摩擦点时打开 issue。我们特别感兴趣以下方面的反馈

  • 关闭序列，尤其是在运行多个 sidecar 的情况下
  • 崩溃的 sidecar 的回退超时调整
  • sidecar 运行时 Pod 就绪和活性探测的行为

要打开 issue，请参阅Kubernetes GitHub 存储库。

下一步是什么？

除了将要解决的已知问题之外，我们还在努力为 sidecar 和主容器添加终止顺序。这将确保 sidecar 容器仅在 Pod 的主容器退出后才终止。

我们很高兴看到 sidecar 功能来到 Kubernetes，并对反馈感兴趣。

致谢

自最初的 KEP 编写以来，已经过去了很多年，因此如果遗漏了多年来为此功能工作的任何人，我们深感抱歉。这是尽力尝试识别参与此工作的人员。

更多信息