以 Canary 為基礎的遷移至 Mesh CA
如要在不遷移控制平面情況下,以最短的停機時間遷移 CA,請參閱「原地 CA 遷移」。從 Istio CA (也稱為 Citadel) 遷移至 Cloud Service Mesh 憑證授權單位 (Mesh CA) 時,需要遷移信任根。在 Cloud Service Mesh 1.10 之前,如果您想從 Google Kubernetes Engine (GKE) 上的 Istio 遷移至搭配 Mesh CA 的 Cloud Service Mesh,就必須安排停機時間,因為 Cloud Service Mesh 無法載入多個根憑證。因此,在遷移期間,新部署的工作負載會信任新的根憑證,而其他工作負載則會信任舊的根憑證。使用不同根憑證簽署的憑證的工作負載無法相互驗證。也就是說,雙向傳輸層安全標準 (mTLS) 流量會在遷移期間中斷。只有在控制層和所有命名空間中的所有工作負載都使用 Mesh CA 的憑證重新部署時,整個叢集才能完全復原。如果您的網格有包含工作負載的多個叢集,且這些工作負載會將要求傳送至另一個叢集的工作負載,則這些叢集中的所有工作負載也都需要更新。
請在下列用途中使用本指南中的步驟:
- 使用 Mesh CA,從 GKE 上的 Istio 遷移至 Cloud Service Mesh 叢集內控制層。 1.26.4-asm.1
- 從使用 Istio CA 的 Cloud Service Mesh 1.15 或 1.16 修補程式版本 升級至使用 Mesh CA 的 Cloud Service Mesh 1.26.4-asm.1 叢集內控制層。
限制
- 所有 GKE 叢集都必須位於同一個 Google Cloud 專案中。
事前準備
按照「安裝依附工具並驗證叢集」中的步驟操作:必要工具
在遷移期間,您可以執行 Google 提供的工具 migrate_ca
,為叢集中的每個 Pod 驗證下列項目:
- Istio CA 和 Mesh CA 的根憑證。
- 由 Istio CA 和 Mesh CA 核發的工作負載 mTLS 憑證。
- Istio CA 和 Mesh CA 設定的信任網域。
這項工具有下列依附元件:
awk
grep
istioctl
執行asmcli install
會下載與您要安裝的 Cloud Service Mesh 版本相符的istioctl
版本。jq
kubectl
openssl
遷移作業總覽
如要遷移至 Mesh CA,請按照修訂版本遷移程序 (也稱為「測試版升級」) 進行。在以修訂版本為基礎的遷移作業中,系統會同時部署新的控制層修訂版本和現有控制層。接著,您可以逐步將工作負載移至新修訂版本,以便監控遷移程序的效果。在遷移過程中,使用 Mesh CA 的工作負載和使用 Istio CA 的工作負載之間的驗證和授權功能都會正常運作。
以下是遷移至 Mesh CA 的概略說明:
發布 Mesh CA 信任根。
安裝新的控制平面修訂版本,使用 Istio CA 和可發布 Mesh CA 信任根的選項。
將工作負載逐一遷移至新的控制層和命名空間,然後測試應用程式。所有工作負載都已成功遷移至新的控制層後,請移除舊的控制層。
遷移至 Mesh CA。由於所有附屬 Proxy 都已設定舊信任根和 Mesh CA 信任根,您可以無需停機即可遷移至 Mesh CA。請再次按照修訂版本遷移程序操作:
安裝啟用 Mesh CA 的控制層修訂版本。
將工作負載遷移至新的控制平面修訂版本,並依命名空間逐一測試應用程式。所有工作負載都已成功遷移至新的控制層後,請移除舊的控制層。
移除叢集中與舊 CA 相關聯的 CA 密鑰,然後重新啟動新的控制平面。
發布 Mesh CA 信任根
您必須先將網格中的所有 GKE 叢集遷移至 Cloud Service Mesh 1.10 以上版本,並為所有叢集設定控制平面選項,觸發 Mesh CA 信任根,再將其分發至叢集中所有工作負載的 Proxy。程序完成後,每個 Proxy 都會同時設定舊信任根與新信任根。使用這個配置時,當您遷移至 Mesh CA 時,使用 Mesh CA 的工作負載將能夠與使用舊版 CA 的工作負載進行驗證。
安裝新的控制層修訂版本
安裝控制層修訂版本,並使用可發布 Mesh CA 信任根的選項。
請按照「安裝依附工具並驗證叢集」中的步驟,準備使用 Google 提供的工具
asmcli
來安裝新的控制層修訂版本。請確認您安裝的
asmcli
版本會安裝 Cloud Service Mesh 1.11 以上版本:./asmcli --version
執行
asmcli install
。 請將以下指令中的預留位置替換為您的值。./asmcli install \ --fleet_id FLEET_PROJECT_ID \ --kubeconfig KUBECONFIG_FILE \ --enable_all \ --ca citadel \ --ca_cert CA_CERT_FILE_PATH \ --ca_key CA_KEY_FILE_PATH \ --root_cert ROOT_CERT_FILE_PATH \ --cert_chain CERT_CHAIN_FILE_PATH \ --option ca-migration-citadel \ --revision_name REVISION_1 \ --output_dir DIR_PATH
--fleet_id
機群主機專案的專案 ID。--kubeconfig
kubeconfig
檔案的路徑。您可以指定相對路徑或完整路徑。環境變數$PWD
在這裡無法運作。--output_dir
加入這個選項,即可指定asmcli
下載anthos-service-mesh
套件並擷取安裝檔案的目錄,其中包含istioctl
、範例和資訊清單。否則,asmcli
會將檔案下載至tmp
目錄。您可以指定相對路徑或完整路徑。環境變數$PWD
在這裡無法運作。-
--enable_all
允許工具執行以下操作: -ca citadel
為避免服務中斷,請指定 Istio CA (citadel
選項對應 Istio CA)。請勿在此時切換至 Mesh CA。--ca_cert
中繼憑證。--ca_key
中繼憑證的金鑰--root_cert
根憑證。--cert_chain
憑證鏈結。--option ca-migration-citadel
重新部署工作負載時,這個選項會觸發新的信任根,並將其分發至工作負載的附屬代理程式。REVISION_1
:建議。修訂版本標籤是控制平面上設定的鍵/值組合。修訂版本標籤鍵一律為istio.io/rev
。根據預設,這項工具會根據 Cloud Service Mesh 版本設定修訂版本標籤的值,例如:asm-1264-1
。建議您加入這個選項,並將REVISION_1
替換為描述安裝作業的名稱,例如asm-1264-1-distribute-root
。名稱必須是 DNS-1035 標籤,且必須由小寫英數字元或-
組成,開頭和結尾須為英文字元,並以英數字元結尾 (例如my-name
或abc-123
)。
將工作負載遷移至新控制層
如要完成新信任根的發布作業,您必須使用修訂版本標籤 istio.io/rev=<var>REVISION_1</var>-distribute-root
為命名空間加上標籤,並重新啟動工作負載。重新啟動工作負載後,您可以執行工具來驗證附加式 Proxy 是否已設定 Mesh CA 的舊和新信任根。
設定
kubectl
的目前背景資訊。如果您有單一區域叢集,請在下列指令中將--region
變更為--zone
。gcloud container clusters get-credentials CLUSTER_NAME \ --project=PROJECT_ID \ --region=CLUSTER_LOCATION
下載驗證工具:
curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/ca-migration/migrate_ca > migrate_ca
在工具上設定可執行位元:
chmod +x migrate_ca
migrate_ca
工具會呼叫istioctl
,這取決於版本。asmcli
工具會在您為--output_dir
指定的目錄中,將符號連結新增至istioctl
。請確認目錄位於路徑的開頭。在下列指令中,將ISTIOCTL_PATH
替換為包含工具下載的istioctl
的目錄。export PATH=ISTIOCTL_PATH:$PATH which istioctl echo $PATH
取得
istiod
和istio-ingressgateway
上的修訂標籤。kubectl get pod -n istio-system -L istio.io/rev
輸出結果會與下列內容相似:
NAME READY STATUS RESTARTS AGE REV istio-ingressgateway-5fd454f8ff-t7w9x 1/1 Running 0 36m default istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-z2s9p 1/1 Running 0 18m asm-195-2-distribute-root istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-zr2cs 1/1 Running 0 18m asm-195-2-distribute-root istiod-68bc495f77-shl2h 1/1 Running 0 36m default istiod-asm-195-2-distribute-root-6f764dbb7c-g9f8c 1/1 Running 0 18m asm-195-2-distribute-root istiod-asm-195-2-distribute-root-6f764dbb7c-z7z9s 1/1 Running 0 18m asm-195-2-distribute-root
在輸出內容的
REV
欄下,記下新修訂版本的修訂版本標籤值,該值與您執行asmcli install
時指定的修訂版本標籤相符。在這個範例中,這個值為asm-1264-1-distribute-root
。將工作負載移至新修訂版本後,您需要刪除
istiod
的舊修訂版本。請注意舊版istiod
修訂版本的修訂標籤中的值。範例輸出內容顯示從 Istio 遷移,該服務使用default
修訂版本。
將修訂版本標籤新增至命名空間,並移除
istio-injection
標籤 (如果有的話)。在下列指令中,將NAMESPACE
替換為要標示的命名空間。kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 istio-injection- --overwrite
如果輸出內容中出現
"istio-injection not found"
,您可以忽略這項訊息。這表示命名空間先前沒有istio-injection
標籤。由於命名空間同時具有istio-injection
和修訂版本標籤時,自動插入行為未定義,因此 Cloud Service Mesh 說明文件中的所有kubectl label
指令都會明確確保只設定一個。重新啟動 Pod 以觸發重新注入。
kubectl rollout restart deployment -n NAMESPACE
測試應用程式,確認工作負載是否正常運作。
如果您在其他命名空間中擁有工作負載,請重複執行上述步驟,為命名空間加上標籤並重新啟動 Pod。
驗證叢集中所有工作負載的附屬代理伺服器是否已同時設定舊版和新版的根憑證:
./migrate_ca check-root-cert
預期輸出內容:
Namespace: foo httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA] sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]
如果您需要遷移閘道,請按照「Canary 升級 (進階)」中的步驟,安裝新的閘道部署。請記住以下要點:
- 使用
REVISION_1
做為修訂版本標籤。 - 將閘道資源部署在舊版安裝程序的閘道所在的同一命名空間中,以便執行零停機時間遷移。請確認指向舊版閘道的服務資源現在也應包含較新的部署作業。
- 在確認應用程式運作正常 (下一個步驟後) 之前,請勿刪除舊的閘道部署作業。
- 使用
如果您認為應用程式運作正常,請繼續按照步驟改用新版
istiod
。如果應用程式發生問題,請按照步驟進行回復。完成轉換
如果您認為應用程式運作正常,請移除舊控制平面,完成改用新版本的程序。
切換至
anthos-service-mesh
GitHub 存放區檔案所在的目錄。設定驗證 webhook,以便使用新的控制層。
kubectl apply -f asm/istio/istiod-service.yaml
刪除舊的
istio-ingressgateway
部署。您執行的指令取決於您是要從 Istio 遷移,還是從舊版 Cloud Service Mesh 升級:遷移
如果您是從 Istio 遷移,舊版
istio-ingressgateway
就沒有修訂版本標籤。kubectl delete deploy/istio-ingressgateway -n istio-system
升級
如果您是從先前的 Cloud Service Mesh 版本升級,請在下列指令中將
OLD_REVISION
替換為先前版本istio-ingressgateway
的修訂版本標籤。kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
刪除
istiod
的舊修訂版本。您要使用的指令取決於您是要從 Istio 遷移,還是要從先前版本的 Cloud Service Mesh 升級。遷移
如果您是從 Istio 遷移,舊版
istio-ingressgateway
就沒有修訂版本標籤。kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
升級
如果您是從舊版 Cloud Service Mesh 升級,請在下列指令中確認
OLD_REVISION
與舊版istiod
的修訂版本標籤相符。kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
移除舊版
IstioOperator
設定。kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
預期的輸出內容會與下列內容相似:
istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
復原
如果您在使用新版
istiod
測試應用程式時遇到問題,請按照下列步驟將應用程式回溯至先前版本:刪除在步驟 11 中安裝的新閘道部署。
重新標記命名空間,以便使用先前版本的
istiod
啟用自動注入功能。您使用的指令取決於您是否在先前版本中使用修訂版本標籤或istio-injection=enabled
。如果您使用修訂版本標籤進行自動插入:
kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
如果您使用
istio-injection=enabled
:kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
預期輸出內容:
namespace/NAMESPACE labeled
確認命名空間的修訂版本標籤與
istiod
舊版的修訂版本標籤相符:kubectl get ns NAMESPACE --show-labels
重新啟動 Pod 以觸發重新注入,讓 Proxy 取得先前的版本:
kubectl rollout restart deployment -n NAMESPACE
移除新的
istio-ingressgateway
部署。kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_1 -n istio-system --ignore-not-found=true
移除
istiod
的新修訂版本。kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true
移除新的
IstioOperator
設定。kubectl delete IstioOperator installed-state-asm-1264-1-distribute-root -n istio-system
預期的輸出內容會與下列內容相似:
istiooperator.install.istio.io "installed-state-asm-1264-1-distribute-root" deleted
遷移至 Mesh CA
由於所有工作負載的附屬代理程式都已同時設定舊信任根和 Mesh CA 的新信任根,因此遷移至 Mesh CA 的步驟與您發布 Mesh CA 信任根的步驟類似:
安裝啟用 Mesh CA 的新控制層
您使用 asmcli install
安裝已啟用 Mesh CA 的新控制平面修訂版本。
如果您先前已自訂安裝作業,則執行
asmcli install
時,您需要指定相同的疊加檔案。執行
asmcli install
。 在下列指令中,將預留位置替換為您的值。./asmcli install \ --fleet_id FLEET_PROJECT_ID \ --kubeconfig KUBECONFIG_FILE \ --output_dir DIR_PATH \ --enable_all \ --ca mesh_ca \ --root_cert ROOT_CERT_FILE_PATH \ --cert_chain CERT_CHAIN_FILE_PATH --option ca-migration-meshca \ --revision_name REVISION_2 \ --output_dir DIR_PATH \ OVERLAYS
--fleet_id
機群主機專案的專案 ID。--kubeconfig
kubeconfig
檔案的路徑。您可以指定相對路徑或完整路徑。環境變數$PWD
在這裡無效。--output_dir
加入這個選項,即可指定asmcli
下載anthos-service-mesh
套件並擷取安裝檔案的目錄,其中包含istioctl
、範例和資訊清單。否則,asmcli
會將檔案下載至tmp
目錄。您可以指定相對路徑或完整路徑。環境變數$PWD
在這裡無效。-
--enable_all
允許工具執行以下操作:- 授予必要的 IAM 權限。
- 啟用必要的 Google API。
- 為叢集設定可識別網格的標籤。
- 如果叢集尚未註冊至機群,請 將叢集註冊。
--ca mesh_ca
由於 Mesh CA 信任根已發布,您現在可以切換至 Mesh CA。REVISION_2
建議。將REVISION_2
替換為描述安裝作業的名稱,例如asm-1264-1-meshca-ca-migration
。名稱必須是 DNS-1035 標籤,且只能使用小寫英數字元或-
,開頭和結尾須為英文字母,並以英數字元結尾 (例如my-name
或abc-123
)。--option ca-migration-migration
當您重新部署工作負載時,這個選項會將 Proxy 設為使用 Mesh CA 信任根。
將工作負載遷移至新控制層
如要完成安裝作業,您必須為命名空間加上新的修訂版本標籤,並重新啟動工作負載。
取得
istiod
和istio-ingressgateway
上的修訂標籤。kubectl get pod -n istio-system -L istio.io/rev
輸出結果會與下列內容相似:
NAME READY STATUS RESTARTS AGE REV istio-ingressgateway-asm-1264-1-distribute-root-65d884685d-6hrdk 1/1 Running 0 67m asm-1264-1-distribute-root istio-ingressgateway-asm-1264-1-distribute-root65d884685d-94wgz 1/1 Running 0 67m asm-1264-1-distribute-root istio-ingressgateway-asm-1264-1-meshca-ca-migration-8b5fc8767-gk6hb 1/1 Running 0 5s asm-1264-1-meshca-ca-migration istio-ingressgateway-asm-1264-1-meshca-ca-migration-8b5fc8767-hn4w2 1/1 Running 0 20s asm-1264-1-meshca-ca-migration istiod-asm-1264-1-distribute-root-67998f4b55-lrzpz 1/1 Running 0 68m asm-1264-1-distribute-root istiod-asm-1264-1-distribute-root-67998f4b55-r76kr 1/1 Running 0 68m asm-1264-1-distribute-root istiod-asm-1264-1-meshca-ca-migration-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-1264-1-meshca-ca-migration istiod-asm-1264-1-meshca-ca-migration-5cd96f88f6-wm68b 1/1 Running 0 27s asm-1264-1-meshca-ca-migration
在輸出內容的
REV
欄下,記下新版本修訂版本標籤的值。在這個範例中,這個值為asm-1264-1-meshca-ca-migration
。請注意舊版
istiod
的修訂版本標籤中的值。當您完成將工作負載遷移至新版本的作業後,就需要這個值來刪除舊版istiod
。在這個範例中,上一個修訂版本的修訂標籤值為asm-1264-1-distribute-root
。
將新修訂版本標籤新增至命名空間。在下列指令中,將
NAMESPACE
替換為要標示的命名空間。kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite
重新啟動 Pod 以觸發重新注入。
kubectl rollout restart deployment -n NAMESPACE
測試應用程式,確認工作負載是否正常運作。請確認 mTLS 通訊可在舊命名空間和新命名空間的工作負載之間運作。
如果其他命名空間中有工作負載,請重複執行上述步驟,為命名空間加上標籤並重新啟動 Pod。
如果您認為應用程式運作正常,請繼續執行轉換至新控制平面的步驟。如果應用程式發生問題,請按照步驟進行回復。
完成轉換
如果您認為應用程式運作正常,請移除舊控制平面,完成改用新版本的程序。
切換至
anthos-service-mesh
GitHub 存放區檔案所在的目錄。設定驗證 webhook,以便使用新的控制層。
kubectl apply -f asm/istio/istiod-service.yaml
刪除舊的
istio-ingressgateway
Deployment。在下列指令中,將OLD_REVISION
替換為舊版istio-ingressgateway
的修訂版本標籤。kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
刪除舊的
istiod
修訂版本。在下列指令中,將OLD_REVISION
替換為先前版本istiod
的修訂版本標籤。kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
移除舊的
IstioOperator
設定。kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
預期的輸出內容會與下列內容相似:
istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
復原
如果您在使用新版
istiod
修訂版本測試應用程式時遇到問題,請按照下列步驟還原至先前版本:重新標記命名空間,以便啟用先前
istiod
修訂版本的自動注入功能。kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
預期輸出內容:
namespace/NAMESPACE labeled
確認命名空間的修訂版本標籤與
istiod
舊版的修訂版本標籤相符:kubectl get ns NAMESPACE --show-labels
重新啟動 Pod 以觸發重新注入,讓 Proxy 取得先前的版本:
kubectl rollout restart deployment -n NAMESPACE
移除新的
istio-ingressgateway
部署。kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_2 -n istio-system --ignore-not-found=true
移除新版
istiod
。請確認下列指令中的修訂版本標籤與您的修訂版本相符。kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_2 -n istio-system --ignore-not-found=true
移除新版
IstioOperator
設定。kubectl delete IstioOperator installed-state-REVISION_2 -n istio-system
預期的輸出內容會與下列內容相似:
istiooperator.install.istio.io "installed-state-REVISION_2" deleted
移除 CA 密鑰,並重新啟動新的控制平面
保留機密資訊,以備不時之需:
kubectl get secret/cacerts -n istio-system -o yaml > save_file_1 kubectl get secret/istio-ca-secret -n istio-system -o yaml > save_file_2
移除與舊 CA 相關聯的叢集中的 CA 密鑰:
kubectl delete secret cacerts istio-ca-secret -n istio-system --ignore-not-found
重新啟動新安裝的控制層。這可確保在網格中執行的所有工作負載都會清除舊信任根。
kubectl rollout restart deployment -n istio-system