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

Kubernetes v1.28: 引入原生 Sidecar 容器

作者：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 终止仍仅取决于主容器。一个设置了 Always restartPolicy 的 init 容器（称为 sidecar）不会阻止 Pod 在主容器退出后终止。

可重启 init 容器的以下特性使其非常适合 sidecar 部署模式：

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

何时使用 sidecar 容器

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

  • 批处理或 AI/ML 工作负载，或运行至完成的其他 Pod。这些工作负载将体验到最显著的优势。
  • 网络代理，在 manifest 中的任何其他容器之前启动。运行的每个其他容器都可以使用代理容器的服务。有关说明，请参阅Istio 博客文章中的 Kubernetes Native sidecars。
  • 日志收集容器，现在可以在任何其他容器之前启动并运行直到 Pod 终止。这提高了你的 Pod 中日志收集的可靠性。
  • Jobs，可以使用 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 特性门控。如果你有配置为在 Pod 生命周期内运行的主容器 sidecar，则可以将其移至 Pod Spec 的 initContainers 部分，并设置 restartPolicy 为 Always。在许多情况下，sidecar 应能像以前一样工作，同时增加了明确启动顺序和不延长 Pod 生命周期的额外好处。

已知问题

内置 sidecar 容器的 Alpha 版本存在以下已知问题，我们将在特性晋升到 Beta 之前解决这些问题：

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

我们需要你的反馈！

在 Alpha 阶段，我们希望你在你的环境中试用 sidecar 容器，并在遇到 bug 或使用不便时提交 issue。我们特别感兴趣的是以下方面的反馈：

  • 关机顺序，特别是在运行多个 sidecar 的情况下
  • 崩溃 sidecar 的回退超时调整
  • 当 sidecar 运行时 Pod readiness 和 liveness 探测的行为

要提交 issue，请访问Kubernetes GitHub 仓库。

下一步计划？

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

我们很高兴看到 sidecar 特性来到 Kubernetes，并期待你的反馈。

致谢

自最初的 KEP 编写以来已过去多年，因此如果我们遗漏了这些年来为此特性做出贡献的任何人，我们深表歉意。这是一次尽力而为的尝试，旨在感谢参与这项工作的人员。

更多信息