大家好，我是Tony Bai。

將Go應(yīng)用部署到Kubernetes已經(jīng)是許多團隊的標配。在這個強大的容器編排平臺上，除了運行我們的核心Go服務(wù)容器，Kubernetes還提供了一種靈活的設(shè)計模式——多容器Pod。通過在同一個Pod內(nèi)運行多個容器，我們可以實現(xiàn)諸如初始化、功能擴展、適配轉(zhuǎn)換等多種輔助功能，其中最知名的就是Sidecar模式。

這些“輔助容器”就像我們Go應(yīng)用的“最佳拍檔”，在某些場景下能發(fā)揮奇效。然而，正如 Kubernetes官方文檔和社區(qū)討論一直強調(diào)的那樣，引入額外的容器并非沒有成本。每一個額外的容器都會增加復(fù)雜度、資源消耗和潛在的運維開銷。

因此，關(guān)鍵在于策略性地使用這些模式。我們不應(yīng)將其視為默認選項，而應(yīng)是解決特定架構(gòu)挑戰(zhàn)的精密工具。今天，我們就來聊聊Kubernetes中幾種合理且常用的多容器Pod模式，探討何時應(yīng)該為我們的Go應(yīng)用引入這些“拍檔”，以及如何更好地利用Kubernetes v1.33中已正式穩(wěn)定（GA）的原生Sidecar支持來實現(xiàn)它們。

首先：警惕復(fù)雜性！優(yōu)先考慮更簡單的替代方案

在深入探討具體模式之前，務(wù)必牢記一個核心原則：非必要，勿增實體。

對于Go這種擁有強大標準庫和豐富生態(tài)的語言來說，許多常見的橫切關(guān)注點（如日志記錄、指標收集、配置加載、基本的HTTP客戶端邏輯等）往往可以通過引入高質(zhì)量的Go庫在應(yīng)用內(nèi)部更輕量、更高效地解決。

只有當以下情況出現(xiàn)時，才應(yīng)認真考慮引入多容器模式：

• 需要擴展或修改無法觸碰源代碼的應(yīng)用（如第三方應(yīng)用或遺留系統(tǒng)）。
• 需要將與語言無關(guān)的通用功能（如網(wǎng)絡(luò)代理、安全策略）從主應(yīng)用中解耦出來。
• 需要獨立于主應(yīng)用進行更新或擴展的輔助功能。
• 特定的初始化或適配需求無法在應(yīng)用內(nèi)部優(yōu)雅處理。

切忌為了“看起來很酷”或“遵循某種時髦架構(gòu)”而盲目添加容器。

下面我們看看常見的一些多容器模式以及對應(yīng)的應(yīng)用場景。

四種推薦的多容器模式及其Go應(yīng)用場景

Kubernetes生態(tài)中已經(jīng)沉淀出了幾種非常實用且目標明確的多容器模式，我們逐一來看一下。

Init Container (初始化容器)

Init Container是K8s最早支持的一種“sidecar”(那時候還不這么叫)，它一般用在主應(yīng)用容器啟動之前，執(zhí)行一次性的關(guān)鍵設(shè)置任務(wù)。它會運行至完成然后終止。

它常用于以下場景：

• 運行數(shù)據(jù)庫Schema遷移。
• 預(yù)加載配置或密鑰。
• 檢查依賴服務(wù)就緒。
• 準備共享數(shù)據(jù)卷。

下面是官方的一個init containers的示例：

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app.kubernetes.io/name: MyApp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]

此示例定義了一個包含兩個init容器的簡單Pod。第一個init容器(init-myservice)等待myservice運行，第二個init容器(init-mydb)等待mydb運行。兩個init容器完成后，Pod將從其spec部分運行app容器(myapp-container)。

Ambassador (大使容器)

Ambassador Container主要是用于扮演主應(yīng)用容器的“網(wǎng)絡(luò)大使”，簡化其與外部服務(wù)的交互，它常用在下面一些場景里：

• 服務(wù)發(fā)現(xiàn)與負載均衡代理。
• 請求重試與熔斷。
• 身份驗證與授權(quán)代理。
• mTLS 加密通信。

Ambassador通常作為Pod內(nèi)的一個長期運行的容器。如果需要確保它在主應(yīng)用之后停止（例如處理完最后的請求轉(zhuǎn)發(fā)），Kubernetes原生Sidecar是實現(xiàn)Ambassador容器的理想選擇。

Configuration Helper (配置助手)

配置助手也是一種最常使用的輔助容器模式，它主要用于動態(tài)地為正在運行的主應(yīng)用提供或更新配置，比如監(jiān)控ConfigMap/Secret變化并熱加載、從配置中心拉取配置等。

它通常也是一個長期運行的容器。由于可能需要在主應(yīng)用啟動前提供初始配置，并在主應(yīng)用停止后同步最后狀態(tài)，使用原生Sidecar提供的精確生命周期管理非常有價值，可以使用Sidecar實現(xiàn)這種模式的容器。

Adapter (適配器容器)

Adapter容器負責在主應(yīng)用和外部世界之間進行數(shù)據(jù)格式、協(xié)議或API的轉(zhuǎn)換，常用于下面一些場景：

• 統(tǒng)一監(jiān)控指標格式。
• 協(xié)議轉(zhuǎn)換（如 gRPC 轉(zhuǎn) REST）。
• 標準化日志輸出。
• 兼容遺留系統(tǒng)接口。

我們可以根據(jù)是否需要精確的生命周期協(xié)調(diào)來選擇普通容器或原生Sidecar來實現(xiàn)這類長期運行的適配器容器。

可見，K8s原生的Sidecar是實現(xiàn)上述四種輔助容器的可靠實現(xiàn)，下面來簡單介紹一下K8s原生Sidecar。

K8s原生Sidecar：可靠實現(xiàn)輔助容器的關(guān)鍵

現(xiàn)在，我們重點關(guān)注Kubernetes v1.33中正式穩(wěn)定（GA）的原生Sidecar 功能。

它是如何實現(xiàn)的呢？

官方推薦的方式是：在Pod的spec.initContainers數(shù)組中定義你的Sidecar容器，并顯式地將其restartPolicy設(shè)置為Always。下面是一個示例：

spec:
  initContainers:
    - name: my-sidecar # 例如日志收集或網(wǎng)絡(luò)代理
      image: my-sidecar-image:latest
      restartPolicy: Always # <--- 關(guān)鍵：標記為原生Sidecar
      # ... 其他配置 ...
  containers:
    - name: my-go-app
      image: my-golang-app:latest
      # ...

雖然將長期運行的容器放在initContainers里初看起來可能有些“反直覺”，但這正是Kubernetes團隊為了復(fù)用Init Container已有的啟動順序保證，并賦予其特殊生命周期管理能力而精心設(shè)計的穩(wěn)定機制。

原生Sidecar具有如下的核心優(yōu)勢：

• 可靠的啟動行為： 所有非Sidecar的 Init Containers (restartPolicy 不是 Always) 會按順序執(zhí)行且必須成功完成。隨后，主應(yīng)用容器 (spec.containers) 和所有原生 Sidecar 并發(fā)啟動。
• 優(yōu)雅的關(guān)閉順序保證：這是最大的改進！當 Pod 終止時，主應(yīng)用容器先收到SIGTERM 并等待其完全停止（或超時），然后Sidecar容器才會收到 SIGTERM 開始關(guān)閉。
• 與Job 的良好協(xié)作： 對于設(shè)置了 restartPolicy: OnFailure或Never的Job，原生Sidecar不會因為自身持續(xù)運行而阻止Job的成功完成。

這對我們的Go應(yīng)用意味著什么？

當你的Go應(yīng)用確實需要一個長期運行的輔助容器，并且需要精確的生命周期協(xié)調(diào)時，原生Sidecar提供了實實在在的好處：

• 服務(wù)網(wǎng)格代理 (Ambassador 變種): Envoy, Linkerd proxy 等可以確保在 Go 應(yīng)用處理完最后請求后才關(guān)閉，極大提升可靠性。
• 日志/監(jiān)控收集 (Adapter/Helper 變種): Fluentd, Vector, OTel Collector 等可以確保捕獲到 Go 應(yīng)用停止前的最后狀態(tài)信息。
• 需要與主應(yīng)用生命周期緊密配合的其他輔助服務(wù): 任何需要在主應(yīng)用運行期間持續(xù)提供服務(wù)，并在主應(yīng)用結(jié)束后才停止的場景。

因此，原生Sidecar不是一個全新的模式，而是當我們需要實現(xiàn)上述這些需要精確生命周期管理的Sidecar模式時，Kubernetes v1.33 提供的穩(wěn)定、可靠且官方推薦的實現(xiàn)方式。

小結(jié)

Kubernetes的多容器Pod模式為我們提供了強大的工具箱，但也伴隨著額外的復(fù)雜性。對于Go開發(fā)者而言：

• 始終將簡單性放在首位： 優(yōu)先考慮使用 Go 語言自身的庫和能力來解決問題。
• 審慎評估必要性： 只有當明確的應(yīng)用場景（如 Init, Ambassador, Config Helper, Adapter）帶來的好處大于其引入的復(fù)雜度和資源開銷時，才考慮使用多容器模式。
• 理解模式目的： 清晰地知道你引入的每個輔助容器是為了解決什么特定問題。
• 擁抱原生 Sidecar (GA): 當你確定需要一個長期運行且需要可靠生命周期管理的輔助容器時，利用 Kubernetes v1.33 及以后版本中穩(wěn)定提供的原生 Sidecar 支持，是提升部署健壯性的最佳實踐。

多容器 Pod 是 Kubernetes 生態(tài)中的“精密武器”，理解何時拔劍、如何出鞘，并善用平臺提供的穩(wěn)定特性，才能真正發(fā)揮其威力，為我們的 Go 應(yīng)用保駕護航。

你通常在什么場景下為你的 Go 應(yīng)用添加輔助容器？你對 K8s 原生 Sidecar 功能的穩(wěn)定有何看法？

參考資料

• Init Containers - https://kubernetes.io/docs/concepts/workloads/pods/init-containers/ Pod Sidecar 
• Containers - https://kubernetes.io/docs/tutorials/configuration/pod-sidecar-containers/ 
• Sidecar Containers - https://kubernetes.io/docs/concepts/workloads/pods/sidecar-containers/ 
• Kubernetes v1.33: Octarine - https://kubernetes.io/blog/2025/04/23/kubernetes-v1-33-release/ 
• Sidecar Containers - https://github.com/kubernetes/enhancements/issues/753