**協助改進此頁面**
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
若要為本使用者指南貢獻內容，請點選每個頁面右側面板中的**在 GitHub 上編輯此頁面**連結。
本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 輪換 EKS 叢集憑證授權單位 (CA)
在公有金鑰基礎設施 (PKI) 中，憑證授權機構 (CA) 是可發行和簽署數位憑證的受信任實體。這些憑證會建立身分，並使用 TLS (Transport Layer Security) 在系統之間啟用加密通訊。當用戶端連線至伺服器時，伺服器會顯示由 CA 簽署的憑證。用戶端會根據其信任CAs 來驗證伺服器的憑證，再允許連線繼續。
在 Amazon Elastic Kubernetes Service (Amazon EKS) 中，會在叢集建立時為每個 EKS 叢集建立 CA。這遵循與上游 Kubernetes 相同的模型：每個 EKS 叢集都有自己的 CA 來簽署 API 伺服器的憑證。這可讓控制平面元件、工作者節點和用戶端向 API 伺服器進行身分驗證，並建立與 EKS 叢集的加密連線。
這些憑證授權單位 CAs) 具有定義的有效期間。CA 輪換是在到期之前取代 EKS 叢集憑證授權單位的程序，確保您的叢集保持運作和可存取。我們有內建的保護措施，可自動管理此程序。如果您不自行啟動 CA 輪換，我們會自動附加後續 CA，並在傳出 CA 過期之前啟用它，確保您的叢集保持可用。
在 CA 輪換期間，後續 CA 會附加到您的 EKS 叢集。EKS 會自動將後續 CA 分發到所有 AWS 受管元件 （控制平面、[EKS Auto Mode](https://docs.aws.amazon.com/automode/automode.html) 執行個體和 AWS Fargate 節點）。您有責任更新您管理的工作者節點 （非 EKS Auto Mode、非 Fargate) 和外部用戶端 （例如 kubeconfig 檔案和 CI/CD 管道），以便在啟用後續 CA 之前信任後續 CA。啟動後續 CA 之後，EKS 叢集會轉換為使用後續 CA 簽署憑證。然後會淘汰傳出 CA。
每個 EKS 叢集都需要 CA 輪換，因為 CAs 的有效期間有限。有效期間取決於叢集的 CA 建立時間。如需詳細資訊，請參閱常見問答集一節。EKS 保護措施可確保您的叢集本身在整個輪換生命週期內保持可用，但成功的輪換也取決於您更新管理的工作者節點和外部用戶端，以便在啟用後續 CA 之後保持連線。
以下各節中的 APIs、主控台體驗、通知和step-by-step指引旨在支援您完成此程序。共同責任模型章節涵蓋完整的責任範圍。
## CA 輪換的運作方式
Amazon EKS 中的 CA 輪換是多階段程序。無論您是否採取行動，我們都有自動保護措施來在整個輪換生命週期中保持 EKS 叢集可用性。成功輪換，其中所有元件都會維持連線能力，因此需要下列各節所述的步驟。
### 階段 1：附加後續 CA
後繼 CA 會附加至 EKS 叢集。從此時開始，EKS 叢集會同時信任傳出 CA 和後續 CA。憑證會繼續由傳出 CA 發行。不會發生中斷。
只要叢集處於作用中狀態，您可以隨時使用 AWS CLI、EKS API、主控台或基礎設施做為程式碼 (IaC)，例如 AWS CloudFormation，自行附加後續 CA。如果您不這樣做，我們會自動代表您附加一個。
在 EKS （階段 2) 中 AWS 完成對 AWS 受管元件的分發之前，無法啟用後續 CA。這是開始識別需要更新的工作者節點和外部用戶端的正確時機。識別連接到 EKS 叢集 API 伺服器的所有系統可能需要一些時間，特別是在具有多個團隊、CI/CD 管道和監控工具的環境中。儘早開始此程序可讓您在自己的時間軸上協調更新。
### 階段 2：分發後續 CA
在附加後續 CA 之後， AWS 更新 EKS 叢集中的受管元件 （控制平面、EKS Auto Mode 執行個體和 AWS Fargate 節點），以識別和信任這兩個 CAs。您可以透過 CA 的分佈狀態來追蹤進度。分佈完成之前，無法啟用後續 CA。
完成受管元件的 CA 分佈後，您需負責更新兩個群組：您管理的工作者節點 （非 EKS Auto Mode、非 Fargate)，以及信任後續 CA 的外部用戶端。這可確保他們會在後續 CA 啟用後繼續連線到 API 伺服器。如果在啟用後續 CA 之前未更新任何元件，CA 復原可在您完成其餘更新時還原連線。
### 階段 3：啟用後續 CA
在我們完成後續 CA 分佈至 EKS 中的所有 AWS 受管元件之後，即可啟用後續 CA。我們建議您在自己的時間軸上啟用後續 CA。給自己足夠的時間來探索和更新您管理的工作者節點和外部用戶端，以信任後續 CA。啟用後續 CA 之後，EKS 叢集會發行後續 CA 簽署的憑證。傳出 CA 仍受信任，但不再用於簽署。復原時段在啟用後有限期間內可用，可讓您視需要還原至傳出 CA。下一節會詳細說明轉返。
當您確信您管理的工作者節點和用戶端已更新時，您可以自行啟用後續 CA。如果沒有，我們會在到期截止日期接近時自動啟用後續 CA。
### 雙重信任期間
附加後續 CA （階段 1) 到淘汰傳出 CA 之間的時間稱為雙重信任期間。在此期間，EKS 叢集會同時信任這兩個 CAs。這就是讓輪換不中斷的原因：元件可以遞增更新，因為 EKS 叢集接受任一 CA 簽署的憑證。
雙重信任期間可讓您有時間識別和更新您管理的所有工作者節點和外部用戶端，而無需同時協調所有變更。
**注意**
在雙重信任期間，叢集的信任套件包含兩個 CAs。這是 .pem 編碼信任套件的標準行為。在輪換開始之前，將執行嚴格單一 CA 驗證或 CA 鎖定的應用程式更新為接受多個 CAs。
請務必了解後續 CA 的啟用如何影響連線。當用戶端連線到 API 伺服器時，它會檢查伺服器的憑證是否由其信任的 CA 簽署，以驗證伺服器的身分。
啟用後續 CA 之後，API 伺服器會顯示其由後續 CA 簽署的憑證。已更新其信任套件以包含後續 CA 的用戶端將成功驗證並正常連線。尚未更新其信任套件的用戶端將無法辨識伺服器的憑證，也無法建立連線。
下圖顯示後續 CA 啟用後的 TLS 連線流程。
這就是為什麼在啟用後續 CA 之前更新工作者節點和外部用戶端很重要：他們需要其信任套件中的後續 CA 來驗證 API 伺服器的身分和連線。雙重信任期間和 CA 轉返可為您提供時間和安全網路來完成此操作。
## 共同責任模型
Amazon EKS 中的 CA 輪換遵循廣泛套用的相同共同責任模型 AWS。 AWS 負責雲端基礎設施的安全性和可用性，而且您需負責其中工作負載的安全性和組態。如需如何將共同責任套用至 Amazon EKS 的詳細資訊，請參閱 [EKS 安全最佳實務](https://docs.aws.amazon.com/eks/latest/best-practices/security.html)。
在 CA 輪換的情況下，這表示：
### AWS 負責
+ 更新 EKS 叢集控制平面以信任並從後續 CA 發行憑證
+ 更新 EKS Auto Mode 節點以信任後續 CA
+ 更新 AWS Fargate 節點以信任後續 CA
+ 確保在 EKS 中發佈至 AWS 受管元件完成之前，無法啟用後續 CA
+ 在整個輪換生命週期中保留 EKS 叢集可用性
+ 在輪換程序的每個階段通知您
+ 如果您在 CA 接近過期之前未採取行動，則自動啟動輪換
### 您負責
+ 更新您的外部用戶端 （開發人員工作站、CI/CD 管道、監控工具、自動化） 以信任後續 CA
+ 更新您的工作者節點 （受管節點群組、Karpenter 控制節點、自我管理節點、混合節點） 以信任後續 CA
+ 當您確定您的元件已更新時，啟用後續 CA
我們無法代表您執行這些動作。外部用戶端存在於 AWS 操作界限之外。非由 EKS Auto Mode 或 Fargate 管理的工作者節點會在啟動時間或透過只有您控制的引導程序設定其 CA 信任組態。這與 TLS 信任的運作方式一致：用戶端擁有自己的信任存放區，只有用戶端的管理員可以更新它。
以下各節會在每一端展開：對您 AWS 有何幫助，以及您需要做什麼，以及如何執行的step-by-step指引。
## 為您 AWS 做什麼
AWS 會在 EKS 叢集的 CA 輪換生命週期中管理下列項目：
### 自動建立 CA
如果您未在自己的時間軸上附加後續 CA，我們會在 EKS 叢集的傳出 CA 接近過期時自動附加 CA。這可確保輪換程序從足夠的時間開始，讓您可以在過期截止日期之前探索和更新用戶端。
### 控制平面更新
我們會自動更新 EKS 叢集控制平面，以信任後續 CA。啟用後續 CA 之後，控制平面會發行後續 CA 簽署的憑證。控制平面不需要您採取任何動作。
### EKS Auto 模式和 Fargate 更新
我們會自動更新 EKS Auto Mode 節點和 Fargate Pod，以信任後續 CA。這些元件完全由我們管理，而且在 CA 輪換期間不需要您採取任何動作。
### EKS 功能更新
我們會自動更新 EKS 功能 (Kubernetes (ACK)、Argo CD 和 kro (Kube Resource Orchestrator) 的AWS 控制器），以信任後續 CA。這些受管資源會與您叢集的 API 伺服器通訊，並在 CA 分佈程序中更新。對於 EKS 功能中的受管資源，您不需要採取任何動作。如需詳細資訊，請參閱 [EKS 功能](https://docs.aws.amazon.com/capabilities/capabilities.html)。
### 分佈狀態追蹤
在我們更新 EKS 叢集中的受管元件時，您可以監控 CA 分佈狀態的進度。這會告訴您我們是否已完成輪換。分佈完成之前，無法啟用後續 CA。
### 內建防護措施
我們有內建的保護措施，可在輪換期間保護您的 EKS 叢集：
+ 在 EKS 中所有 AWS 受管元件的分佈完成之前，無法啟用後續 CA
+ 當 AWS附加的後續 CA 是叢集上唯一的後續 CA 時，就無法刪除。此保護措施可確保叢集一律具有有效的 CA 路徑，以防止過期。啟用後續 CA 之後，即可刪除傳出 CA。
+ 在 CA 到期前達到兩年標記後，無法刪除客戶套用的後續 CA。在此時間點之後，CA 會受到保護，不會遭到刪除，以確保您的叢集一律具有後續 CA，做為過期方法。
+ 如果過期截止日期接近且您尚未自行啟用，我們會自動啟用後續 CA
這些保護措施可確保 EKS 叢集在整個輪換生命週期中保持可用性，無論您是否採取行動。
### 通知
我們在 CA 輪換生命週期的每個階段通知您。通知會透過 AWS Health、Cluster Insights 和電子郵件傳送。每個通知都會告訴您發生了什麼、您需要採取什麼動作 （如果有的話），以及 EKS 叢集在輪換時間軸中的位置。
| 通知 | 當 | 代表什麼意思 |
| --- | --- | --- |
| CA 到期提醒 | CA 過期前 2.5 年 | EKS 叢集的 CA 具有定義的過期日期。規劃輪換。 |
| 已附加後續 CA | 當您或 AWS 附加後續 CA 時 （在過期前 2 年自動附加） | 輪換程序已開始。 AWS 正在將後續 CA 分發給受管元件。 |
| 分佈完成 | 附加後不久 （依叢集而異） | AWS 已完成其端。您現在可以更新您管理的工作者節點和外部用戶端。 |
| 啟用警告 | 自動啟用前 60 天 | 我們很快就會啟用後續 CA。如果您尚未更新元件，請更新元件。 |
| 啟用後續 CA | 當您或 AWS 啟用時 （過期前 6 個月自動啟用） | EKS 叢集現在正在從後續 CA 發行憑證。 |
| 最終自動啟用 （如果復原） | 過期前 45 天 | AWS 會啟用後續 CA。沒有可用的 CA 轉返。 |
**注意**
在 2018-2019 中建立的叢集具有不同的通知時間軸。這些叢集將依調整後的排程收到自動通知。
您也可以使用 Amazon EventBridge 設定自己的通知，將 CA 輪換事件整合到現有的監控和提醒工作流程中。
## 您需要做什麼 （以及原因）
成功的 CA 輪換需要您更新 AWS 無法代表您到達的元件。這些分為兩個類別：
### 外部用戶端
從叢集外部連線至 EKS 叢集 API 伺服器的任何系統。這包括開發人員工作站、CI/CD 管道 (Jenkins、GitHub Actions、GitLab、ArgoCD)、監控和可觀測性工具、自動化指令碼，以及使用 kubeconfig 與 API 伺服器通訊的任何應用程式。
這些系統各自維護自己的信任組態。啟用後續 CA 時，API 伺服器會顯示後續 CA 簽署的憑證。在啟用後續 CA 之前，更新這些用戶端以信任後續 CA，確保它們保持連線。如果錯過用戶端，CA 轉返可以在您完成更新時還原存取權。
### 工作者節點 （非 EKS Auto Mode、非 Fargate)
非由 EKS Auto Mode 或 Fargate 管理的工作者節點會在啟動時間或透過 kubelet 引導程序設定其 CA 信任組態。這些節點需要重新整理，以便他們信任後續 CA。所需的動作取決於工作者節點的類型：
#### 受管節點群組
執行節點群組版本更新，這會觸發節點的滾動取代。具有更新 CA 信任組態的新節點自動引導。
#### Karpenter 控制的節點
如果啟用偏離偵測，Karpenter 將在設定的偏離時段內循環節點，而新節點將在沒有手動動作的情況下取得後續 CA。如果偏離偵測已停用或設定為長視窗，請將這些節點視為與自我管理節點相同的節點。
#### 自我管理的節點
取代節點，使其以更新的 CA 信任組態引導。這通常涉及使用更新的 CA 資料更新啟動範本，並透過 Auto Scaling 群組觸發滾動替換。
#### 混合節點
更新每個混合節點上的信任組態，以包含後續 CA。特定程序取決於如何啟動混合節點，以及如何管理其信任組態。
您可以使用 Cluster Insights 來識別 EKS 叢集中執行的工作者節點類型。更新每種類型的step-by-step指引會在下一節中提供。
如果遺漏任何工作者節點，我們會提供 CA 轉返做為安全網路。不過，在啟用後續 CA 之前更新所有工作者節點，可避免完全中斷連線。在啟用後續 CA 之前未更新的節點將失去與 EKS 叢集 API 伺服器的連線，直到替換或執行 CA 轉返為止。
### 為什麼只有您才能這樣做
外部用戶端存在於 AWS 操作界限之外。在您的公司網路中執行的 CI/CD 管道，開發人員的筆記型電腦，即內部部署託管的監控工具： AWS 沒有機制可以連線到這些系統並更新其信任組態。
非 EKS Auto Mode 工作者節點可透過您擁有的啟動範本、使用者資料指令碼或引導程序來控制其信任組態。更新它們需要取代節點或修改其組態，這兩者都是基礎設施中的動作。
這是 Kubernetes 目前使用的 TLS 信任模型的限制。API 伺服器沒有通訊協定層級機制可查詢用戶端是否已更新其信任套件。伺服器只能在用戶端連線時呈現其憑證。如果用戶端信任簽署它的 CA，連線會成功。如果沒有，則會失敗。沒有允許 代表您 AWS 確認元件整備的啟用前驗證路徑。
### 何時開始
儘早開始識別您的外部用戶端。這是 CA 輪換中最耗時的部分，特別是在具有多個團隊，可獨立將工作負載部署到 EKS 叢集的環境中。您越早開始用戶端探索，就越能在團隊間無壓力地協調更新。
以下各節提供如何更新每種類型的用戶端和工作者節點的詳細指導。
## 先決條件
開始 CA 輪換之前，請確認下列事項：
+ ** AWS CLI：**2.x 版或更新版本。CA 輪換 APIs可在最新的 CLI AWS 中使用。執行 `aws --version`以檢查。
+ **主控台存取：**適用於支援區域的 Amazon EKS 主控台提供 CA 輪換。
+ **區域可用性：**CA 輪換可在支援 Amazon EKS 的所有 AWS 商業區域中使用。
除了管理 EKS 叢集所需的許可之外，不需要額外的 IAM 許可。如果您現在可以為 EKS 叢集呼叫 EKS APIs，則可以執行 CA 輪換。
## 開始使用
您可以使用 AWS CLI 或 Amazon EKS 主控台執行 CA 輪換。確定您正在執行 AWS CLI 2.x 版或更新版本 (`aws --version` 檢查）。
### 使用 AWS CLI
下列演練涵蓋使用 CLI 和 EKS API AWS 的end-to-end CA 輪換程序。 APIs
#### 步驟 1：檢查您的作用中 CA
檢視 EKS 叢集上的作用中憑證授權單位。
```
aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2
```
預期的輸出結果：
```
{
"certificateAuthorities": [
{
"id": "a1b2c3d4-5678-90ab-cdef-example11111",
"createdAt": "2024-01-15T10:30:00-07:00",
"createdBy": "EKS",
"activatedAt": "2024-01-15T10:30:00-07:00",
"activatedBy": "EKS",
"signingStatus": "IN_USE",
"distributionStatus": "COMPLETE"
}
]
}
```
這會顯示建立 EKS 叢集時所建立的 CA。它目前正在使用 （簽署憑證） 且分佈已完成 (EKS 中的所有 AWS 受管元件都信任它）。
#### 步驟 2：檢視 CA 詳細資訊和過期
```
aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id a1b2c3d4-5678-90ab-cdef-example11111 --region us-west-2
```
預期的輸出結果：
```
{
"certificateAuthority": {
"id": "a1b2c3d4-5678-90ab-cdef-example11111",
"createdAt": "2024-01-15T10:30:00-07:00",
"createdBy": "EKS",
"activatedAt": "2024-01-15T10:30:00-07:00",
"activatedBy": "EKS",
"signingStatus": "IN_USE",
"distributionStatus": "COMPLETE",
"validity": {
"notBefore": "2024-01-15T10:30:00-07:00",
"notAfter": "2029-01-14T10:30:00-07:00"
},
"rollbackAvailable": false
}
}
```
`validity` 區塊會顯示 CA 建立的時間 (`notBefore`) 和過期的時間 (`notAfter`)。 `rollbackAvailable`指出您是否可以在啟用後續 CA 之後還原至先前的 CA。對於使用 EKS 叢集建立的初始 CA，`false`這是因為沒有先前的 CA 可還原。
**注意**
`scheduledEvents` 區塊 （包含 `firstAutoActivation`和 `finalAutoActivation`) 會出現在後續 CA 上，而不是傳出 CA。如果您尚未自行啟用，這些欄位會顯示我們自動啟用後續 CA 的時間。當您在附加後描述後續 CA 時，您會看到這些欄位。
#### 步驟 3：附加後續 CA
```
aws eks create-certificate-authority --cluster-name my-cluster --region us-west-2
```
這會將後續 CA 附加到您的 EKS 叢集。回應包含`updateId`可用來追蹤進度的 。
#### 步驟 4：追蹤更新
```
aws eks describe-update --name my-cluster --update-id a1b2c3d4-update-id --region us-west-2
```
等待更新狀態為 `Successful`。
**注意**
如果更新狀態顯示 ，`UPDATE_FAILED`且後續 CA `distributionStatus`顯示 `FAILED`，則 CA 建立未成功。使用 刪除失敗的 CA，`aws eks delete-certificate-authority`並建立新的 CA。對於 AWS啟動的自動輪換， 會在附加新的後續程式之前 AWS 自動偵測和清除失敗CAs，因此在該案例中不需要客戶動作。
#### 步驟 5：驗證分佈狀態
```
aws eks list-certificate-authorities --cluster-name my-cluster --region us-west-2
```
您現在應該會看到兩個 CAs。更新 EKS 叢集中的所有 AWS 受管元件`COMPLETE`後，後續 CA 將擁有 `signingStatus: NOT_USED`，`distributionStatus`並將從 進展`IN_PROGRESS`至 。
在後續 CA 的分佈狀態為 之前，請勿繼續`COMPLETE`。
#### 步驟 6：更新您的 kubeconfig
```
aws eks update-kubeconfig --name my-cluster --region us-west-2
```
這會將您的本機 kubeconfig 更新為信任這兩個 CAs。之後，您的 kubectl 命令會在後續 CA 啟用後繼續運作。
#### 步驟 7：更新您管理的工作者節點和外部用戶端
這會在下一節中詳細說明。在您管理的所有工作者節點和外部用戶端更新為信任後續 CA 之後，請繼續啟用。
#### 步驟 8：啟用後續 CA
```
aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id --region us-west-2
```
啟用後續 CA 後，EKS 叢集會發行後續 CA 簽署的憑證。驗證連線，以確認所有元件都如預期般運作。
### 使用 Amazon EKS 主控台
Amazon EKS 主控台提供 CA 輪換的引導式體驗。您可以直接從主控台檢視 CA 狀態、附加後續 CA、監控分佈進度，以及啟用後續 CA。
下圖顯示在作用中輪換期間 Amazon EKS 主控台中的憑證授權機構詳細資訊檢視。作用中 CA 和後續 CA 都會顯示其簽署狀態、過期日期和過期天數。
下圖顯示 Amazon EKS 主控台中的輪換進度檢視。輪換程序的每個步驟都會以其目前狀態顯示，包括附加、分佈、更新工作者節點和外部用戶端、啟用和刪除傳出 CA。
## 更新您的 Kubernetes 用戶端
**重要**
在雙重信任期間，叢集的信任套件包含兩個 CA 憑證。兩個 base64 編碼 CAs 的合併大小約為 2.8 KB （或使用 gzip 壓縮約 1.9 KB)。對於在 EC2 啟動範本中提供自訂使用者資料的工作者節點，請確認您的總使用者資料大小不超過 [EC2 使用者資料限制 16KB](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html)。如果您現有的使用者資料接近此限制，請考慮使用 gzip 壓縮使用者資料內容，以減少大小。
在附加後續 CA 且 AWS 完成對 EKS 叢集 (`distributionStatus: COMPLETE`) 中受管元件的分發之後，您需要更新自己的元件以信任後續 CA。在此內容中，「用戶端」是連線到 EKS 叢集 API 伺服器的任何系統。這包括本機 kubectl 組態、CI/CD 管道、監控工具、自動化指令碼和工作者節點。
EKS 叢集 （現在包含目前和後續 CA) 的更新 CAs 資料可以使用下列方式擷取：
```
aws eks describe-cluster --name my-cluster --region us-west-2 --query 'cluster.certificateAuthority.data' --output text
```
使用此值來更新下列小節中每個用戶端類型的信任組態。
### Kubeconfig （開發人員工作站、CI/CD 管道、自動化）
執行下列動作以更新本機 kubeconfig：
```
aws eks update-kubeconfig --name my-cluster --region us-west-2
```
這會自動擷取最新的 CA 資料並更新您的 kubeconfig。使用此 kubeconfig 的任何系統都會信任這兩個 CAs。
對於產生自己的 kubeconfig 的 CI/CD 管道和自動化 （例如，直接使用 EKS APIs 或將 kubeconfig 儲存為秘密），請使用從 擷取的值更新 `certificate-authority-data` 欄位`describe-cluster`。
### 受管節點群組
執行節點群組版本更新，以觸發節點的滾動取代：
```
aws eks update-nodegroup-version --cluster-name my-cluster --nodegroup-name my-nodegroup --region us-west-2
```
具有更新 CA 資料的新節點自動引導。滾動替換可確保節點一次替換一個節點，而不會中斷執行中的工作負載。
如果您透過 Terraform 或 CloudFormation 管理節點群組，CA 輪換不會在您的 IaC 狀態建立偏離。CA 生命週期是透過與您的叢集資源組態分開的專用 EKS APIs 進行管理。如需 CA 輪換如何以程式碼形式與基礎設施互動的詳細資訊，請參閱基礎設施即程式碼一節。
#### 具有自訂 AMI 的自訂啟動範本
如果您的節點群組是使用自訂 AMI 部署， AWS 不會合併使用者資料。您負責提供正確的引導組態，包括更新的 CA 信任套件。CA 輪換不會為您更新使用者資料，沒有後續 CA 的節點無法加入叢集。
1. 擷取更新的 CA 資料 （包含傳出和後續 CAs的合併信任套件）：
```
aws eks describe-cluster --name my-cluster --region us-west-2 --query 'cluster.certificateAuthority.data' --output text
```
1. 更新啟動範本使用者資料中的 CA 資料。您指定 CA 資料的方式取決於您的作業系統和引導機制，並符合您最初提供的方式。如需自訂受管節點的詳細資訊，請參閱[使用啟動範本自訂受管節點](https://docs.aws.amazon.com/eks/latest/userguide/launch-templates.html)。
1. 使用更新的使用者資料建立新的啟動範本版本，然後將節點群組更新為該啟動範本版本。這會回收節點，以便它們使用後續 CA 引導：
```
aws eks update-nodegroup-version --cluster-name my-cluster --nodegroup-name my-nodegroup --launch-template id=,version= --region us-west-2
```
如需將節點群組更新為新啟動範本版本的詳細資訊，請參閱[更新叢集的受管節點群組](https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html)。
#### 驗證節點是否在更新的啟動範本上執行
在繼續啟用之前，請確認受管節點群組中的所有節點都在最新的啟動範本版本上執行。此版本必須包含更新的 CA 信任套件。
1. 取得節點群組的啟動範本。如果 `describe-nodegroup`傳回`launchTemplate`欄位，請直接使用它：
```
aws eks describe-nodegroup --cluster-name my-cluster --nodegroup-name my-nodegroup --region us-west-2 --query 'nodegroup.launchTemplate'
```
如果它未傳回`launchTemplate`欄位， 會在內部 AWS 管理啟動範本。改為透過 Auto Scaling 群組尋找：
```
ASG=$(aws eks describe-nodegroup --cluster-name my-cluster --nodegroup-name my-nodegroup --region us-west-2 --query 'nodegroup.resources.autoScalingGroups[0].name' --output text)
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names "$ASG" --region us-west-2 --query 'AutoScalingGroups[0].{LaunchTemplate: LaunchTemplate, MixedInstancesPolicy: MixedInstancesPolicy.LaunchTemplate.LaunchTemplateSpecification}'
```
**注意**
啟動範本可能低於`LaunchTemplate`或`MixedInstancesPolicy`取決於 Auto Scaling 群組組態。
1. 解碼啟動範本使用者資料。使用上一個步驟的啟動範本 ID 和版本。確認使用者資料中的 CA 資料符合 傳回的合併信任套件`describe-cluster`。保留 CA 資料的欄位取決於您的作業系統和引導機制：
```
aws ec2 describe-launch-template-versions --launch-template-id --versions --region us-west-2 --query 'LaunchTemplateVersions[0].LaunchTemplateData.UserData' --output text | base64 --decode
```
1. 確認升級後所有工作者節點都在最新的啟動範本版本上執行。描述節點群組的 Auto Scaling 群組。比較每個執行個體的啟動範本版本與群組目前的啟動範本版本。每個`InService`執行個體都必須在目前的版本上。滾動取代會耗盡處於 `Terminating` 狀態的執行個體。您可以忽略這些執行個體：
```
ASG=$(aws eks describe-nodegroup --cluster-name my-cluster --nodegroup-name my-nodegroup --region us-west-2 --query 'nodegroup.resources.autoScalingGroups[0].name' --output text)
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names "$ASG" --region us-west-2 --query 'AutoScalingGroups[0].Instances[].{InstanceId: InstanceId, LifecycleState: LifecycleState, LaunchTemplateVersion: LaunchTemplate.Version}' --output table
```
1. 確認取代節點運作狀態良好。節點群組中的每個節點都必須是 `Ready`，確認 kubelet 已使用更新的 CA 信任套件建立與 API 伺服器的連線：
```
kubectl get nodes -l eks.amazonaws.com/nodegroup=my-nodegroup
```
### Karpenter 控制的節點
如果在 Karpenter NodePool 中啟用偏離偵測，Karpenter 將自動偵測節點是否使用過時的 CA 資料執行，並在設定的中斷時段內循環它們。新節點無需手動動作即可取得後續 CA。
確認您的 NodePool 組態中已啟用偏離偵測：
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: default
spec:
disruption:
consolidationPolicy: WhenEmptyOrUnderutilized
budgets:
- nodes: "10%"
template:
spec:
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: default
```
如果`disruption`使用合併政策設定 ，則偏離偵測預設為作用中。Karpenter 將取代偏離其所需狀態的節點，其中包括 CA 資料變更。
如果啟用偏離偵測，請確認您的中斷預算允許在後續 CA 啟用日期之前取代所有 Karpenter 控制的節點。如果預算太嚴格 （例如，具有低取代百分比的狹窄維護時段），則並非所有節點都會及時取代。
如果偏離偵測已停用，或您的中斷預算限制取代超過輪換時間軸的時段，您可以透過封鎖和耗盡節點來手動觸發節點取代：
```
kubectl cordon
kubectl drain --ignore-daemonsets --delete-emptydir-data
```
Karpenter 將佈建替代節點，以使用更新後的 CA 資料引導。
### 自我管理的節點
對於自我管理節點，您需要更新啟動範本中的 CA 資料或節點在引導期間使用的使用者資料指令碼：
1. 擷取更新的 CA 資料：
```
aws eks describe-cluster --name my-cluster --region us-west-2 --query 'cluster.certificateAuthority.data' --output text
```
1. 使用更新的 CA 資料值更新您的啟動範本 （或使用者資料）。
1. 透過 Auto Scaling 群組觸發節點的滾動取代 （例如，執行個體重新整理）。
新節點將使用更新的 CA 資料引導，並信任目前和後續 CAs。
### AWS Fargate Pod (EKS Fargate 啟動類型）
AWS EKS 叢集中的 Fargate Pod 與其他 EKS 資料平面啟動模式 （受管節點群組、自我管理節點、Karpenter 控制節點） 的運作方式不同。
當 Pod 連線到 API 伺服器時，會發生兩件事：Pod 會使用其服務帳戶字符 （向 API 伺服器提供其身分） 進行身分驗證，而 Pod 透過檢查伺服器憑證是否由其信任的 CA 簽署來驗證 API 伺服器身分。存放在 Pod 環境中的 CA 資料是實現此驗證的原因。如果 API 伺服器開始呈現由 Pod 不信任的後續 CA 簽署的憑證，Pod 會拒絕連線。
在其他 EKS 資料平面啟動模式中 （受管節點群組、自我管理節點、Karpenter 控制節點），CA 資料會存在於節點上。當您取代節點時，新的節點引導會使用更新的 CA 資料。排程在該新節點上的 Pod 會收到更新的 CA 資料，允許他們驗證 API 伺服器，無論哪個 CA 簽署其憑證。
在 Fargate 中，每個 Pod 都會使用自己的 kubelet 程序，在自己的專用運算環境中執行。在建立 Pod 時，此 kubelet 引導具有 CA 資料。下方沒有共用節點，而且您無法直接存取基礎運算。
**在 CA 輪換期間，EKS 中的 AWS Fargate 節點不需要客戶動作。** AWS 自然會透過其修補程序回收 Fargate 節點中的 Pod。在附加後續 CA 之後，作為此程序的一部分，會回收預先存在的 Fargate Pod。他們無需您採取任何動作即可信任後續 CA。由於 會在 AWS EKS 中的任何起始 CA 啟用時間軸之前 AWS 附加後續 CA，因此 Fargate Pod 將回收，並在 AWS 啟用後續 CA 的時間之前信任後續 CA。有內建的保護措施，可防止啟用後續 CA，直到 Fargate Pod 完成回收。
這表示 EKS 叢集的受管資料平面選項 (EKS Auto Mode 和 Fargate) 具有相同的 CA 輪換使用者體驗：工作者節點不需要客戶動作。您仍需負責更新連線至 API 伺服器的任何外部用戶端。
這是邊緣案例。鑑於輪換時間表 （後續 CA 在過期前幾年附加），在絕大多數情況下，自然修補週期會在啟動後續 CA 之前順利完成。在客戶嘗試提早啟用的罕見情況下，防護措施做為預防措施存在。
### 外部用戶端 （監控工具、第三方整合）
使用 kubeconfig 或憑證信任組態連線到 EKS 叢集 API 伺服器的任何應用程式或工具都需要更新為更新的 CA 資料。其中包含：
+ 監控和可觀測性工具 (Datadog、Prometheus、Grafana 代理程式）
+ 在叢集外部執行的 GitOps 控制器 (ArgoCD、Flux)
+ 呼叫 Kubernetes API 的自訂自動化或指令碼
+ 儲存`certificate-authority-data`為靜態值的任何系統
對於這些項目，請將儲存的 CA 資料取代為來自 的更新值`describe-cluster`。
### 如何確認用戶端已更新
更新用戶端後，請確認用戶端仍可與 API 伺服器通訊：
```
kubectl get nodes
```
如果命令成功，您的 kubeconfig 會信任作用中的 CA 資料。啟用後續 CA 之後，請執行相同的命令以確認持續連線。
## 基礎設施即程式碼
您可以與現有基礎設施一起執行 CA 輪換做為程式碼 (IaC)，而無需建立偏離或需要變更 IaC 組態。
### 為什麼 CA 輪換不會影響您的 IaC 狀態
CA 生命週期是透過與 EKS `create-certificate-authority`叢集資源組態完全分開的專用 EKS APIs (`activate-certificate-authority`、、`delete-certificate-authority`) 進行管理。無論您是由您啟動還是由 自動啟動 CA 輪換 AWS，都不會修改 EKS 叢集資源上 IaC 工具追蹤的任何屬性。
這表示：
+ 在附加或啟用 CA 之後套用或更新 IaC 堆疊，不會偵測到偏離或嘗試協調 CA 狀態
+ 透過 CLI 或主控台啟動的 CA 輪換操作不會與 IaC 受管叢集資源衝突
傳回`certificateAuthority.data`的欄位`describe-cluster`是唯讀輸出。它反映了目前的合併信任套件 （兩個 CAs雙重信任期間），但不是可設定的屬性。IaC 工具不會將其追蹤為要協調的項目。
每個 CA 記錄上的屬性欄位 (`createdBy`、`activatedBy`) 可讓您區分啟動的操作和自動 AWS 啟動的操作，以支援稽核和變更管理工作流程。
### 搭配 CA 輪換使用 CloudFormation
您可以在 `AWS::EKS::Cluster` 資源上使用 WriteOnly 屬性，透過 CloudFormation 觸發 CA 輪換。此屬性會觸發啟用，但不會存放在堆疊的狀態，因此後續堆疊更新時不會嘗試還原或停用。
```
# Phase 1: Add to existing stack that manages your cluster
Resources:
NewCA:
Type: AWS::EKS::CertificateAuthority
Properties:
ClusterName: my-cluster
MyCluster:
Type: AWS::EKS::Cluster
Properties:
Name: my-cluster
```
第一個堆疊更新會將後續 CA 附加到您的叢集。等待後續 CA 的分佈狀態到達，`COMPLETE`然後再繼續。
```
# Phase 2: After distribution completes, update your existing Cluster resource to activate
Resources:
NewCA:
Type: AWS::EKS::CertificateAuthority
Properties:
ClusterName: my-cluster
# Update your existing Cluster resource to activate
MyCluster:
Type: AWS::EKS::Cluster
Properties:
Name: my-cluster
ActiveCertificateAuthorityId: !GetAtt NewCA.Id
```
第二個堆疊更新會觸發後續 CA 的啟用。由於 `ActiveCertificateAuthorityId` 是 WriteOnly 屬性，因此不會在讀取時傳回，而且如果作用中 CA 在 CloudFormation 外部變更 （例如，透過自動啟用方式），CloudFormation 將不會偵測偏離 AWS。
重要：CA 輪換 CloudFormation 整合遵循與典型 CloudFormation 資源不同的模式。EKS 中的憑證授權機構不是具有自己的 ARN 的獨立資源。它在叢集的憑證生命週期中存在，並透過叢集本身授權，類似於如何透過其父角色 (`AWS::IAM::RolePolicy`) 授權 IAM 角色政策，或透過其執行個體 () 授權 EIP 關聯`AWS::EC2::EIPAssociation`。透過 CloudFormation 管理 CA 輪換的客戶應注意此差異。
### 受管節點群組和 IaC
使用更新的 CA 信任組態執行節點群組版本更新以重新整理節點是一種操作動作。新節點會使用來自叢集的作用中 CA 信任資料自動引導。如果您的 IaC 範本未在啟動範本或使用者資料中硬式編碼 CA 資料，則不需要變更範本。
## CA 轉返
啟用後續 CA 之後，如果您發現您管理的工作者節點 （非 EKS Auto Mode、非 Fargate) 或外部用戶端發生連線問題，則可以轉返到先前的 CA。轉返會將先前的 CA 重新啟用為 EKS 叢集的簽署授權。
### 當 CA 轉返可用時
CA 復原可在 CA 啟用後使用，只要：
+ CA 啟用是由客戶起始或第一次自動啟用 AWS （大約在傳出 CA 過期前 6 個月）
+ 轉返視窗尚未過期
您可以使用 傳回的 `rollbackAvailable` 欄位，隨時檢查 CA 轉返是否可用`describe-certificate-authority`：
```
aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id --region us-west-2
```
```
{
"certificateAuthority": {
"id": "a1b2c3d4-5678-90ab-cdef-example22222",
"signingStatus": "IN_USE",
"distributionStatus": "COMPLETE",
"rollbackAvailable": true
}
}
```
### 當 CA 轉返不可用時
最終自動啟用後，無法使用 CA 轉返。如果 最後一次 AWS 啟用後續 CA (CA 過期前 45 天），輪換必須繼續進行。只有在第一次自動啟用之前已復原時，才會發生最終自動啟用。它作為最後的防護措施存在，以確保 EKS 叢集不會在沒有有效 CA 的情況下達到 CA 過期。
### 如何轉返
若要轉返，請重新啟用先前的 CA：
```
aws eks activate-certificate-authority --cluster-name my-cluster --certificate-authority-id --region us-west-2
```
### CA 復原期間會發生什麼情況
+ 先前的 CA 會繼續簽署 EKS 叢集的簽署憑證
+ 接續 CA 會保留在信任套件中 （這兩個 CAs 仍然受信任）
+ 已更新以信任後續 CA 的工作者節點和用戶端將繼續運作 （他們信任這兩個 CAs)
+ 尚未更新的工作者節點和用戶端將恢復正常操作 (API 伺服器正在呈現由他們已經信任的 CA 簽署的憑證）
+ 工作者節點上的 Kubelet 程序會透過其內建的重試迴圈自動重新連線
### 何時考慮 CA 轉返
CA 轉返是一種安全機制，適用於後續 CA 啟用顯示您未事先發現的連線問題的情況：
+ 在更新階段期間未識別的外部用戶端在後續 CA 啟用後失去連線
+ 監控或可觀測性工具無法驗證新憑證
+ CI/CD 管道因為使用硬式編碼憑證信任組態而中斷
轉返後，您可以保留完整的雙信任期，以在重新啟用後續 CA 之前識別和修正問題。
## 不含 CA 轉返的復原
如果您在更新受管節點群組之前啟用後續 CA，且 CA 復原時段不再可用 （例如，在最終自動啟用截止日期之後），您可以透過對受影響的節點群組執行滾動更新來復原。不過，初始滾動更新嘗試將會失敗，因為中斷連線的節點無法從 API 伺服器接收 Pod 移出命令。
### 復原步驟
1. 識別 NotReady 節點：
```
kubectl get nodes
```
1. 列出每個 NotReady 節點上的 Pod：
```
kubectl get pods --all-namespaces --field-selector spec.nodeName=
```
1. 強制刪除每個 NotReady 節點上的所有 Pod：
```
kubectl delete pod --force --grace-period=0 -n
```
1. 重試滾動更新：
```
aws eks update-nodegroup-version --cluster-name --nodegroup-name --region
```
1. 驗證節點復原：
```
kubectl get nodes
```
**重要**
強制刪除 Pod 會無可追溯地終止工作負載。狀態工作負載可能會遺失資料。在 Auto Scaling 群組終止容器之前，容器可能會繼續在中斷連線的執行個體上執行。這是當 CA 轉返視窗不再可用時的最後手段。
## 考量和限制
### 區域可用性
CA 輪換可在支援 Amazon EKS 的所有 AWS 商業區域中使用。
### 最多兩個 CAs
EKS 叢集隨時最多可以有兩個 CAs：作用中 CA 和一個後續 CA。在先前的輪換完成之前，您無法附加第二個後續 CA。
### 無憑證撤銷
CA 輪換不支援撤銷個別憑證。這與上游 Kubernetes 一致，上游 Kubernetes 不會實作憑證撤銷 (CRL 或 OCSP)。輪換會取代整個 CA，從信任套件中移除傳出 CA 簽署的所有憑證，自然會使其失效。
### AWS無法刪除 附加CAs
如果 AWS 自動附加後續 CA，則無法刪除它。此保護措施可確保輪換程序不會因意外刪除而中斷。只要客戶附加CAs 不是作用中簽署 CA，就可以將其刪除。
### CA 有效期間
使用叢集建立的原始 CA 具有 10 年的有效期。透過輪換程序建立的後續 CAs具有 5 年有效期間。您叢集的所有未來 CAs都將遵循 5 年有效期間。使用 檢查您的 CA 過期`describe-certificate-authority`。
### 雙重信任期間的 EC2 使用者資料大小
在雙重信任期間，由於包含兩個 CA 憑證 （合併約 2.8 KB，或使用 gzip 壓縮約 1.9 KB)，叢集的信任套件大小會增加。對於在 EC2 啟動範本中提供自訂使用者資料的工作者節點，請確認您的總使用者資料大小不超過 [EC2 使用者資料限制 16KB](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html)。如果您現有的使用者資料接近此限制，新增第二個 CA 可能會導致啟動範本建立失敗，並防止佈建新的節點。請考慮使用 gzip 壓縮您的使用者資料內容，以減少大小。
### CA 輪換期間的版本升級
EKS 叢集版本升級和 CA 輪換是獨立的操作。不過，您無法同時執行兩者。如果 CA 輪換操作正在進行中，版本升級將被拒絕，直到 CA 操作完成，反之亦然。
### 自攜 CA (BYOCA)
目前不支援使用您自己的 AWS 私有 CA 來備份 EKS 叢集的憑證。
## 常見問答集
### 如何開始使用 CA 輪換？
若要開始使用，請執行 `aws eks list-certificate-authorities --cluster-name my-cluster`以檢視作用中的 CA 及其過期時間。如果您準備好開始輪換，請執行 `aws eks create-certificate-authority --cluster-name my-cluster` 以附加後續 CA。入門一節涵蓋完整的step-by-step程序。您也可以透過 Amazon EKS 主控台執行 CA 輪換。
### CA 輪換是否有任何相關成本？
否。所有 EKS 叢集可免費使用 CA 輪換。
### 如果我未在 CA 過期之前輪換 CA，會發生什麼情況？
我們有自動保護措施，可防止 EKS 叢集在沒有有效 CA 的情況下達到 CA 過期。如果您不自行啟動 CA 輪換，我們會在過期之前自動附加並啟用後續 CA，確保您的叢集保持可用。
不過，成功輪換也需要您更新管理的工作者節點 （非 EKS Auto Mode、非 Fargate) 和外部用戶端，以信任後續 CA。如果這些元件未在後續 CA 啟用之前更新，它們將失去與 API 伺服器的連線。
在 Kubernetes 中，如果 CA 未在到期之前輪換，則該 CA 簽署的所有憑證都會失效。任何用戶端都無法再連線 API 伺服器，而且叢集無法使用。
### 我有多少時間可以完成 CA 輪換？
完成 CA 輪換的整體時間取決於 AWS 自動化防護措施和您自己的更新程序。
AWS 提供其管理項目的最終時間表。後繼 CA 會在傳出 CA 到期前約 2 年附加。如果您不自行啟用後續 CA，我們會在過期前約 6 個月自動啟用它。如果您在自動啟用後轉返，我們會在過期前 45 天執行最終自動啟用。這些保護措施可確保您的 EKS 叢集保持可用，無論您是否採取行動。
成功的 CA 輪換也取決於您更新管理的工作者節點 （非 EKS Auto Mode、非 Fargate) 和外部用戶端，以在啟用後續 CA 之前信任後續 CA。這需要多長時間，取決於資料平面的工作者節點組態、外部用戶端使用量，以及執行這些元件的探索和更新所需的時間。
### CA 輪換是否會導致我的叢集停機？
否。您的 EKS 叢集在整個 CA 輪換生命週期中仍然可用。控制平面會繼續在每個階段提供請求。在雙重信任期間，傳出 CA 和後續 CAs都會同時受信任，允許元件遞增更新，而不會中斷叢集操作。如果您因為發現用戶端問題而轉返到先前的 CA， 會在傳出 CA 過期前約 45 天 AWS 執行最終轉返，作為保護。
請務必區分 EKS 叢集 （控制平面） 和您的資料平面元件。控制平面由 完全管理 AWS ，並在整個輪換過程中保持可用。
對於 EKS Auto Mode 和 Fargate， 會自動 AWS 更新工作者節點。在這些資料平面啟動模式中，工作者節點沒有連線中斷的風險。您仍需負責更新連線到 API 伺服器的任何外部用戶端。
對於受管節點群組、自我管理節點、Karpenter 控制執行個體 （未啟用偏離偵測） 和混合節點，在啟用後續 CA 之前，您必須負責取代或更新這些節點。如果未取代這些節點，這些節點會在後續 CA 啟動後失去與控制平面的連線，即使控制平面本身仍能完全運作。
### 我的工作負載是否會在 CA 輪換期間中斷？
執行中的工作負載 (Pod) 不會因 CA 輪換本身而中斷。Pod 透過叢集網路彼此通訊，這不受 CA 變更影響。CA 用於元件與 API 伺服器之間的通訊，而非 pod-to-pod流量。
如果您的工作者節點需要替換為更新它們以信任後續 CA 的一部分 （例如，執行滾動更新的受管節點群組，或 Karpenter 替換漂移節點），這些節點上的 Pod 將重新排程為正常節點替換程序的一部分。這是節點替換期間的標準 Kubernetes 行為，不是 CA 輪換的副作用。確保您已針對關鍵工作負載設定 Pod 中斷預算 (PDBs)，以控制節點取代期間如何移出 Pod。
### 我叢集的 CA 何時過期？
您可以使用 AWS CLI、EKS APIs 或 Amazon EKS 主控台來檢查叢集的 CA 何時到期。例如，您可以執行下列動作：
```
aws eks describe-certificate-authority --cluster-name my-cluster --certificate-authority-id --region us-west-2 --query 'certificateAuthority.validity.notAfter'
```
您可以執行 來尋找 CA 的 ID`aws eks list-certificate-authorities --cluster-name my-cluster`。
### 我叢集 CA 的有效期間是多久？
使用叢集建立的原始 CA 具有 10 年的有效期。透過輪換程序建立的後續 CAs具有 5 年有效期間。您叢集的所有未來 CAs都將遵循 5 年有效期間。您可以使用 檢查 CA 的過期時間`describe-certificate-authority`。
### 我可以先自行啟動 CA 輪換 AWS ，再自動啟動嗎？
是。您可以隨時使用 附加後續 CA`aws eks create-certificate-authority --cluster-name my-cluster`。您不需要等待 AWS 來啟動輪換。提早開始可讓您有更多時間根據自己的排程來識別和更新工作者節點和外部用戶端。
### 啟用後續 CA 後是否可以轉返？
是，只要轉返視窗尚未過期，CA 轉返會在啟用後續 CA 之後提供。CA 轉返會將先前的 CA 重新啟用為簽署授權。在最終自動啟用後 (CA 過期前 45 天） 無法使用此功能。您可以使用 檢查 CA 上的 `rollbackAvailable` 欄位`describe-certificate-authority`。如需詳細資訊，請參閱 CA 轉返一節。
### 如何知道啟用後續 CA 是安全的？
當您管理的所有工作者節點 （非 EKS Auto Mode、非 Fargate) 和外部用戶端已更新以信任後續 CA 時，可以安全地啟用後續 CA。您可以透過確認每個用戶端都可以使用更新的信任組態與 API 伺服器成功通訊來驗證這一點。 AWS 不提供所有用戶端都就緒的單一指標，因為它無法在您的外部系統中看到。提早開始探索程序，給自己時間來識別所有用戶端。
### 如何監控多個叢集的 CA 輪換進度？
您可以使用 CLI AWS 或 EKS API，以程式設計方式完成此作業。針對每個叢集使用 `aws eks list-certificate-authorities` 。下列欄位提供機群層級監控的情境感知：
+ `signingStatus`：指出 CA 是否正在主動簽署憑證 (`NOT_USED`、`ACTIVATING`、`IN_USE`)
+ `distributionStatus`：指出 是否 AWS 已完成將 CA 分配至受管元件 (`IN_PROGRESS`、`COMPLETE`、`FAILED`、`DELETING`)
+ `rollbackAvailable`：指出啟用後續 CA 後是否可使用 CA 轉返
+ `createdBy` / `activatedBy`：區分客戶起始和 AWS起始的操作 (`CUSTOMER`、`EKS`)
+ `scheduledEvents.firstAutoActivation` / `scheduledEvents.finalAutoActivation`：顯示即將到來的 AWS 自動啟用日期
下列範例指令碼會檢查叢集清單中的 CA 輪換狀態：
```
#!/bin/bash
CLUSTERS=("cluster-1" "cluster-2" "cluster-3")
REGION="us-west-2"
for CLUSTER in "${CLUSTERS[@]}"; do
echo "--- $CLUSTER ---"
aws eks list-certificate-authorities \
--cluster-name "$CLUSTER" \
--region "$REGION" \
--query 'certificateAuthorities[].{Id:id,Signing:signingStatus,Distribution:distributionStatus,Expiry:validity.notAfter}' \
--output table
done
```
您可以擴展此範圍以涵蓋多個區域和帳戶，並篩選已附加後續 CA、正在等待您的動作或即將接近自動啟用截止日期的叢集。
通知也會在輪換生命週期的每個階段，透過 AWS 運作狀態和電子郵件傳遞每個叢集。
### 如果我在更新所有用戶端之前啟用後續 CA，會發生什麼情況？
任何尚未更新以信任後續 CA 的用戶端都會失去與 EKS 叢集的連線。啟用後續 CA 之後，API 伺服器會呈現後續 CA 簽署的憑證。不信任用戶端的 TLS 驗證會失敗且無法連線。如果發生這種情況，您可以轉返到先前的 CA （如果轉返視窗仍然可用），以在修復剩餘的用戶端時還原連線。
### 如果我錯過 CA 過期截止日期，會發生什麼情況？
AWS 可防止這種情況發生。自動防護可確保您的 EKS 叢集不會在沒有有效 CA 的情況下達到 CA 過期。如果您尚未這樣做，我們將附加後續 CA，並在過期前約 6 個月自動將其啟用。如果您在第一次自動啟用後轉返， 會在過期前 45 天 AWS 執行最終轉返。您的叢集將保持可用。
不過，如果您管理的工作者節點 （非 EKS Auto Mode、非 Fargate) 和外部用戶端在自動啟用發生時尚未更新以信任後續 CA，這些元件將失去與 API 伺服器的連線。
### 在 CA 輪換期間，是否可以失去對叢集的存取權？
您的 EKS 叢集 （控制平面） 在整個 CA 輪換生命週期保持可用。 AWS 保護可確保叢集本身不會無法使用。
不過，如果您管理的個別用戶端在啟用後續 CA 之前未更新為信任後續 CA，則可能會失去存取權。例如，如果您的 kubeconfig、CI/CD 管道或監控工具仍然只參考傳出 CA，這些用戶端在啟用後續 CA 之後將無法連線。如果發生這種情況，CA 轉返可以在您更新受影響的用戶端時還原存取權。
### 我需要重新啟動 Pod 嗎？
執行中的工作負載 Pod 不會直接受到 CA 輪換的影響。每個節點上的 kubelet 會處理 API 伺服器通訊，因此只要您的節點已更新，工作負載 Pod 就會繼續執行而不會中斷。不過，在啟用後續 CA 之後，使用 client-go 與 API 伺服器通訊的叢集內控制器和運算子可能需要重新啟動，因為 client-go 不會動態重新讀取 CA 信任套件。對於 AWS Fargate 節點， 會透過自然 Pod 回收程序自動 AWS 處理更新。
### 我的信任套件是否會在輪換期間變更？
是。在 CA 輪換期間，叢集的信任套件會同時包含兩個憑證授權單位：傳出 CA 和後續 CA。這是雙信任期間預期的行為，也是輪換程序維持所有元件連線的方式。
應用程式和用戶端應設定為信任 CA 套件，而不是釘選到單一 CA 憑證。CA 鎖定 （不建議對單一 CA 進行嚴格驗證），因為它會在信任套件更新時導致失敗。這適用於連線到 EKS 叢集 API 伺服器的任何用戶端 TLS 組態。
### 為什麼我的通知時間表與本文件所述不同？
如果您的叢集是在 2018-2019 中建立，您的叢集將在調整後的時間軸上收到自動通知。您的第一個通知將包含叢集特定的相關日期和後續步驟。標準通知里程碑是根據叢集的 CA 過期日期來計算。對於此範圍內的叢集，這些計算日期早於此功能的可用性，因此會套用調整後的排程。