Kubernetes 多容器 Pod 概述

隨著雲原生架構的不斷演進，Kubernetes 已成為部署複雜分散式系統的首選平臺。在這個生態系統中，Sidecar 模式是最強大但又最微妙的設計模式之一，它允許開發人員在不深入研究原始碼的情況下擴充套件應用程式功能。

Sidecar 模式的起源

把 Sidecar 想象成一個可靠的摩托車邊鬥。從歷史上看，IT 基礎設施總是使用輔助服務來處理關鍵任務。在容器出現之前，我們依靠後臺程序和輔助守護程序來管理日誌、監控和網路。微服務革命改變了這種方法，使 Sidecar 成為一種結構化和有意的架構選擇。隨著微服務的興起，Sidecar 模式的定義變得更加清晰，允許開發人員從主服務中解除安裝特定職責，而無需更改其程式碼。像 Istio 和 Linkerd 這樣的服務網格推廣了 Sidecar 代理，展示了這些伴隨容器如何優雅地處理分散式系統中的可觀測性、安全性和流量管理。

Kubernetes 實現

在 Kubernetes 中，Sidecar 容器與主應用程式在同一個 Pod 中執行，從而實現通訊和資源共享。這聽起來是不是就像在 Pod 中將多個容器並排定義一樣？確實如此，在 Kubernetes v1.29.0 引入對 Sidecar 的原生支援之前，Sidecar 容器必須這樣實現。Sidecar 容器現在可以使用 spec.initContainers 欄位在 Pod 清單中定義。使其成為 Sidecar 容器的是你將其指定為 restartPolicy: Always。你可以在下面看到一個例子，這是完整 Kubernetes 清單的部分程式碼片段。

initContainers:
  - name: logshipper
    image: alpine:latest
    restartPolicy: Always
  command: ['sh', '-c', 'tail -F /opt/logs.txt']
    volumeMounts:
    - name: data
        mountPath: /opt

spec.initContainers 這個欄位名可能會讓人困惑。為什麼想要定義一個 Sidecar 容器，卻必須在 spec.initContainers 陣列中新增一個條目？spec.initContainers 在主應用程式啟動前執行至完成，所以它們是一次性的，而 Sidecar 通常與主應用程式容器並行執行。正是帶有 restartPolicy:Always 的 spec.initContainers 將經典的 Init 容器與 Kubernetes 原生的 Sidecar 容器區分開來，並確保它們始終處於執行狀態。

何時擁抱（或避免）Sidecar

雖然 Sidecar 模式在許多情況下都很有用，但除非用例證明其合理性，否則它通常不是首選方法。新增 Sidecar 會增加複雜性、資源消耗和潛在的網路延遲。相反，應首先考慮更簡單的替代方案，例如內建庫或共享基礎設施。

在以下情況下部署 Sidecar

1. 你需要擴充套件應用程式功能而不觸及原始程式碼
2. 實現日誌記錄、監控或安全等橫切關注點
3. 與需要現代網路功能的遺留應用程式一起工作
4. 設計需要獨立擴充套件和更新的微服務

在以下情況下請謹慎操作

1. 資源效率是你的主要關注點
2. 最小網路延遲至關重要
3. 存在更簡單的替代方案
4. 你希望最大限度地減少故障排查的複雜性

四種基本的多容器模式

Init 容器模式

Init 容器模式用於在主應用程式容器啟動前執行（通常是關鍵的）設定任務。與常規容器不同，Init 容器執行至完成然後終止，確保主應用程式的先決條件得到滿足。

適用於

1. 準備配置
2. 載入 Secret
3. 驗證依賴項的可用性
4. 執行資料庫遷移

Init 容器確保你的應用程式在可預測、受控的環境中啟動，而無需修改程式碼。

Ambassador 模式

Ambassador 容器提供 Pod 本地的輔助服務，暴露一種簡單的方式來訪問網路服務。通常，Ambassador 容器代表應用程式容器傳送網路請求，並處理服務發現、對等身份驗證或傳輸中加密等挑戰。

在你需要時非常完美

1. 解除安裝客戶端連線問題
2. 實現與語言無關的網路功能
3. 新增 TLS 等安全層
4. 建立強大的熔斷器和重試機制

配置助手

一個**配置助手（Configuration Helper）** Sidecar 動態地為應用程式提供配置更新，確保它始終可以訪問最新的設定而不會中斷服務。通常，助手需要在應用程式能夠成功啟動之前提供初始配置。

使用場景

1. 獲取環境變數和 Secret
2. 輪詢配置更改
3. 將配置管理與應用程式邏輯解耦

Adapter 模式

一個 **Adapter**（有時也稱為 **Facade**）容器透過轉換資料格式、協議或 API，實現主應用程式容器與外部服務之間的互操作性。

優勢

1. 轉換遺留資料格式
2. 橋接通訊協議
3. 促進不匹配服務之間的整合

總結

雖然 Sidecar 模式提供了巨大的靈活性，但它們並非萬能藥。每個增加的 Sidecar 都會引入複雜性，消耗資源，並可能增加運維開銷。始終首先評估更簡單的替代方案。關鍵在於戰略性實施：將 Sidecar 用作解決特定架構挑戰的精確工具，而不是預設方法。當正確使用時，它們可以改善容器化環境中的安全性、網路和配置管理。明智選擇，謹慎實施，讓你的 Sidecar 提升你的容器生態系統。

• ←上一篇
• 下一篇→