服務網格ASM支援以Sidecar模式或Sidecarless模式為叢集中的應用部署網格代理,以實現對底層網路功能的抽象化管理,例如負載平衡、服務發現、流量控制、安全性增強、流量可觀測等。ASM通過Sidecar模式將網格代理容器加入到Pod,讓網格代理容器與應用程式容器共同部署在同一Pod中、共用相同的網路命名空間,並使得網格代理透明地攔截和處理應用程式容器的入站和出站流量。本文主要介紹在ASM中使用原生Sidecar方式部署網格代理。
傳統Sidecar與原生Sidecar
對比項 | 傳統Sidecar | 原生Sidecar |
受支援K8s版本 | 1.2~1.28。 | 1.28及以上。 |
受支援ASM版本 | 1.22以下版本的ASM執行個體。 | 1.22及以上版本ASM執行個體添加1.30及以上版本的Kubernetes叢集(ACK、ACK Serverless或ACS叢集)時,預設將以原生Sidecar方式部署網格代理。 |
部署方式 | Sidecar容器與主容器都配置在 | Sidecar容器配置 |
生命週期 | 無法與主容器同步,需要單獨管理。 | 與主容器同步,無需額外配置。 |
傳統Sidecar方式的網格代理實際上作為Pod中的普通容器與應用程式容器一同部署,並分別擁有各自的生命週期。這可能會產生以下的已知問題:
如果應用程式容器啟動速度比Sidecar代理容器快,則應用程式容器將無法訪問網路。我們可以通過配置Sidecar優雅啟動來解決此問題,但在Sidecar代理啟動速度較慢時仍然可能出現問題。具體操作,請參見Sidecar優雅啟動。
如果Sidecar代理容器先於應用程式容器關閉,則應用程式容器無法訪問網路。我們可以通過配置Sidecar優雅終止來解決此問題,但可能會導致Pod終止時間延長。具體操作,請參見Sidecar優雅終止。
如果Job類應用程式容器運行結束後退出,Sidecar代理容器仍將運行並保持Pod無限期運行。
在 Sidecar代理容器啟動之前啟動並執行
initContainers
將無法訪問網路。通常我們可以通過設定部分出口流量免於經過Sidecar代理來繞過此問題。具體操作,請參見不攔截對外訪問的位址範圍。
如何確認網格代理是否以原生Sidecar方式部署
當您看到Pod的initContainers
欄位中存在istio-proxy
容器,並且容器配置中包含restartPolicy: Always
欄位時,則網格代理正在以原生Sidecar方式部署。例如:
apiVersion: v1
kind: Pod
metadata:
name: sleep-xxxxxxxx-xxxxx
namespace: default
spec:
containers:
...
image: 'registry.cn-hangzhou.aliyuncs.com/acs/curl:8.1.2'
imagePullPolicy: IfNotPresent
name: sleep
...
initContainers:
...
image: registry-cn-hangzhou-vpc.ack.aliyuncs.com/acs/proxyv2:v1.22.2.35-ge64ec8af-aliyun
imagePullPolicy: IfNotPresent
name: istio-proxy
ports:
- containerPort: 15090
name: http-envoy-prom
protocol: TCP
restartPolicy: Always # 包含此欄位則表示使用原生sidecar方式部署
...
在這種模式下,所有與Sidecar代理生命週期相關的Sidecar代理配置都將失效(因為原生Sidecar不再需要這些配置)。更多資訊,請參見配置Sidecar代理。
如何切換回傳統Sidecar代理部署方式
如果您的叢集中還部署了一些依賴較老K8s版本,且會修改Pod定義的MutatingWebhook組件(如kubesphere的logsidecar-injector),這些組件可能會刪除原生Sidecar的定義,導致建立失敗。您可能需要切換回傳統Sidecar代理部署模式,以保持和老版本MutatingWebhook的相容性。
具體操作步驟如下:
使用kubectl串連到ASM執行個體。具體操作,請參見通過控制面kubectl訪問Istio資源。
執行以下命令,為
asmmeshconfig
資源追加配置。kubectl patch asmmeshconfig default --type=merge --patch='{"spec":{"enableNativeSidecar":false}}'
預期輸出:
asmmeshconfig.istio.alibabacloud.com/default patched
手動重啟Pod。具體操作,請參見重新部署工作負載。
執行以下命令,再次查看Pod資訊。
kubectl get pod sleep-xxxxxxxx-xxxxx -o yaml
預期輸出:
apiVersion: v1 kind: Pod metadata: name: sleep-xxxxxxxx-xxxxx namespace: default spec: containers: ... image: registry-cn-hangzhou-vpc.ack.aliyuncs.com/acs/proxyv2:v1.22.2.35-ge64ec8af-aliyun name: istio-proxy ports: - containerPort: 15090 name: http-envoy-prom protocol: TCP ... image: 'registry.cn-hangzhou.aliyuncs.com/acs/curl:8.1.2' imagePullPolicy: IfNotPresent name: sleep ...
可以看到,Sidecar容器
istio-proxy
不再處於initContainers
下,而是與主容器一同配置在containers
下。