如何將節點狀態從 NotReady 或不明狀態變更為就緒狀態？

簡短描述

您無法在處於 NotReady 或不明狀態的節點上排程 Pod。您只能在處於就緒狀態的節點上排程 Pod。

下列解決方法可解決處於 NotReady 或不明狀態的節點。

在您的節點處於 MemoryPressure、DiskPressure 或 PIDPressure 狀態時，您必須管理資源，才能允許在節點上排程其他 Pod。

如果節點處於 NetworkUnavailable 狀態，則您必須在節點上正確設定網路。如需詳細資訊，請參閱 Kubernetes 網站上的節點狀態。

**注意：**如需有關如何管理 Pod 移出和資源限制的資訊，請參閱 Kubernetes 網站上的節點壓力移出。

解決方法

檢查 aws-node 和 kube-proxy Pod，以了解節點為何處於 NotReady 狀態

無法在處於 NotReady 狀態的節點上排程 Pod。

為了改善安全狀態，受管節點群組可能會從節點角色的 Amazon Resource Name (ARN) 移除容器網路介面 (CNI) 政策。這個遺失的 CNI 政策會導致節點變更為 NotReady 狀態。若要解決此問題，請按照指導方針設定 aws-node DaemonSet 的服務帳戶 IAM 角色 (IRSA)。

1. 若要檢查 aws-node 和 kube-proxy Pod 的狀態，請執行下列命令：

   $ kubectl get pods -n kube-system -o wide

   輸出類似於下列內容：

   $ kubectl get pods -n kube-system -o wideNAME                             READY   STATUS    RESTARTS   AGE        IP              NODE
   aws-node-qvqr2                    1/1     Running   0          4h31m      192.168.54.115  ip-192-168-54-115.ec2.internal
   kube-proxy-292b4                  1/1     Running   0          4h31m      192.168.54.115  ip-192-168-54-115.ec2.internal

2. 檢閱輸出。如果您的節點狀態正常，則您的 aws-node 和 kube-proxy Pod 處於執行中狀態。
   如果未列出任何 aws-node 或 kube-proxy Pod，請跳至步驟 3。aws-node 和 kube-proxy Pod 由 DaemonSet 管理。這表示叢集中的每個節點都必須具有一個 aws-node 和一個在其上執行的 kube-proxy Pod。如需詳細資訊，請參閱 Kubernetes 網站上的 DaemonSet。

   如果其中一個 Pod 處於執行中以外的狀態，請執行下列命令：

   $ kubectl describe pod yourPodName -n kube-system

   若要從 aws-node 和 kube-proxy Pod 日誌取得其他資訊，請執行下列命令：

   $ kubectl logs yourPodName -n kube-system

   來自描述輸出的日誌和事件可顯示 Pod 未處於執行中狀態的原因。若要使節點變更為就緒狀態，aws-node 和 kube-Proxy Pod 都必須在該節點上處於執行中狀態。

3. 如果 aws-node 和 kube-proxy Pod 未顯示在命令輸出中，請執行下列命令：

   $ kubectl describe daemonset aws-node -n kube-system
   $ kubectl describe daemonset kube-proxy -n kube-system

4. 在輸出中搜尋 Pod 無法啟動的原因：

   注意： 您也可以搜尋 Amazon EKS 控制平面日誌，以了解無法排程 Pod 的原因。

5. 根據 AWS 指導方針，確認 aws-node 和 kube-proxy 的版本與叢集版本相容。例如，請執行下列命令來檢查 Pod 版本：

   $ kubectl describe daemonset aws-node --namespace kube-system | grep Image | cut -d "/" -f 2$ kubectl get daemonset kube-proxy --namespace kube-system -o=jsonpath='{$.spec.template.spec.containers[:1].image}'

   **注意：**若要更新 aws-node 版本，請參閱使用 Kubernetes Amazon EKS 附加元件的 Amazon VPC CNI 外掛程式。若要更新 kube-proxy 版本，請依照更新 Amazon EKS 叢集的 Kubernetes 版本中的步驟 4 進行操作。

在某些情況下，節點可能處於不明狀態。這表示節點上的 kubelet 無法將節點的正確狀態傳達給控制平面。

若要對處於不明狀態的節點進行疑難排解，請完成下列各節的步驟。

檢查節點與控制平面之間的網絡組態

1. 確認子網路上沒有會封鎖 Amazon EKS 控制平面與工作節點間之流量的網路存取控制清單 (ACL) 規則。

2. 確認控制平面和節點的安全群組符合最低傳入和傳出需求。

3. (選用) 如果您的節點設定為使用代理，請確認代理允許流量傳輸至 API 伺服器端點。

4. 若要驗證節點是否具有 API 伺服器的存取權，請從工作節點內部執行下列 netcat 命令：

   $ nc -vz 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443Connection to 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 443 port [tcp/https] succeeded!

   **注意：**將 9FCF4EA77D81408ED82517B9B7E60D52.yl4.eu-north-1.eks.amazonaws.com 取代為您的 API 伺服器端點。

5. 檢查路由表是否設定為允許與 API 伺服器端點進行通訊。這可以透過網際網路閘道或 NAT 閘道完成。如果叢集使用 PrivateOnly 聯網，請確認已正確設定 VPC 端點。

檢查 kubelet 狀態

1. 使用 SSH 連線至受影響的工作節點。

2. 若要檢查 kubelet 日誌，請執行下列命令：

   $ journalctl -u kubelet > kubelet.log

   **注意：**kubelet.log 檔案包含 kubelet 操作的相關資訊，可協助您找出節點狀態問題的根本原因。

3. 如果日誌未提供問題來源的相關資訊，請執行下列命令。此命令會檢查工作節點上的 kubelet 的狀態：

   $ sudo systemctl status kubelet  kubelet.service - Kubernetes Kubelet
      Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
     Drop-In: /etc/systemd/system/kubelet.service.d
              └─10-eksclt.al2.conf
      Active: inactive (dead) since Wed 2023-12-04 08:57:33 UTC; 40s ago

   如果 kubelet 未處於執行中狀態，請執行下列命令以重新啟動 kubelet：

   $ sudo systemctl restart kubelet

確認 Amazon EC2 API 端點是否可連線

1. 使用 SSH 連線至其中一個工作節點。
2. 若要檢查您 AWS 區域的 Amazon Elastic Compute Cloud (Amazon EC2) API 端點是否可連線，請執行下列命令：

   $ nc -vz ec2.<region>.amazonaws.com 443Connection to ec2.us-east-1.amazonaws.com 443 port [tcp/https] succeeded!

   **注意：**將 us-east-1 取代為您的工作節點所在的 AWS 區域。

檢查工作節點執行個體設定檔和 ConfigMap

1. 確認工作節點執行個體設定檔具有建議的政策。
2. 確認工作節點執行個體角色存在於 aws-auth ConfigMap 中。若要檢查 ConfigMap，請執行下列命令：

   $ kubectl get cm aws-auth -n kube-system -o yaml

   ConfigMap 必須具有工作節點執行個體 AWS Identity and Access Management (IAM) 角色的項目。例如：

   apiVersion: v1kind: ConfigMap
   metadata:
     name: aws-auth
     namespace: kube-system
   data:
     mapRoles: |
       - rolearn: <ARN of instance role (not instance profile)>
         username: system:node:{{EC2PrivateDNSName}}
         groups:
           - system:bootstrappers
           - system:nodes