CA 憑證的手動輪換
本頁說明如何手動輪換憑證授權機構 (CA) 憑證。
開始之前
您需要有一個 Kubernetes 叢集，而且必須將 kubectl 命令列工具配置為與您的叢集通訊。建議在至少有兩個節點且不充當控制平面主機的叢集上執行本教學課程。如果您還沒有叢集，可以使用 minikube 建立一個，或者您可以使用以下 Kubernetes 實驗環境
手動輪換 CA 憑證
注意
請務必備份您的憑證目錄以及組態檔和任何其他必要檔案。
此方法假設 Kubernetes 控制平面在具有多個 API 伺服器的 HA 配置中運作。也假設 API 伺服器正常終止，以便用戶端可以從一個 API 伺服器乾淨地斷開連線並重新連線到另一個伺服器。
單一 API 伺服器的配置在 API 伺服器重新啟動時將會遇到無法使用的情況。
將新的 CA 憑證和私密金鑰 (例如：
ca.crt、ca.key、front-proxy-ca.crt和front-proxy-ca.key) 分發到 Kubernetes 憑證目錄中所有控制平面節點。更新 kube-controller-manager 的
--root-ca-file旗標，以同時包含舊的和新的 CA，然後重新啟動 kube-controller-manager。在此時間點之後建立的任何服務帳戶都將取得包含舊的和新的 CA 的密鑰。
注意
kube-controller-manager 旗標
--client-ca-file和--cluster-signing-cert-file指定的檔案不能是 CA 捆綁包。如果這些旗標和--root-ca-file指向相同的ca.crt檔案，而該檔案現在是捆綁包 (包含舊的和新的 CA)，您將會遇到錯誤。若要解決此問題，您可以將新的 CA 複製到個別的檔案，並讓旗標--client-ca-file和--cluster-signing-cert-file指向該副本。一旦ca.crt不再是捆綁包，您可以還原問題旗標以指向ca.crt並刪除副本。Issue 1350 適用於 kubeadm 追蹤 kube-controller-manager 無法接受 CA 捆綁包的錯誤。
等待控制器管理器更新服務帳戶密鑰中的
ca.crt，以包含舊的和新的 CA 憑證。如果在 API 伺服器使用新的 CA 之前啟動任何 Pod，則新的 Pod 會取得此更新，並將信任舊的和新的 CA。
重新啟動所有使用叢集內配置的 Pod (例如：kube-proxy、CoreDNS 等)，以便它們可以使用來自連結到 ServiceAccount 的密鑰的更新憑證授權機構資料。
- 確保 CoreDNS、kube-proxy 和其他使用叢集內配置的 Pod 運作正常。
將舊的和新的 CA 都附加到
kube-apiserver配置中針對--client-ca-file和--kubelet-certificate-authority旗標的檔案。將舊的和新的 CA 都附加到
kube-scheduler配置中針對--client-ca-file旗標的檔案。更新使用者帳戶的憑證，方法是分別替換
client-certificate-data和client-key-data的內容。如需建立個別使用者帳戶憑證的相關資訊，請參閱設定使用者帳戶憑證。
此外，請更新 kubeconfig 檔案中的
certificate-authority-data區段，分別使用 Base64 編碼的舊版和新版憑證授權單位資料。更新雲端控制器管理員的
--root-ca-file標記，以同時包含舊版和新版 CA，然後重新啟動 cloud-controller-manager。注意
如果您的叢集沒有雲端控制器管理員，您可以跳過此步驟。請以滾動方式按照以下步驟操作。
重新啟動任何其他聚合 API 伺服器或 Webhook 處理常式，以信任新的 CA 憑證。
透過更新 kubelet 組態中的
clientCAFile檔案，以及kubelet.conf中的certificate-authority-data，以在所有節點上同時使用舊版和新版 CA，來重新啟動 kubelet。如果您的 kubelet 未使用用戶端憑證輪替，請更新所有節點上
kubelet.conf中的client-certificate-data和client-key-data，以及通常位於/var/lib/kubelet/pki中的 kubelet 用戶端憑證檔案。使用由新版 CA 簽署的憑證 (
apiserver.crt、apiserver-kubelet-client.crt和front-proxy-client.crt) 重新啟動 API 伺服器。您可以使用現有的私密金鑰或新的私密金鑰。如果您變更了私密金鑰，也請在 Kubernetes 憑證目錄中更新這些金鑰。由於叢集中的 Pod 信任舊版和新版 CA，因此在 Pod 的 Kubernetes 用戶端重新連線至新的 API 伺服器後，會發生短暫的連線中斷。新的 API 伺服器使用由新版 CA 簽署的憑證。
- 重新啟動 kube-scheduler 以使用並信任新的 CA。
- 確認控制平面元件記錄中沒有 TLS 錯誤。
注意
To generate certificates and private keys for your cluster using the `openssl` command line tool, see [Certificates (`openssl`)](/docs/tasks/administer-cluster/certificates/#openssl). You can also use [`cfssl`](/docs/tasks/administer-cluster/certificates/#cfssl).註釋任何 DaemonSet 和 Deployment，以更安全地以滾動方式觸發 Pod 替換。
for namespace in $(kubectl get namespace -o jsonpath='{.items[*].metadata.name}'); do for name in $(kubectl get deployments -n $namespace -o jsonpath='{.items[*].metadata.name}'); do kubectl patch deployment -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}'; done for name in $(kubectl get daemonset -n $namespace -o jsonpath='{.items[*].metadata.name}'); do kubectl patch daemonset -n ${namespace} ${name} -p '{"spec":{"template":{"metadata":{"annotations":{"ca-rotation": "1"}}}}}'; done done注意
To limit the number of concurrent disruptions that your application experiences, see [configure pod disruption budget](/docs/tasks/run-application/configure-pdb/).Depending on how you use StatefulSets you may also need to perform similar rolling replacement.如果您的叢集使用啟動程序權杖來加入節點，請使用新的 CA 更新
kube-public命名空間中的 ConfigMapcluster-info。base64_encoded_ca="$(base64 -w0 /etc/kubernetes/pki/ca.crt)" kubectl get cm/cluster-info --namespace kube-public -o yaml | \ /bin/sed "s/\(certificate-authority-data:\).*/\1 ${base64_encoded_ca}/" | \ kubectl apply -f -驗證叢集功能。
檢查來自控制平面元件、kubelet 和 kube-proxy 的記錄。確保這些元件未報告任何 TLS 錯誤；如需更多詳細資訊，請參閱查看記錄。
驗證來自任何聚合 API 伺服器和使用叢集內部組態的 Pod 的記錄。
一旦成功驗證叢集功能
僅更新所有服務帳戶權杖以包含新的 CA 憑證。
- 最終需要重新啟動所有使用叢集內部 kubeconfig 的 Pod，以取得新的密鑰 (Secret)，以便沒有 Pod 依賴舊版的叢集 CA。
透過從 kubeconfig 檔案和針對
--client-ca-file、--root-ca-file標記的檔案中移除舊版 CA，來重新啟動控制平面元件。在每個節點上，透過從針對
clientCAFile標記的檔案和從 kubelet kubeconfig 檔案中移除舊版 CA，來重新啟動 kubelet。您應該以滾動更新的方式執行此操作。如果您的叢集允許您進行此變更，您也可以透過替換節點而非重新設定節點來推出此變更。