Sidecar 容器
Kubernetes v1.33 [stable] （默认启用：true）Sidecar 容器是与主应用程序容器在同一个 Pod 中运行的辅助容器。这些容器通过提供额外的服务或功能（如日志记录、监控、安全性或数据同步）来增强或扩展主要_应用程序容器_的功能，而无需直接修改主要应用程序代码。
通常，一个 Pod 中只有一个应用程序容器。例如，如果你有一个需要本地 Web 服务器的 Web 应用程序，则本地 Web 服务器是 sidecar，Web 应用程序本身是应用程序容器。
Kubernetes 中的 Sidecar 容器
Kubernetes 将 sidecar 容器实现为 Init 容器 的一种特殊情况；sidecar 容器在 Pod 启动后仍然运行。本文档使用术语_常规 Init 容器_来明确指代仅在 Pod 启动期间运行的容器。
如果你的集群启用了 SidecarContainers 特性门控（从 Kubernetes v1.29 开始，此特性默认处于活动状态），你可以为 Pod 的 initContainers 字段中列出的容器指定 restartPolicy。这些可重启的_sidecar_容器独立于其他 Init 容器和同一个 Pod 中的主应用程序容器。它们可以启动、停止或重启，而不会影响主应用程序容器和其他 Init 容器。
你还可以运行包含多个未标记为 Init 容器或 Sidecar 容器的 Pod。如果 Pod 中的容器是整个 Pod 正常工作所必需的，但你不需要控制哪些容器先启动或停止，则此方法是合适的。如果你需要支持不支持容器级别 restartPolicy 字段的旧版本 Kubernetes，你也可以这样做。
应用程序示例
这是一个包含两个容器的 Deployment 示例，其中一个容器是 sidecar
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 生命周期
如果 Init 容器的 restartPolicy 设置为 Always，它将在 Pod 的整个生命周期内启动并保持运行。这对于运行与主应用程序容器分离的支持服务很有帮助。
如果为这个 Init 容器指定了 readinessProbe，其结果将用于确定 Pod 的 ready 状态。
由于这些容器被定义为 Init 容器，它们享有与常规 Init 容器相同的排序和顺序保证，允许你将 sidecar 容器与常规 Init 容器混合使用，以实现复杂的 Pod 初始化流程。
与常规 Init 容器相比，在 initContainers 中定义的 sidecar 容器在启动后会继续运行。当 Pod 的 .spec.initContainers 中有多个条目时，这一点很重要。当 sidecar 风格的 Init 容器运行后（kubelet 将该 Init 容器的 started 状态设置为 true），kubelet 会从有序的 .spec.initContainers 列表中启动下一个 Init 容器。该状态变为 true 是因为容器中有一个进程正在运行且未定义启动探测，或者是其 startupProbe 成功的结果。
在 Pod 终止 时，kubelet 会推迟终止 sidecar 容器，直到主应用程序容器完全停止。然后，sidecar 容器将以其在 Pod 规范中出现的相反顺序关闭。这种方法确保 sidecar 容器保持运行，支持 Pod 中的其他容器，直到不再需要其服务。
带 Sidecar 容器的 Job
如果你定义了一个使用 Kubernetes 风格 Init 容器的 Job，其中包含 sidecar 容器，则每个 Pod 中的 sidecar 容器不会阻止 Job 在主容器完成后终止。
这是一个包含两个容器的 Job 示例，其中一个容器是 sidecar
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 容器与主容器共享相同的网络和存储命名空间。这种共置允许它们密切交互和共享资源。
从 Kubernetes 的角度来看，sidecar 容器的优雅终止不那么重要。当其他容器占据所有分配的优雅终止时间时，sidecar 容器将在其有机会优雅终止之前收到 SIGTERM 信号，然后是 SIGKILL 信号。因此，sidecar 容器在 Pod 终止时退出代码非 0（0 表示成功退出）是正常的，外部工具通常应忽略它们。
与 Init 容器的区别
Sidecar 容器与主容器协同工作，扩展其功能并提供额外服务。
Sidecar 容器与主应用程序容器同时运行。它们在 Pod 的整个生命周期中都处于活动状态，并且可以独立于主容器启动和停止。与 Init 容器 不同，sidecar 容器支持 探测 来控制其生命周期。
Sidecar 容器可以直接与主应用程序容器交互，因为它们像 Init 容器一样始终共享相同的网络，并且还可以选择共享卷（文件系统）。
Init 容器在主容器启动之前停止，因此 Init 容器不能与 Pod 中的应用程序容器交换消息。任何数据传递都是单向的（例如，Init 容器可以将信息放入 emptyDir 卷中）。
更改 sidecar 容器的镜像不会导致 Pod 重启，但会触发容器重启。
容器内资源共享
考虑到 Init 容器、sidecar 容器和应用程序容器的执行顺序，以下资源使用规则适用：
- 所有 Init 容器上定义的任何特定资源请求或限制的最高值是_有效 Init 请求/限制_。如果任何资源未指定资源限制，则将其视为最高限制。
- Pod 的资源的_有效请求/限制_是 Pod 开销 与以下两者中的较高者的总和：
- 所有非 Init 容器（应用程序和 sidecar 容器）的资源请求/限制总和
- 资源的有效 Init 请求/限制
- 调度是根据有效请求/限制进行的，这意味着 Init 容器可以为初始化保留资源，这些资源在 Pod 的生命周期内不使用。
- Pod 的_有效 QoS 层级_的 QoS（服务质量）层级与所有 Init 容器、sidecar 容器和应用程序容器的 QoS 层级相同。
配额和限制根据 Pod 的有效请求和限制应用。
Sidecar 容器和 Linux cgroups
在 Linux 上，Pod 级别控制组 (cgroups) 的资源分配是基于 Pod 的有效请求和限制，与调度程序相同。
下一步
- 了解如何 采用 Sidecar 容器
- 阅读关于 原生 sidecar 容器 的博客文章。
- 阅读关于 创建具有 Init 容器的 Pod。
- 了解 探测类型：存活探测、就绪探测、启动探测。
- 了解 Pod 开销。