Sidecar 容器

功能状态： Kubernetes v1.29 [beta]

Sidecar 容器是在同一个 Pod 中与主应用程序容器一起运行的辅助容器。这些容器用于通过提供额外的服务或功能（如日志记录、监控、安全或数据同步）来增强或扩展主应用程序容器的功能，而无需直接更改主应用程序代码。

通常，您在一个 Pod 中只有一个应用程序容器。例如，如果您有一个需要本地 Web 服务器的 Web 应用程序，则本地 Web 服务器是一个 Sidecar，而 Web 应用程序本身就是应用程序容器。

Kubernetes 中的 Sidecar 容器

Kubernetes 将 Sidecar 容器实现为 初始化容器 的特例；Sidecar 容器在 Pod 启动后仍然运行。本文档使用术语常规初始化容器来明确指代仅在 Pod 启动期间运行的容器。

只要您的集群启用了 SidecarContainers 功能门控（该功能从 Kubernetes v1.29 开始默认启用），您就可以为 Pod 的 initContainers 字段中列出的容器指定 restartPolicy。这些可重启的Sidecar容器独立于其他初始化容器以及同一个 Pod 中的主应用程序容器。这些可以启动、停止或重启，而不会影响主应用程序容器和其他初始化容器。

您也可以运行多个没有标记为初始化或 Sidecar 容器的容器的 Pod。如果 Pod 中的容器是 Pod 整体正常工作所必需的，但您不需要控制哪些容器先启动或停止，这将是合适的。您也可以在需要支持不支持容器级别 restartPolicy 字段的旧版 Kubernetes 版本时执行此操作。

示例应用程序

这是一个包含两个容器的 Deployment 示例，其中一个容器是 Sidecar

application/deployment-sidecar.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: alpine:latest
          command: ['sh', '-c', 'while true; do echo "logging" >> /opt/logs.txt; sleep 1; done']
          volumeMounts:
            - name: data
              mountPath: /opt
      initContainers:
        - name: logshipper
          image: alpine:latest
          restartPolicy: Always
          command: ['sh', '-c', 'tail -F /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      volumes:
        - name: data
          emptyDir: {}

Sidecar 容器和 Pod 生命周期

如果用其 restartPolicy 设置为 Always 的方式创建初始化容器，它将在 Pod 的整个生命周期中启动并保持运行。这对于运行与主应用程序容器分离的支持服务非常有用。

如果为该初始化容器指定了 readinessProbe，则其结果将用于确定 Pod 的 ready 状态。

由于这些容器被定义为初始化容器，因此它们受益于与常规初始化容器相同的排序和顺序保证，使您能够将 Sidecar 容器与常规初始化容器混合使用以进行复杂的 Pod 初始化流程。

与常规初始化容器相比，在 initContainers 中定义的 Sidecar 在启动后会继续运行。当 Pod 的 .spec.initContainers 中有多个条目时，这一点很重要。在 Sidecar 样式的初始化容器运行后（kubelet 已将该初始化容器的 started 状态设置为 true），kubelet 然后从排序的 .spec.initContainers 列表中启动下一个初始化容器。该状态要么变为 true（因为容器中正在运行一个进程，并且没有定义启动探测），要么是其 startupProbe 成功的结果。

带有 Sidecar 容器的作业

如果您定义一个使用 Kubernetes 样式的初始化容器的作业，则每个 Pod 中的 Sidecar 容器不会阻止作业在主容器完成之后完成。

这是一个包含两个容器的作业示例，其中一个容器是 Sidecar

application/job/job-sidecar.yaml 
apiVersion: batch/v1
kind: Job
metadata:
  name: myjob
spec:
  template:
    spec:
      containers:
        - name: myjob
          image: alpine:latest
          command: ['sh', '-c', 'echo "logging" > /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      initContainers:
        - name: logshipper
          image: alpine:latest
          restartPolicy: Always
          command: ['sh', '-c', 'tail -F /opt/logs.txt']
          volumeMounts:
            - name: data
              mountPath: /opt
      restartPolicy: Never
      volumes:
        - name: data
          emptyDir: {}

与应用程序容器的区别

Sidecar 容器与同一个 Pod 中的应用程序容器一起运行。但是，它们不执行主要应用程序逻辑；相反，它们为主应用程序提供支持功能。

Sidecar 容器有自己独立的生命周期。它们可以独立于应用程序容器启动、停止和重启。这意味着您可以更新、扩展或维护 Sidecar 容器，而不会影响主应用程序。

Sidecar 容器与主容器共享相同的网络和存储命名空间。这种共同定位使它们能够密切交互和共享资源。

与初始化容器的区别

Sidecar 容器与主容器一起工作，扩展其功能并提供附加服务。

Sidecar 容器与主应用程序容器同时运行。它们在 Pod 的整个生命周期中处于活动状态，可以独立于主容器启动和停止。与 初始化容器 不同，Sidecar 容器支持 探测 来控制其生命周期。

Sidecar 容器可以直接与主应用程序容器交互，因为它们与初始化容器一样，始终共享相同的网络，并且可以选择共享卷（文件系统）。

初始化容器在主容器启动之前停止，因此初始化容器无法与 Pod 中的应用程序容器交换消息。任何数据传递都是单向的（例如，初始化容器可以将信息放入 emptyDir 卷中）。

容器内资源共享

鉴于初始化容器、Sidecar 容器和应用程序容器的执行顺序，资源使用适用以下规则

  • 所有初始化容器中定义的任何特定资源请求或限制的最大值是有效初始化请求/限制。如果任何资源没有指定资源限制，则将其视为最高限制。
  • Pod 的有效请求/限制对于某个资源来说，是 Pod 开销 和以下两者中较高的值的总和：
    • 所有非初始化容器（应用程序和 Sidecar 容器）的资源请求/限制之和
    • 某个资源的有效初始化请求/限制
  • 调度是根据有效请求/限制进行的，这意味着初始化容器可以为初始化预留 Pod 生命周期内未使用的资源。
  • Pod 的有效 QoS 等级的 QoS（服务质量）等级与所有初始化容器、Sidecar 容器和应用程序容器的 QoS 等级相同。

配额和限制是根据有效的 Pod 请求和限制应用的。

Sidecar 容器和 Linux cgroup

在 Linux 上，Pod 级控制组（cgroup）的资源分配基于有效的 Pod 请求和限制，与调度器相同。

下一步

上次修改时间：2024 年 3 月 26 日下午 12:17 PST：更新 sidecar-containers.md (1808b6277e)