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 開銷。