作者 Todd Neal (AWS), Matthias Bertschy (ARMO), Sergey Kanzhelev (Google), Gunju Kim (NAVER), Shannon Kularathna (Google)
本文介绍如何使用新的边车特性，该特性允许设置可重新启动的 Init 容器，并已在 Kubernetes 1.28 中以 Alpha 状态提供。我们希望听取你的反馈，以便尽快将此功能推进到毕业阶段。
“边车（Sidecar）” 的概念几乎从一开始就是 Kubernetes 的一部分。
2015 年，一篇关于边车容器的 博客文章 将边车描述为“扩展和增强‘主’容器”的附加容器。
边车容器已成为一种常见的 Kubernetes 部署模式，通常用于网络代理或作为日志系统的一部分。
到目前为止，边车一直是 Kubernetes 用户在缺少原生支持的情况下应用的概念。
缺乏原生支持也导致了一些使用摩擦，此增强功能旨在解决这些问题。
在 Kubernetes 1.28 中的边车容器是什么？
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 容器的以下属性使其非常适合边车部署模式：
- 不管你是否设置了
restartPolicy，Init 容器都有明确定义的启动顺序。
因此，你可以确保清单中的边车容器会在边车声明之后的所有容器之前启动。 - 边车容器不会延长 Pod 的生命周期，因此你可以在生命期较短的 Pod 中使用
它们，而无需更改 Pod 生命周期。 - 边车容器在退出时会重新启动，这提高了可靠性，从而允许你使用边车来为主容器提供更为可靠的服务。
何时使用边车容器
你可能会发现内置边车容器对于以下工作负载很有用：
- 批处理或 AI/ML 工作负载，或运行一段时间就结束的其他 Pod。这些工作负载将获得最显著的好处。
- 在清单中的所有其他容器之前启动的网络代理。所运行的所有其他容器都可以使用代理容器的服务。
有关说明，请参阅 Istio 中的 Kubernetes 原生边车容器博客文章。 - 日志收集容器，现在可以在任何其他容器之前启动并运行至 Pod 终止。这提高了 Pod 中日志收集的可靠性。
- 作业，可以将边车用于任何目的，而 Job 的完成不会被正在运行的边车所阻止。无需额外配置即可确保此行为。
1.28 之前用户是如何实现边车行为的？
在引入边车特性之前，可以使用以下选项来根据边车容器的预期生命周期来实现边车行为：
- 边车的生命周期小于 Pod 生命周期：使用 Init 容器，这类容器提供明确定义的启动顺序。
然而边车必须退出，才能让其他 Init 容器和主 Pod 容器启动。 - 边车的生命周期与 Pod 生命周期相同：使用与 Pod 中的工作负载容器一起运行的主容器。此方法无法让你控制启动顺序，并且边车容器可能会在工作负载容器退出后阻止 Pod 终止。
内置的边车特性解决了生命周期与 Pod 生命周期相同的场景，并具有以下额外优势：
- 提供对启动顺序的控制
- 不阻止 Pod 终止
将现有边车过渡到新模型
我们建议在 Alpha 阶段仅对短期存在的测试集群启用边车特性门控。
如果你已经有一个被配置为主容器的边车，且它可以在 Pod 的整个生命周期内运行，
则可以将其移至 Pod 规约的 initContainers 部分，并将 restartPolicy 设置为 Always。
在许多情况下，边车容器能够继续像以前一样工作，并且额外的好处是可以定义启动顺序，并且不会延长 Pod 的生命周期。
已知的问题
内置的边车容器的 Alpha 版本具有以下已知问题，我们将在将该功能升级为 Beta 之前解决这些问题：
- CPU、内存、设备和拓扑管理器无法意识到边车容器的生命周期和额外资源使用情况，它们会按照 Pod 资源请求比实际用量低的假设来运行 Pod。
- 使用边车时，
kubectl describe node命令描述的节点的输出不正确。
输出显示的资源使用量低于实际使用量，因为它没有计算边车容器的资源使用量。
我们需要你的反馈！
在 Alpha 阶段，我们希望你在你的环境中尝试边车容器，并在遇到错误或异常点时登记问题。
我们对以下方面的反馈特别感兴趣：
- 关闭顺序，尤其是多个边车一起运行的时候
- 边车的重启回退超时时间调整
- 边车运行时 Pod 就绪性和存活性探针的行为
要登记问题，请访问 Kubernetes GitHub 仓库。
下一步是什么？
除了要解决的已知问题之外，我们正在努力为边车和主容器添加终止顺序。终止顺序能够确保边车容器仅在 Pod 的主容器退出后才终止。
我们很高兴看到 Kubernetes 引入了边车特性，并对反馈感兴趣。
致谢
自最初的 KEP 编写以来已经过去了很多年，因此如果我们漏掉了多年来致力于此特性的相关人员，请接受我们的道歉。我们尽最大努力去认可参与这项工作的人们。
- mrunalp 参与了设计讨论和评审
- thockin 多年来的 API 讨论和支持
- bobbypage 的评审
- smarterclayton 的细致评审和反馈
- howardjohn 多年来的反馈以及在实现过程中的早期尝试
- derekwaynecarr 和 dchen1107 的领导
- jpbetz 对 API 和终止排序的设计以及代码评审
- Joseph-Irving 和 rata 参与多年前的早期迭代设计和评审
- swatisehgal 和 ffromani 针对有关资源管理器影响所给出的早期反馈
- alculquicondor 针对与调度程序版本偏差相关的反馈 - wojtek-t 对 KEP 的 PRR 的评审
- ahg-g 对 KEP 的调度器部分的评审
- adisky 解决作业完成问题
更多信息
- 阅读 Kubernetes 文档中的边车容器 API
- 阅读 Sidecar KEP
