本文已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Kubernetes v1.28：原生 Sidecar 容器簡介

作者：Todd Neal (AWS), Matthias Bertschy (ARMO), Sergey Kanzhelev (Google), Gunju Kim (NAVER), Shannon Kularathna (Google) |

這篇文章說明如何使用新的 Sidecar 功能，該功能啟用可重新啟動的 Init Container，並且在 Kubernetes 1.28 的 Alpha 版本中可用。我們希望收到您的回饋，以便我們能夠盡快將此功能升級。

「Sidecar」的概念幾乎從一開始就已成為 Kubernetes 的一部分。在 2015 年，Sidecar 在一篇關於複合容器的部落格文章中被描述為「擴展和增強『主要』容器」的附加容器。Sidecar 容器已成為常見的 Kubernetes 部署模式，並且經常被用於網路代理或作為日誌記錄系統的一部分。到目前為止，Sidecar 仍然是 Kubernetes 使用者在沒有原生支援的情況下應用的概念。缺乏原生支援導致了一些使用上的摩擦，而此增強功能旨在解決此問題。

1.28 版本中的 Sidecar 容器是什麼？

Kubernetes 1.28 在 Init Container 中新增了一個新的 restartPolicy 欄位，當啟用 SidecarContainers 功能閘道 時，該欄位可用。

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 Container 的行為，如下所示：

  • 容器在退出時重新啟動
  • 任何後續的 Init Container 在 startupProbe 成功完成後立即啟動，而不是等待可重新啟動的 Init Container 退出
  • Pod 的資源使用計算發生變化，因為可重新啟動的 Init Container 資源現在被添加到主要容器的資源請求總和中

Pod 終止 仍然僅取決於主要容器。restartPolicy 為 Always 的 Init Container（名為 Sidecar）不會阻止 Pod 在主要容器退出後終止。

可重新啟動的 Init Container 的以下屬性使其非常適合 Sidecar 部署模式：

  • 無論您是否設定 restartPolicy，Init Container 都具有明確定義的啟動順序，因此您可以確保您的 Sidecar 在資訊清單中 Sidecar 宣告之後的任何容器宣告之前啟動。
  • Sidecar 容器不會延長 Pod 的生命週期，因此您可以在生命週期短暫的 Pod 中使用它們，而無需更改 Pod 的生命週期。
  • Sidecar 容器在退出時重新啟動，這提高了彈性，並讓您可以使用 Sidecar 來提供您的主要容器可以更可靠地使用的服務。

何時使用 Sidecar 容器

您可能會發現內建的 Sidecar 容器對於以下工作負載很有用：

  • 批次或 AI/ML 工作負載，或其他運行至完成的 Pod。這些工作負載將體驗到最顯著的好處。
  • 在資訊清單中任何其他容器之前啟動的網路代理。運行的每個其他容器都可以使用代理容器的服務。有關說明，請參閱 Istio 部落格文章中的 Kubernetes 原生 Sidecar。
  • 日誌收集容器，現在可以在任何其他容器之前啟動並運行直到 Pod 終止。這提高了 Pod 中日誌收集的可靠性。
  • Jobs，可以使用 Sidecar 進行任何目的，而 Job 完成不會被運行的 Sidecar 阻止。無需額外配置即可確保此行為。

在 1.28 版本之前，使用者如何獲得 Sidecar 行為？

在 Sidecar 功能之前，以下選項可用於實作 Sidecar 行為，具體取決於 Sidecar 容器的所需生命週期：

  • Sidecar 的生命週期短於 Pod 的生命週期：使用 Init Container，它提供明確定義的啟動順序。但是，Sidecar 必須退出才能啟動其他 Init Container 和主要 Pod 容器。
  • Sidecar 的生命週期等於 Pod 的生命週期：使用與 Pod 中的工作負載容器並排運行的主要容器。此方法無法讓您控制啟動順序，並讓 Sidecar 容器在工作負載容器退出後可能會阻止 Pod 終止。

內建的 Sidecar 功能解決了生命週期等於 Pod 生命週期的使用案例，並具有以下額外好處：

  • 提供對啟動順序的控制
  • 不會阻止 Pod 終止

將現有的 Sidecar 轉換為新模型

我們建議僅在 生命週期短暫的測試叢集 的 Alpha 階段使用 Sidecar 功能閘道。如果您有現有的 Sidecar 配置為主要容器，以便它可以運行 Pod 的生命週期，則可以將其移動到 Pod Spec 的 initContainers 部分，並給予 restartPolicy 為 Always。在許多情況下，Sidecar 應該像以前一樣工作，並具有定義的啟動順序且不會延長 Pod 生命週期的額外好處。

已知問題

內建 Sidecar 容器的 Alpha 版本具有以下已知問題，我們將在將該功能升級到 Beta 版本之前解決這些問題：

  • CPU、記憶體、裝置和拓撲管理器不知道 Sidecar 容器的生命週期和額外資源使用量，並且會像 Pod 的資源請求低於實際請求一樣運行。
  • 當使用 Sidecar 時，kubectl describe node 的輸出不正確。輸出顯示的資源使用量低於實際使用量，因為它沒有對 Sidecar 容器使用新的資源使用計算。

我們需要您的回饋！

在 Alpha 階段，我們希望您在您的環境中試用 Sidecar 容器，如果您遇到錯誤或摩擦點，請開啟 Issue。我們特別感興趣的是關於以下內容的回饋：

  • 關閉順序，尤其是當多個 Sidecar 運行時
  • 崩潰的 Sidecar 的退避逾時調整
  • 當 Sidecar 運行時，Pod 就緒和存活探針的行為

若要開啟 Issue，請參閱 Kubernetes GitHub 儲存庫。

下一步是什麼？

除了將要解決的已知問題外，我們還致力於為 Sidecar 和主要容器新增終止順序。這將確保 Sidecar 容器僅在 Pod 的主要容器退出後終止。

我們很高興看到 Sidecar 功能進入 Kubernetes，並對回饋感興趣。

致謝

自最初的 KEP 撰寫以來已經過去了很多年，因此如果我們遺漏了多年來參與此功能的任何人，我們深感抱歉。這是盡力表彰參與此工作的人員。

更多資訊