1. CNBPA云原生社区首页
  2. 技术分享

Kubernetes 1.28：介绍原生 Sidecar 容器

• 技术分享

一文带你了解如何使用新的边车特性

Kubernetes 1.28：介绍原生 Sidecar 容器

作者：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] 启用时使用。

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] 继续只根据主容器来判定。restartPolicy 为 Always 的所有 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

转载请注明出处：https://www.cloudnative-tech.com/technology/5958.html

赞 (0)
上一篇 2023年8月30日 下午3:35
下一篇 2023年8月31日 下午12:14

相关推荐

  • 云原生架构：开启现代化应用开发和部署 技术分享

    云原生架构：开启现代化应用开发和部署

    本文将深入介绍云原生架构的定义、核心原则、优势与价值，以及关键技术要素。我们还将探讨云原生架构的演进路径和实际应用案例，并针对挑战提供应对策略。最后，我们提供下一步行动指南，帮助您制定云原生架构转型计划并选定适合的工具与平台。

    2023年6月28日
    0
  • 容器平台的适用场景有哪些？ 技术分享

    容器平台的适用场景有哪些？

    本文介绍了容器平台的概念、技术特点和适用场景。容器平台是一种新兴的技术，可以大大简化应用程序的部署和管理，提高效率和可靠性。容器平台适用于云原生应用、微服务架构、持续集成和持续交付、大数据应用和混合云环境等场景。容器平台具有轻量级、可移植性、资源隔离、快速部署和灵活性高等特点。

    2023年5月30日
    0
  • Docker启动容器命令有哪些？ 技术分享

    Docker启动容器命令有哪些？

    Docker是一个流行的容器化平台，可以通过一系列命令来管理和启动容器。下面介绍一些常用的Docker启动容器命令：

    2023年6月1日
    0
  • 云原生服务架构怎么做？ 技术分享

    云原生服务架构怎么做？

    云原生服务架构是一种基于云计算原理和现代化开发方法的应用架构模式，旨在实现高度可伸缩性、灵活性和可靠性的应用交付和管理。云原生服务架构的实施需要综合考虑多个方面，包括应用设计、基础设施架构、开发流程和工具链等。本文将介绍云原生服务架构的关键要素和实施步骤。

    2023年7月4日
    0
  • 容器自动化部署脚本怎么写？ 技术分享

    容器自动化部署脚本怎么写？

    编写容器自动化部署脚本是实现容器化应用的关键步骤之一。下面是一些指导原则，帮助你编写容器自动化部署脚本：

    2023年6月21日
    0