如何對無法加入 Amazon EKS Anywhere 叢集的節點進行疑難排解？

簡短說明

在開始疑難排解之前，請確認您的組態符合以下要求：

• 您有一台管理機器來執行叢集生命週期操作。
• 您的管理機器、控制平面和工作節點位於相同的第二層網路。
• 您的網路支援 DHCP。
  **注意：**最佳實務是將網路設定為排除控制平面和工作節點的特定 IP 位址。
• 您已為控制平面端點及其他叢集節點保留靜態 IP 位址，並將靜態 IP 位址排除在 DHCP 範圍之外。
• 您的伺服器每個節點至少有兩個 vCPU、8 GB RAM 和 25 GB 儲存空間。
• 您的彈性網路介面支援 Preboot eXecution Environment (PXE)。
• 您擁有 VMware vSphere 7 或 8 及 VMware vCenter Server。
• 您有能力部署 6 至10 台虛擬機器 (VM)。此外，您在工作叢集的主要 VM 網路中執行 DHCP 服務。
• 您的 vSphere 網路允許存取 vCenter Server，並且您已保留並排除 DHCP 所需的 IP 位址。

解決方法

節點註冊錯誤

如果您未將 AWS IAM Authenticator for Kubernetes 組態對應 (aws-auth ConfigMap) 套用到叢集，那麼您會收到以下錯誤訊息：

「Unable to register node with API server err=Unauthorized.」

**注意：**該組態對應提供 system:bootstrappers 和 system:nodes 角色型存取控制 (RBAC) 權限，以便將節點註冊至叢集。

要解決節點註冊錯誤，請將您的 AWS Identity and Access Management (IAM) 角色新增至 aws-auth ConfigMap。

未授權錯誤

當您刪除受管節點群組，且節點角色項目隨後從 aws-auth ConfigMap 刪除時，會收到「unauthorized」錯誤訊息。您可以在檢視 kubelet 日誌中對 API 伺服器的 kubelet API 請求時，辨識此錯誤。

若要解決未授權錯誤，請再次將您的 IAM 角色新增 至 aws-auth ConfigMap。

Kubelet 相依性錯誤

CA 檔案錯誤

當節點無法從叢集擷取憑證認證機構 (CA) 檔案，或執行 /etc/eks/bootstrap.sh 指令碼時，會收到以下錯誤訊息：

「Failed to construct kubelet dependencies" err="unable to load client CA file /etc/kubernetes/pki/ca.crt: open /etc/kubernetes/pki/ca.crt: no such file or directory.」

若要解決 Kubelet 相依性錯誤，請完成以下步驟：

1. 檢查您 cloud-init 日誌中 /var/log/cloud-init-output.log 流程，確認是否有以下錯誤訊息：
   「Connect timeout on endpoint URL: https://eks.us-east-1.amazonaws.com/clusters/vg-xx-uat Exited with error on line 291」

2. 執行以下 curl -vk 命令，確認您能否連線至 Amazon EKS API 端點：

   curl -vk https://eks.us-east-1.amazonaws.com/

3. 刪除 Amazon EKS 端點。

如果無法連線到端點，請採取以下措施：

• 對於私有端點，將節點放在相同的虛擬私有雲端 (VPC) 或已連線的網路中。私有端點無法公開存取。
• 對於公有端點，請設定您的安全群組、路由表及網路存取控制清單 (網路 ACL)。安全群組、路由表和網路 ACL 必須全部允許對 Amazon EKS 端點的傳出 HTTPS (TCP 443) 流量。如需更多資訊，請參閱 VPC 和子網路注意事項。
• 對於位於私有子網路的節點，請確保您有 NAT 閘道或 VPC 端點，以提供傳出網際網路存取。
• 在您的 VPC 中，將 enableDnsHostnames 和 enableDnsSupport 設定為 true。
• 確保 DHCP 選項集包含 AmazonProvidedDNS。

驗證錯誤

當 Kubernetes 無法在工作負載叢集中找到控制平面資源「kubeadmcontrolplanes.controlplane.cluster.x-k8s.io」時，您會收到以下驗證錯誤訊息：

「Validation failed: kubeadmcontrolplanes.controlplane.cluster.x-k8s.io 'eksa-sit' not found; no CAPI cluster objects present on workload cluster 'eksa-sit'...」

若要解決驗證錯誤，請完成以下步驟：

1. 存取正在執行 kubeadm 程序的控制平面節點。

2. 執行以下 journalctl 命令，以取得 kubelet 服務日誌中的疑難排解資訊：

   journalctl -u kubelet -f

3. 在日誌輸出中，識別造成驗證錯誤的叢集元件。

啟動程序權杖錯誤

由於 Amazon EKS Anywhere 叢集版本 1.0.2 的錯誤，您可能會遇到啟動程序權杖錯誤。如需更多資訊，請參閱 GitHub 網站上的 如果啟動程序叢集時間落後工作叢集過多，啟動程序權杖可能在使用前過期。

若要解決此錯誤，請參閱 GitHub 網站上的修正以啟用啟動程序密碼輪換 (若密碼本身缺失)。

缺少啟動程序權杖密碼錯誤

當您執行 eksctl anywhere upgrade cluster -f cluster.yaml 命令時，可能會收到錯誤訊息。會發生此錯誤是因為，工作流程中的錯誤導致啟動程序權杖密碼遺失。該錯誤阻擋了新節點加入您的叢集。

若要解決此錯誤，請完成以下步驟：

1. 手動刪除新佈建的機器，以重新整理啟動程序權杖。
2. 當叢集處於運作良好狀態時，請備份 Kubernetes Cluster API (CAPI) 並將 CAPI 元件移至管理叢集。如需操作說明，請參閱叢集升級失敗，啟動程序叢集上的管理元件發生問題。

內部錯誤

當 webhook 驗證服務發生連線問題時，您會收到以下內部錯誤訊息：

「Error from server (InternalError): Internal error occurred: failed calling webhook...」

若要解決內部錯誤，請完成以下步驟：

1. 執行以下 kubectl 取得 Pod 命令，以尋找您的 eks-controller-manager Pod：

   kubectl get pods -n kube-system | grep eks-controller-manager

2. 執行以下 kubectl 日誌命令，以查看該 Pod 的日誌：

   kubectl logs eksa-controller-manager-pod-name -n kube-system

   **注意：**將 eksa-controller-manager-pod-name 替換為您的 eksa-controller-manager Pod 名稱。

3. 使用日誌輸出結果中的資訊進行疑難排解。

當 Kubernetes 控制平面的主導者選舉程序逾時時，您會收到以下內部錯誤訊息：

「Failed to update lock: etcdserver: request timed out failed to renew lease eksa-system/f64ae69e.eks.amazonaws.com: timed out waiting for the condition Error setup problem running manager {'error': 'leader election lost'}...」

當主導者選舉程序無法在 etcd 中續租其資源鎖時，您也可能會收到此錯誤訊息。

此錯誤的根本原因包括網路延遲、etcd 無法使用或資源爭用問題。

若要解決此內部錯誤，請刪除 eksa-controller-manager Pod。新的替代 Pod 會啟動並進入執行中狀態。

**注意：**內部錯誤可能發生在 Amazon EKS Anywhere 叢集版本 1.21 或更舊版本。若要避免此錯誤，最佳實務是將叢集更新至最新的 Kubernetes 版本。

PLEG 錯誤

當 Pod Lifecycle Event Generator (PLEG) 發生問題時，您會收到以下錯誤訊息：

「PLEG is not healthy: pleg was last seen active.」

若要解決 PLEG 錯誤，請採取以下措施：

• 檢查並解決容器執行時期延遲或逾時問題，例如在遠端請求期間發生的效能下降、鎖死或錯誤。
• 避免主機資源上有過多執行中的 Pod，或高規格主機上執行過多 Pod。
• 對節點中的資源問題進行疑難排解。

如需更多關於 PLEG 的資訊，請參閱 Red Hat Developer 網站上的 Pod Lifecycle Event Generator: 了解 Kubernetes 中「PLEG 運作狀態不良」的問題。

NotReady,SchedulingDisabled 錯誤

當 Amazon EKS Anywhere 叢集中的某個節點處於 NotReady,SchedulingDisabled 狀態時，您會收到錯誤。這是因為執行該 vSphere VM 的實體機器已不存在。您的叢集會卡在擴展階段，且新節點無法啟動。

若要解決 NotReady,SchedulingDisabled 狀態錯誤，請完成以下步驟：

1. 移除機器的完成項。
2. 執行以下 kubectl delete node 命令以刪除待處理的 Amazon EKS 節點，並讓新節點啟動：

   kubectl delete node your_node_name

   **注意：**將 your_node_name 替換為您想刪除的節點名稱。

相關資訊

什麼是 EKS Anywhere？

容器執行時期網路尚未就緒