使用原生Sidecar方式部署網(wǎng)格代理
服務(wù)網(wǎng)格ASM支持以Sidecar模式或Sidecarless模式為集群中的應(yīng)用部署網(wǎng)格代理,以實現(xiàn)對底層網(wǎng)絡(luò)功能的抽象化管理,例如負載均衡、服務(wù)發(fā)現(xiàn)、流量控制、安全性增強、流量可觀測等。ASM通過Sidecar模式將網(wǎng)格代理容器加入到Pod,讓網(wǎng)格代理容器與應(yīng)用容器共同部署在同一Pod中、共享相同的網(wǎng)絡(luò)命名空間,并使得網(wǎng)格代理透明地攔截和處理應(yīng)用容器的入站和出站流量。本文主要介紹在ASM中使用原生Sidecar方式部署網(wǎng)格代理。
傳統(tǒng)Sidecar與原生Sidecar
對比項 | 傳統(tǒng)Sidecar | 原生Sidecar |
受支持K8s版本 | 1.2~1.28。 | 1.28及以上。 |
受支持ASM版本 | 1.22以下版本的ASM實例。 | 1.22及以上版本ASM實例添加1.30及以上版本的Kubernetes集群(ACK、ACK Serverless或ACS集群)時,默認將以原生Sidecar方式部署網(wǎng)格代理。 |
部署方式 | Sidecar容器與主容器都配置在 | Sidecar容器配置 |
生命周期 | 無法與主容器同步,需要單獨管理。 | 與主容器同步,無需額外配置。 |
傳統(tǒng)Sidecar方式的網(wǎng)格代理實際上作為Pod中的普通容器與應(yīng)用容器一同部署,并分別擁有各自的生命周期。這可能會產(chǎn)生以下的已知問題:
如果應(yīng)用容器啟動速度比Sidecar代理容器快,則應(yīng)用容器將無法訪問網(wǎng)絡(luò)。我們可以通過配置Sidecar優(yōu)雅啟動來解決此問題,但在Sidecar代理啟動速度較慢時仍然可能出現(xiàn)問題。具體操作,請參見Sidecar優(yōu)雅啟動。
如果Sidecar代理容器先于應(yīng)用容器關(guān)閉,則應(yīng)用容器無法訪問網(wǎng)絡(luò)。我們可以通過配置Sidecar優(yōu)雅終止來解決此問題,但可能會導(dǎo)致Pod終止時間延長。具體操作,請參見Sidecar優(yōu)雅終止。
如果Job類應(yīng)用容器運行結(jié)束后退出,Sidecar代理容器仍將運行并保持Pod無限期運行。
在 Sidecar代理容器啟動之前運行的
initContainers
將無法訪問網(wǎng)絡(luò)。通常我們可以通過設(shè)置部分出口流量免于經(jīng)過Sidecar代理來繞過此問題。具體操作,請參見不攔截對外訪問的地址范圍。
如何確認網(wǎng)格代理是否以原生Sidecar方式部署
當(dāng)您看到Pod的initContainers
字段中存在istio-proxy
容器,并且容器配置中包含restartPolicy: Always
字段時,則網(wǎng)格代理正在以原生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代理生命周期相關(guān)的Sidecar代理配置都將失效(因為原生Sidecar不再需要這些配置)。更多信息,請參見配置Sidecar代理。
如何切換回傳統(tǒng)Sidecar代理部署方式
如果您的集群中還部署了一些依賴較老K8s版本,且會修改Pod定義的MutatingWebhook組件(如kubesphere的logsidecar-injector),這些組件可能會刪除原生Sidecar的定義,導(dǎo)致創(chuàng)建失敗。您可能需要切換回傳統(tǒng)Sidecar代理部署模式,以保持和老版本MutatingWebhook的兼容性。
具體操作步驟如下:
使用kubectl連接到ASM實例。具體操作,請參見通過控制面kubectl訪問Istio資源。
執(zhí)行以下命令,為
asmmeshconfig
資源追加配置。kubectl patch asmmeshconfig default --type=merge --patch='{"spec":{"enableNativeSidecar":false}}'
預(yù)期輸出:
asmmeshconfig.istio.alibabacloud.com/default patched
手動重啟Pod。具體操作,請參見重新部署工作負載。
執(zhí)行以下命令,再次查看Pod信息。
kubectl get pod sleep-xxxxxxxx-xxxxx -o yaml
預(yù)期輸出:
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
下。