邊車容器
Kubernetes v1.29 [beta]邊車容器是與主要應用程式容器在同一個 Pod 中一起執行的次要容器。這些容器用於增強或擴展主要應用程式容器的功能，方法是提供額外的服務或功能，例如記錄、監控、安全性或資料同步，而無需直接變更主要應用程式程式碼。
一般而言，您在 Pod 中只會有一個應用程式容器。例如，如果您有一個需要本機網頁伺服器的網頁應用程式，則本機網頁伺服器是邊車容器，而網頁應用程式本身是應用程式容器。
Kubernetes 中的邊車容器
Kubernetes 將邊車容器實作為初始化容器的特殊情況；邊車容器在 Pod 啟動後仍保持執行。本文件使用常規初始化容器一詞，清楚地指僅在 Pod 啟動期間執行的容器。
假設您的叢集已啟用 SidecarContainers 功能閘道（此功能自 Kubernetes v1.29 起預設為啟用），您可以為 Pod 的 initContainers 欄位中列出的容器指定 restartPolicy。這些可重新啟動的邊車容器獨立於其他 init 容器以及相同 Pod 內的主要應用程式容器。這些容器可以啟動、停止或重新啟動，而不會影響主要應用程式容器和其他 init 容器。
您也可以執行具有多個未標記為 init 或邊車容器的 Pod。如果 Pod 內的多個容器是 Pod 整體運作所必需的，而且您不需要控制哪些容器先啟動或停止，則此方法很適用。如果您需要支援不支援容器層級 restartPolicy 欄位的舊版 Kubernetes，您也可以這樣做。
範例應用程式
以下是一個 Deployment 範例，其中包含兩個容器，其中一個是邊車容器
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: {}邊車容器和 Pod 生命週期
如果 init 容器建立時將其 restartPolicy 設定為 Always，則它將在 Pod 的整個生命週期內啟動並保持執行。這對於執行與主要應用程式容器分離的支援服務非常有用。
如果為此 init 容器指定了 readinessProbe，則其結果將用於判斷 Pod 的 ready 狀態。
由於這些容器被定義為 init 容器，因此它們受益於與常規 init 容器相同的排序和順序保證，允許您將邊車容器與常規 init 容器混合使用，以實現複雜的 Pod 初始化流程。
與常規 init 容器相比，在 .spec.initContainers 內定義的邊車容器在啟動後會繼續執行。當 Pod 的 .spec.initContainers 內有多個條目時，這一點很重要。在邊車樣式的 init 容器執行後（kubelet 已將該 init 容器的 started 狀態設定為 true），kubelet 接著從排序後的 .spec.initContainers 列表中啟動下一個 init 容器。該狀態會變為 true，原因可能是容器中正在執行進程且未定義啟動探針，或是因為其 startupProbe 成功。
在 Pod 終止時，kubelet 會延遲終止邊車容器，直到主要應用程式容器完全停止。然後，邊車容器會按照它們在 Pod 規格中出現的相反順序關閉。這種方法確保邊車容器保持運作，支援 Pod 內的其他容器，直到不再需要它們的服務為止。
具有邊車容器的 Job
如果您定義一個使用 Kubernetes 樣式 init 容器的 Job，則每個 Pod 中的邊車容器不會阻止 Job 在主要容器完成後完成。
以下是一個 Job 範例，其中包含兩個容器，其中一個是邊車容器
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: {}與應用程式容器的差異
邊車容器與同一個 Pod 中的應用程式容器並排執行。但是，它們不執行主要應用程式邏輯；相反地，它們為主要應用程式提供支援功能。
邊車容器有自己獨立的生命週期。它們可以獨立於應用程式容器啟動、停止和重新啟動。這表示您可以更新、擴展或維護邊車容器，而不會影響主要應用程式。
邊車容器與主要容器共用相同的網路和儲存命名空間。這種共置允許它們緊密互動並共享資源。
從 Kubernetes 的角度來看，邊車容器的正常終止不太重要。當其他容器佔用所有分配的正常終止時間時，邊車容器將比預期的更快收到 SIGTERM，隨後是 SIGKILL。因此，對於邊車容器，與 0 不同的退出代碼（0 表示成功退出）在 Pod 終止時是正常的，並且通常應被外部工具忽略。
與 init 容器的差異
邊車容器與主要容器並排工作，擴展其功能並提供額外服務。
邊車容器與主要應用程式容器同時執行。它們在 Pod 的整個生命週期中處於活動狀態，並且可以獨立於主要容器啟動和停止。與 init 容器不同，邊車容器支援 探針 來控制其生命週期。
邊車容器可以直接與主要應用程式容器互動，因為與 init 容器一樣，它們始終共享相同的網路，並且可以選擇性地共享磁碟區（檔案系統）。
Init 容器在主要容器啟動之前停止，因此 init 容器無法與 Pod 中的應用程式容器交換訊息。任何資料傳遞都是單向的（例如，init 容器可以將資訊放入 emptyDir 磁碟區中）。
容器內的資源共享
考慮到 init 容器、邊車容器和應用程式容器的執行順序，以下資源使用規則適用
- 在所有 init 容器上定義的任何特定資源請求或限制中的最高值是有效 init 請求/限制。如果任何資源未指定資源限制，則視為最高限制。
- Pod 的資源有效請求/限制是 Pod 額外開銷 與以下兩者中較高者的總和
- 所有非 init 容器（應用程式容器和邊車容器）的資源請求/限制的總和
- 資源的有效 init 請求/限制
- 排程是根據有效請求/限制完成的，這表示 init 容器可以為初始化保留在 Pod 生命週期內未使用的資源。
- Pod 的 有效 QoS 層級的 QoS（服務品質）層級是所有 init 容器、邊車容器和應用程式容器的 QoS 層級。
配額和限制根據有效的 Pod 請求和限制套用。
邊車容器和 Linux cgroups
在 Linux 上，Pod 層級控制群組 (cgroups) 的資源分配基於有效的 Pod 請求和限制，與排程器相同。
下一步
- 了解如何採用邊車容器
- 閱讀關於原生邊車容器的部落格文章。
- 閱讀關於建立具有 init 容器的 Pod。
- 了解探針類型：存活探針、就緒探針、啟動探針。
- 了解Pod 額外開銷。