Kubernetes v1.28:介绍原生边车容器
作者:Todd Neal (AWS), Matthias Bertschy (ARMO), Sergey Kanzhelev (Google), Gunju Kim (NAVER), Shannon Kularathna (Google)
本文介绍了如何使用新的边车(Sidecar)功能,该功能支持可重新启动的 Init 容器, 并且在 Kubernetes 1.28 以 Alpha 版本发布。我们希望得到你的反馈,以便我们尽快完成此功能。
“边车”的概念几乎从一开始就是 Kubernetes 的一部分。在 2015 年, 一篇关于复合容器的博客文章(英文)将边车描述为“扩展和增强 ‘main’ 容器”的附加容器。 边车容器已成为一种常见的 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 容器退出
- 由于可重新启动的 Init 容器资源现在添加到主容器的资源请求总和中,所以 Pod 使用的资源计算发生了变化。
Pod 终止继续仅依赖于主容器。
restartPolicy
为 Always
的 Init 容器(称为边车)不会阻止 Pod 在主容器退出后终止。
可重新启动的 Init 容器的以下属性使其非常适合边车部署模式:
- 无论你是否设置
restartPolicy
,初始化容器都有一个明确定义的启动顺序, 因此你可以确保你的边车在其所在清单中声明的后续任何容器之前启动。 - 边车容器不会延长 Pod 的生命周期,因此你可以在短生命周期的 Pod 中使用它们,而不会对 Pod 生命周期产生改变。
- 边车容器在退出时将被重新启动,这提高了弹性,并允许你使用边车来为主容器提供更可靠地服务。
何时要使用边车容器
你可能会发现内置边车容器对于以下工作负载很有用:
- 批量或 AI/ML 工作负载,或已运行完成的其他 Pod。这些工作负载将获得最显着的好处。
- 任何在清单中其他容器之前启动的网络代理。所有运行的其他容器都可以使用代理容器的服务。 有关说明,请参阅在 Istio 中使用 Kubernetes 原生 Sidecar。
- 日志收集容器,现在可以在任何其他容器之前启动并运行直到 Pod 终止。这提高了 Pod 中日志收集的可靠性。
- Job,可以将边车用于任何目的,而 Job 完成不会被正在运行的边车阻止。无需额外配置即可确保此行为。
1.28 之前用户如何获得 Sidecar 行为?
在边车功能出现之前,可以使用以下选项来根据边车容器的所需生命周期来实现边车行为:
- 边车的生命周期小于 Pod 生命周期:使用 Init 容器,它提供明确定义的启动顺序。 然而,边车必须退出才能让其他 Init 容器和主 Pod 容器启动。
- 边车的生命周期等于 Pod 生命周期:使用与 Pod 中的工作负载容器一起运行的主容器。 此方法无法让你控制启动顺序,并让边车容器可能会在工作负载容器退出后阻止 Pod 终止。
内置的边车功能解决了其生命周期与 Pod 生命周期相同的用例,并具有以下额外优势:
- 提供对启动顺序的控制
- 不阻碍 Pod 终止
将现有边车过渡到新模式
我们建议仅在 Alpha 阶段的短期测试集群中使用边车功能。
如果你有一个现有的边车,被配置为主容器,以便它可以在 Pod 的生命周期内运行,
则可以将其移至 Pod 规范的 initContainers
部分,并将 restartPolicy
指定为 Always
。
在许多情况下,边车应该像以前一样工作,并具有定义启动顺序且不会延长 Pod 生命周期的额外好处。
已知问题
内置边车容器的 Alpha 版本具有以下已知问题,我们将在该功能升级为 Beta 之前解决这些问题:
- CPU、内存、设备和拓扑管理器不知道边车容器的生命周期和额外的资源使用情况,并且会像 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 处理了 Job 完成问题