大家好，我是Tony Bai。

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

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

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

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

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

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

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

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

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

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

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

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

Init Container (初始化容器)

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

它常用于以下場景：

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

下面是官方的一個(gè)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"]

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

Ambassador (大使容器)

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

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

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

Configuration Helper (配置助手)

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

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

Adapter (適配器容器)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

小結(jié)

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

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

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

你通常在什么場景下為你的 Go 應(yīng)用添加輔助容器？你對(duì) 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