本頁說明如何輪替 GKE 叢集憑證。規劃及定期輪替叢集憑證，對於確保叢集維持良好狀態至關重要。本頁面說明如何執行憑證輪替。您也會瞭解規劃定期輪替的最佳做法。
本頁面適用於負責管理 GKE 叢集上憑證生命週期的安全專家。如要進一步瞭解我們在內容中提及的常見角色和範例工作，請參閱「常見的 GKE 使用者角色和工作」。 Google Cloud
關於 GKE 中的憑證輪替
叢集根憑證授權單位 (CA) 的有效期限有限。CA 過期後，由該 CA 簽署的所有憑證都會失效，包括叢集用戶端憑證 (來自 MasterAuth API 欄位)、API 伺服器的金鑰和憑證，以及 kubelet 用戶端憑證。叢集憑證的生命週期取決於您建立叢集的時間，或上次輪替憑證的時間。詳情請參閱憑證生命週期。
您可以執行憑證輪替來撤銷叢集的憑證，再發出新憑證。這項作業會輪替叢集 CA 私密金鑰，並需要重新建立節點，才能使用新憑證。您必須在目前憑證到期前，為叢集開始並完成憑證輪替。除了輪替憑證以外，憑證輪替功能還能執行 IP 輪替。
執行憑證輪替的時機
您應定期執行憑證輪替，並在目前憑證到期前執行。憑證輪替需要重新建立節點才能使用新憑證，這可能會中斷執行中的工作負載。規劃維護期並在維護時間範圍內執行輪替，避免叢集外部發生非預期的工作負載停機或 API 用戶端沒有回應。
如要進一步瞭解維護可用性如何影響叢集憑證輪替，以及叢集在輪替步驟中會遇到哪種中斷情形，請參閱手動變更表格中憑證輪替的資料列。該表格會使用節點升級策略重新建立節點，並遵守維護政策。GKE 會依據資源可用性更新節點。如要進一步瞭解節點更新，請參閱「規劃節點更新中斷」。
叢集憑證生命週期
叢集憑證的生命週期通常取決於叢集的建立時間，或最近一次輪換憑證的時間：
- 大約在 2021 年 10 月前建立的叢集，CA 的生命週期為 5 年。
- 大約在 2021 年 10 月後建立的叢集，CA 的生命週期為 30 年。
- 2022 年 1 月左右輪替的叢集，其 CA 生命週期為 30 年。
找出憑證即將到期或已過期的叢集
如果叢集的憑證將在未來 180 天內到期，或叢集的憑證已過期，GKE 會提供洞察資料和建議，說明您必須為這個叢集執行憑證輪替。這項指引包括憑證到期日。您可以在 Google Cloud 控制台查看這項指引。或者，您可以使用 gcloud CLI 或 Recommender API 查看這項指引，並指定 CLUSTER_CA_EXPIRATION 子類型。
如果收到叢集的洞察資訊和建議，您必須執行憑證輪替，否則 GKE 會在目前 CA 到期日後 30 天內自動啟動憑證輪替，詳情請參閱下一節。憑證輪替完成後，洞察和建議最多可能要過 36 小時才會解決。
GKE 自動化政策，可防止叢集服務中斷
為避免叢集在目前憑證到期後進入無法復原的狀態，GKE 會在目前 CA 到期日前 30 天內，自動啟動憑證輪替程序。舉例來說，如果叢集 CA 在 2024 年 1 月 6 日到期，而您未在 2023 年 12 月 5 日前輪替憑證，GKE 會在 2023 年 12 月 7 日當天或之後啟動自動輪替，並在作業開始七天後嘗試完成輪替。這項自動輪替作業是最後的嘗試，目的是為了避免叢集服務中斷，並有下列注意事項：
- 自動輪替作業通常會遵守維護期間或維護作業排除時段，但 GKE 保留權利，可在憑證到期前 30 天內執行輪替步驟，不論維護作業是否可用。在 30 天內，GKE 會忽略第一步的維護可用性，也就是開始輪替。
- 如果維護作業導致 GKE 無法完成初始輪替作業，GKE 會持續嘗試完成輪替作業，直到憑證到期為止。憑證到期後，叢集將無法復原。
- 憑證輪替完成後，系統會撤銷即將到期的憑證。您必須先設定用戶端使用新憑證，叢集外部的 Kubernetes API 用戶端 (例如本機環境中的 kubectl) 才能運作。
- 輪替期間重新建立節點集區可能會導致執行中的工作負載中斷。
事前準備
開始之前，請確認您已完成下列工作：
- 啟用 Google Kubernetes Engine API。 啟用 Google Kubernetes Engine API
- 如要使用 Google Cloud CLI 執行這項工作，請安裝並初始化 gcloud CLI。如果您先前已安裝 gcloud CLI，請執行
gcloud components update指令，取得最新版本。較舊的 gcloud CLI 版本可能不支援執行本文件中的指令。
- 請確認您有現有的 Autopilot 或 Standard 叢集。如需叢集，請建立 Autopilot 叢集。
檢查憑證效期
建議您在執行憑證輪替前後檢查憑證生命週期，瞭解叢集根 CA 的效期。
如要檢查單一叢集的憑證生命週期，請執行下列指令：
gcloud container clusters describe CLUSTER_NAME \
--location LOCATION \
--format "value(masterAuth.clusterCaCertificate)" \
| base64 --decode \
| openssl x509 -noout -dates
輸出結果會與下列內容相似：
notBefore=Mar 17 16:45:34 2023 GMT
notAfter=Mar 9 17:45:34 2053 GMT
如果您在啟動憑證輪替後執行這項指令，輸出內容會是原始憑證的生命週期。在完成輪替前，這個憑證仍有效。完成輪替後，輸出內容會是新憑證的生命週期。
如要查看專案中所有叢集的憑證生命週期，請執行下列指令：
gcloud container clusters list --project PROJECT_ID \
--format="value(name,masterAuth.clusterCaCertificate)" | \
while read -r cluster ca; do \
expiry_date=$(echo -e "$ca" | base64 --decode | openssl x509 -noout -enddate | awk -F'=' '{print $2}'); \
printf "%-40s | %s\n" "$cluster" "$expiry_date" ; \
done | \
column -t | \
awk -F',' 'BEGIN{print "Cluster Name | Certificate Expiry Date"} {print}'
執行憑證輪替
任何憑證輪替都包含下列步驟：
- 啟動輪替：控制層除了原本的 IP 位址之外，也會開始為新的 IP 位址提供服務。新憑證會發給工作負載和控制層。
- 重新建立節點：GKE 會重新建立叢集節點，讓節點使用新的 IP 位址和憑證，並遵守維護期間和排除項目中的可用性。您也可以將節點版本升級至節點已執行的相同 GKE 版本，手動重新建立節點。
- 更新 API 用戶端：啟動輪替後，請更新所有叢集 API 用戶端 (例如使用
kubectl的開發機器)，透過新的 IP 位址與控制平面通訊。 - 完成輪替：控制層會停止透過原始 IP 位址提供流量。系統會撤銷舊憑證，包括 Kubernetes 服務帳戶的所有現有靜態憑證。
啟動憑證輪替時，或 GKE 自動啟動輪替時，GKE 會自動執行這些步驟，包括嘗試完成輪替。在每個步驟中，如果叢集到期日距離現在超過 30 天，GKE 會尊重維護可用性。在叢集到期前的自動輪替期間，GKE 保留忽略維護可用性的權利，以防止叢集無法復原。在 30 天內，GKE 會忽略第一個步驟的維護可用性，也就是開始輪替。
如果未在啟動憑證輪替後的七天內完成輪替作業，GKE 會嘗試為您完成輪替。如果叢集中的任何節點仍使用先前的憑證，自動完成作業就會失敗，但 GKE 會持續嘗試完成作業，直到憑證過期，叢集無法復原為止。您應規劃手動追蹤及完成您啟動的任何憑證輪替。如要覆寫維護作業可用性阻礙，請在下列各節中執行指令，手動觸發輪替程序的這些階段。請勿依賴自動完成功能，這項功能只能盡量提供最佳結果。
啟動輪替
如要啟動憑證輪替，請執行下列指令：
gcloud container clusters update CLUSTER_NAME \
--location LOCATION \
--start-credential-rotation
這個指令會建立新憑證、將憑證發到控制層，並將控制層設為提供兩個 IP 位址的服務，為原本的 IP 位址和新的 IP 位址提供服務。
重新啟動具有長期連線的叢內元件
啟動 IP 位址或憑證輪替後，叢集的憑證授權單位 (CA) 也會輪替。某些叢集內元件 (例如 metrics-server 和 konnectivity-agent) 會維護長期 TLS 連線，可能不會自動信任新的叢集 CA。
這種情況可能會導致這些連線在與節點或其他叢集端點通訊時失敗，您可能會在元件記錄中看到 TLS 交握錯誤，例如 x509: certificate signed by unknown authority。
如果在啟動輪替後發現這些錯誤，可能需要手動重新啟動 Pod。重新啟動會強制 Pod 重新初始化連線，並載入新的叢集 CA 憑證。舉例來說，如要重新啟動 metrics-server 和 konnectivity-agent，請執行下列指令：
kubectl rollout restart deployment metrics-server -n kube-system
kubectl rollout restart deployment konnectivity-agent -n kube-system
重新建立節點
重新設定 API 伺服器，以在新 IP 位址上提供服務後，如果維護作業可用，GKE 會自動更新節點，以使用新的 IP 位址和憑證。GKE 會將所有節點升級至節點目前執行的 GKE 版本，並重新建立節點。詳情請參閱「節點集區升級」。
根據預設，GKE 會在您啟動作業七天後，自動完成憑證輪替。如果叢集有作用中的維護期間或排除項目，導致 GKE 無法在這七天內重新建立部分節點，憑證輪替作業一開始會無法完成。不過，GKE 會持續嘗試重建節點並完成輪替，直到維護可用性允許 GKE 繼續作業為止。在 Google Cloud Next 等重大活動期間，GKE 也可能會暫停自動重新建立節點，避免發生中斷情形。
如果您使用維護排除項目或維護期間，可能會導致輪替失敗，請執行下列任一步驟，強制 GKE 重新建立節點：
在 Autopilot 叢集中，手動升級控制層：
gcloud container clusters upgrade CLUSTER_NAME \ --location=LOCATION \ --cluster-version=VERSION將
VERSION替換為叢集已使用的相同 GKE 版本。在 Standard 叢集中，手動升級每個節點集區。
詳情請參閱手動變更，以遵守 GKE 維護政策。
查看節點集區重建進度
如要監控輪替作業，請執行下列指令：
gcloud container operations list \ --filter="operationType=UPGRADE_NODES AND status=RUNNING" \ --format="value(name)"此指令會傳回節點升級作業的「作業 ID」。
如要對作業進行輪詢，請將作業 ID 傳送至下列指令：
gcloud container operations wait OPERATION_ID
系統會逐一重建節點集區，每個集區都有各自的作業。如果您有多個節點集區，請按照這些操作說明輪詢每個作業。
更新 API 用戶端
啟動憑證輪替後，您必須更新叢集外的所有 API 用戶端 (例如開發人員機器上的 kubectl)，使用新憑證並指向控制層的新 IP 位址。
如要更新 API 用戶端，請對每個用戶端執行下列指令：
gcloud container clusters get-credentials CLUSTER_NAME \
--location LOCATION
更新 Kubernetes ServiceAccount 憑證
如果您在叢集中使用 ServiceAccount 的靜態憑證，請改用短期憑證。完成輪替後，現有的 ServiceAccount 憑證就會失效。如果不想使用短期憑證，請務必在完成輪替前，為叢集中的所有 ServiceAccount 重新建立靜態憑證。
如要找出叢集中現有的靜態 ServiceAccount 憑證，請執行下列指令：
kubectl get secrets --all-namespaces --field-selector type=kubernetes.io/service-account-token
如果這項指令的輸出內容是 No resources found，表示叢集沒有靜態 ServiceAccount 憑證。
更新硬式編碼 IP 位址和防火牆規則
如果您在環境中將控制層的 IP 位址硬式編碼，或是防火牆規則以控制層的 IP 位址為目標，請將位址更新為新的 IP 位址。如果您完成輪替，但未更新應用程式和防火牆規則中的 IP 位址，當 GKE 停止透過先前的控制平面 IP 位址提供服務時，這些資源可能會發生中斷情形。
完成輪替
更新叢集外部的 API 用戶端後，請完成輪替，將控制層設為只使用新憑證和新 IP 位址提供服務：
gcloud container clusters update CLUSTER_NAME \
--location=LOCATION \
--complete-credential-rotation
如果憑證輪替作業無法完成，並傳回類似下列的錯誤訊息，請參閱「錯誤 400：節點集區需要重新建立」：
ERROR: (gcloud.container.clusters.update) ResponseError: code=400, message=Node pool "test-pool-1" requires recreation.
GKE 會在自動完成輪替作業時遵守維護作業可用性，但為了避免叢集無法復原，GKE 可能會在憑證到期前 30 天內忽略這項可用性。如果輪替作業一開始失敗，且輪替作業至少在七天前啟動，GKE 會嘗試完成輪替作業，直到憑證到期為止。憑證到期後，叢集將無法復原。