前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Kubernetes 1.28:介绍原生 Sidecar 容器

Kubernetes 1.28:介绍原生 Sidecar 容器

作者头像
xcbeyond
发布2023-09-06 11:26:00
1K0
发布2023-09-06 11:26:00
举报
文章被收录于专栏:技术那些事

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

本文介绍如何使用新的边车特性,该特性允许设置可重新启动的 Init 容器,并已在 Kubernetes 1.28 中以 Alpha 状态提供。我们希望听取你的反馈,以便尽快将此功能推进到毕业阶段。

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

在 Kubernetes 1.28 中的边车容器是什么?

Kubernetes 1.28 在 Init 容器[2]中添加了一个新的 restartPolicy 字段,该字段可以在 SidecarContainers特性门控[3] 启用时使用。

代码语言:javascript
复制
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[4]成功完成后立即启动,而不是等待可重新启动的 Init 容器退出
  • Pod 的资源使用计算发生变化,因为可重新启动的 Init 容器资源现在添加到主容器的资源请求总和中

Pod 终止[5] 继续只根据主容器来判定。restartPolicyAlways 的所有 Init 容器(称为 Sidecar)不会阻止 Pod 在主容器退出后进入终止状态。

可重新启动的 Init 容器的以下属性使其非常适合边车部署模式:

  • 不管你是否设置了 restartPolicy,Init 容器都有明确定义的启动顺序。因此,你可以确保清单中的边车容器会在边车声明之后的所有容器之前启动。
  • 边车容器不会延长 Pod 的生命周期,因此你可以在生命期较短的 Pod 中使用 它们,而无需更改 Pod 生命周期。
  • 边车容器在退出时会重新启动,这提高了可靠性,从而允许你使用边车来为主容器提供更为可靠的服务。

何时使用边车容器

你可能会发现内置边车容器对于以下工作负载很有用:

  • 批处理或 AI/ML 工作负载,或运行一段时间就结束的其他 Pod。这些工作负载将获得最显著的好处。
  • 在清单中的所有其他容器之前启动的网络代理。所运行的所有其他容器都可以使用代理容器的服务。有关说明,请参阅 Istio 中的 Kubernetes 原生边车容器博客文章[6]
  • 日志收集容器,现在可以在任何其他容器之前启动并运行至 Pod 终止。这提高了 Pod 中日志收集的可靠性。
  • 作业,可以将边车用于任何目的,而 Job 的完成不会被正在运行的边车所阻止。无需额外配置即可确保此行为。

1.28 之前用户是如何实现边车行为的?

在引入边车特性之前,可以使用以下选项来根据边车容器的预期生命周期来实现边车行为:

  • 边车的生命周期小于 Pod 生命周期:使用 Init 容器,这类容器提供明确定义的启动顺序。然而边车必须退出,才能让其他 Init 容器和主 Pod 容器启动。
  • 边车的生命周期与 Pod 生命周期相同:使用与 Pod 中的工作负载容器一起运行的主容器。此方法无法让你控制启动顺序,并且边车容器可能会在工作负载容器退出后阻止 Pod 终止。

内置的边车特性解决了生命周期与 Pod 生命周期相同的场景,并具有以下额外优势:

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

将现有边车过渡到新模型

我们建议在 Alpha 阶段仅对短期存在的测试集群[7]启用边车特性门控。如果你已经有一个被配置为主容器的边车,且它可以在 Pod 的整个生命周期内运行, 则可以将其移至 Pod 规约的 initContainers 部分,并将 restartPolicy 设置为 Always。在许多情况下,边车容器能够继续像以前一样工作,并且额外的好处是可以定义启动顺序,并且不会延长 Pod 的生命周期。

已知的问题

内置的边车容器的 Alpha 版本具有以下已知问题,我们将在将该功能升级为 Beta 之前解决这些问题:

  • CPU、内存、设备和拓扑管理器无法意识到边车容器的生命周期和额外资源使用情况,它们会按照 Pod 资源请求比实际用量低的假设来运行 Pod。
  • 使用边车时,kubectl describe node 命令描述的节点的输出不正确。输出显示的资源使用量低于实际使用量,因为它没有计算边车容器的资源使用量。

我们需要你的反馈!

在 Alpha 阶段,我们希望你在你的环境中尝试边车容器,并在遇到错误或异常点时登记问题。我们对以下方面的反馈特别感兴趣:

  • 关闭顺序,尤其是多个边车一起运行的时候
  • 边车的重启回退超时时间调整
  • 边车运行时 Pod 就绪性和存活性探针的行为

要登记问题,请访问 Kubernetes GitHub 仓库[8]

下一步是什么?

除了要解决的已知问题之外,我们正在努力为边车和主容器添加终止顺序。终止顺序能够确保边车容器仅在 Pod 的主容器退出后才终止。

我们很高兴看到 Kubernetes 引入了边车特性,并对反馈感兴趣。

致谢

自最初的 KEP 编写以来已经过去了很多年,因此如果我们漏掉了多年来致力于此特性的相关人员,请接受我们的道歉。我们尽最大努力去认可参与这项工作的人们。

  • mrunalp[9] 参与了设计讨论和评审
  • thockin[10] 多年来的 API 讨论和支持
  • bobbypage[11] 的评审
  • smarterclayton[12] 的细致评审和反馈
  • howardjohn[13] 多年来的反馈以及在实现过程中的早期尝试
  • derekwaynecarr[14]dchen1107[15] 的领导
  • jpbetz[16] 对 API 和终止排序的设计以及代码评审
  • Joseph-Irving[17]rata[18] 参与多年前的早期迭代设计和评审
  • swatisehgal[19]ffromani[20] 针对有关资源管理器影响所给出的早期反馈
  • alculquicondor[21] 针对与调度程序版本偏差相关的反馈 - wojtek-t[22] 对 KEP 的 PRR 的评审
  • ahg-g[23] 对 KEP 的调度器部分的评审
  • adisky[24] 解决作业完成问题

更多信息

  • 阅读 Kubernetes 文档中的边车容器 API[25]
  • 阅读 Sidecar KEP[26]

参考资料

[1]

博客文章: https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns/

[2]

Init 容器: https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/init-containers/

[3]

特性门控: https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/

[4]

startupProbe: https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-startup-probes

[5]

Pod 终止: https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination

[6]

Istio 中的 Kubernetes 原生边车容器博客文章: https://istio.io/latest/blog/2023/native-sidecars/

[7]

短期存在的测试集群: https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#feature-stages

[8]

Kubernetes GitHub 仓库: https://github.com/kubernetes/kubernetes/issues/new/choose

[9]

mrunalp: https://github.com/mrunalp/

[10]

thockin: https://github.com/thockin/

[11]

bobbypage: https://github.com/bobbypage

[12]

smarterclayton: https://github.com/smarterclayton

[13]

howardjohn: https://github.com/howardjohn

[14]

derekwaynecarr: https://github.com/derekwaynecarr

[15]

dchen1107: https://github.com/dchen1107

[16]

jpbetz: https://github.com/Jpbetz

[17]

Joseph-Irving: https://github.com/Joseph-Irving

[18]

rata: https://github.com/rata

[19]

swatisehgal: https://github.com/swatisehgal

[20]

ffromani: https://github.com/ffromani

[21]

alculquicondor: https://github.com/Alculquicondor

[22]

wojtek-t: https://github.com/Wojtek-t

[23]

ahg-g: https://github.com/ahg-g

[24]

adisky: https://github.com/Adisky

[25]

边车容器 API: https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/init-containers/#api-for-sidecar-containers

[26]

Sidecar KEP: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/753-sidecar-containers/README.md

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2023-08-31,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 程序猿技术大咖 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 在 Kubernetes 1.28 中的边车容器是什么?
  • 何时使用边车容器
  • 1.28 之前用户是如何实现边车行为的?
  • 将现有边车过渡到新模型
  • 已知的问题
  • 我们需要你的反馈!
  • 下一步是什么?
  • 致谢
  • 更多信息
    • 参考资料
    相关产品与服务
    容器服务
    腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
    领券
    问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档