使用原生Sidecar方式部署網格代理 - Alibaba Cloud Service Mesh

服務網格ASM支援以Sidecar模式或Sidecarless模式為叢集中的應用部署網格代理，以實現對底層網路功能的抽象化管理，例如負載平衡、服務發現、流量控制、安全性增強、流量可觀測等。ASM通過Sidecar模式將網格代理容器加入到Pod，讓網格代理容器與應用程式容器共同部署在同一Pod中、共用相同的網路命名空間，並使得網格代理透明地攔截和處理應用程式容器的入站和出站流量。本文主要介紹在ASM中使用原生Sidecar方式部署網格代理。

傳統Sidecar與原生Sidecar

對比項	傳統Sidecar	原生Sidecar
受支援K8s版本	社區版本1.4~1.28，ACK、ACK Serverless或ACS叢集為1.30以下版本。	社區版本1.29及以上，ACK、ACK Serverless或ACS叢集需1.30及以上版本。
受支援ASM版本	1.22以下版本的ASM執行個體。	1.22及以上版本ASM執行個體添加1.30及以上版本的Kubernetes叢集（ACK、ACK Serverless或ACS叢集）時，預設將以原生Sidecar方式部署網格代理。
部署方式	Sidecar容器與主容器都配置在`containers`欄位下。	Sidecar容器配置`initContainers`欄位，並存在`restartPolicy: Always`欄位。
生命週期	無法與主容器同步，需要單獨管理。	與主容器同步，無需額外配置。

傳統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下。