對處於 Critical 或 NotReady 狀態的工作者節點進行疑難排解

當叢集工作者節點停止與叢集主節點通訊時，它們會進入 Critical 或 NotReady 狀態。 當此情況發生時，您的工作節點在 IBM Cloud 使用者介面 Critical 中會標記為，或當您執行 ibmcloud oc worker 指令時；同時在 Red Hat OpenShift 儀表板中會標 NotReady 記為，以及當您執行 oc get nodes 時。 工作者節點與叢集主節點之間的通訊停止有數個原因。 請遵循下列步驟，對處於這些狀態的工作者節點進行疑難排解。

請 IBM Cloud 檢查健康與狀態儀表板，查看是否有任何可能與您的工作節點相關的通知或維護更新。 這些通知或更新項目可能有助於判斷工作者節點失敗的原因。

檢查工作者節點失敗的一般原因

工作者節點與叢集主節點之間的通訊停止有數個原因。 請檢查下列一般問題是否導致毀壞。

工作者已刪除、重新載入、更新、取代或重新開機
工作者節點在刪除、重新載入、更新或取代時，可能會暫時顯示 Critical 或 NotReady 狀態。 如果已在工作者節點上起始任何這些動作 (不論是手動或作為自動化設定的一部分，例如叢集 Autoscaler)，請等待這些動作完成。 然後，再次檢查工作者節點的狀態。 如果任何工作者仍處於 Critical 或 NotReady 狀態，請 重新載入 或 取代 受影響的工作者。
如果工作者節點已重新載入或取代且最初正常運作，但在一段時間之後又回到 Critical 或 NotReady 狀態，則可能是工作者節點上的某個工作量或元件導致問題。 請參閱 對工作者節點除錯，以隔離問題工作量。

如果工作者節點重新開機而未先被封鎖及排除，則工作者節點可能最終會處於 Critical 或 NotReady 狀態。 如果是這種情況，等待重新開機完成並不會解決問題。 重新載入 或 取代 受影響的工作者。 如果問題持續存在，請繼續進行疑難排解步驟。

工作者節點無意中關閉電源
標準叢集 在IBM Cloud 主控台資源清單中，標準基礎架構上的工作者節點分類為 運算資源或虛擬機器。 有時使用者可能不知道這些資源作為叢集工作者節點運作，並且可能無意中關閉工作者節點的電源。 已關閉電源的工作者節點可能會顯示在 Critical 或 NotReady 狀態。 請確定受影響的工作者節點未關閉電源。

疑難排解步驟

在解決 一般原因 之後，如果工作者節點仍處於 Critical 或 NotReady 狀態，請繼續執行下列疑難排解步驟。

如果您先前重新載入或取代的工作者節點在執行 ibmcloud ks workers 時處於 deploy_failed 或 provision_failed 狀態，請遵循 叢集裡的所有工作者節點都受到影響 區段中的步驟，即使並非所有節點都受到影響。 如果指出不同的狀態，請參閱 工作者節點狀態，以取得對新工作者節點進行疑難排解的步驟。 請勿取代或重新載入任何其他工作者節點。

如果一個或部分工作者節點受到影響

如果叢集裡只有部分 (而非所有) 工作者節點處於 Critical 或 NotReady 狀態，請遵循下列步驟來判斷毀壞的原因並解決問題。 如果受影響的工作者節點都來自相同的區域、子網路或 VLAN，請繼續進行下一個區段。

  1. 取得特定節點的詳細資料。

    oc describe node <node-IP-address>

  2. 在輸出中，檢查 條件 區段，以判斷節點是否遇到任何記憶體、磁碟或 PID 問題。 此資訊可能指出節點在該類型資源上不足。 發生這種情況可能是由於以下其中一個原因：

    • 由於 Pod 缺少適當的要求及限制，導致記憶體或 CPU 耗盡。
    • 工作者磁碟已滿，有時是因為節點本身的大型 Pod 日誌或 Pod 輸出。
    • 在一段時間內累積的緩慢記憶體洩漏，可能會導致超過一個月未更新的工作者發生問題。
    • 影響 Linux 核心的錯誤及當機。

  3. 如果您能夠從 條件 區段中的資訊判定問題的原因，請遵循 對工作者節點進行除錯 中的步驟，以隔離問題工作量。

  4. 如果先前的步驟無法解決問題，請 重新載入 或 取代 受影響的工作者 (一次一個)。

如果單一區域、子網路或 VLAN 中的所有工作者節點都受到影響

如果一個區域、子網路或 VLAN 中的所有工作程序節點均處於 Critical 或 NotReady 狀態，但叢集中的所有其他工作程序節點均正常運行，則網路元件可能有問題。 請遵循 如果叢集裡所有工作者節點都受到影響 中的步驟，特別是有關可能影響區域、子網路或 VLAN 的任何網路元件的步驟，例如防火牆或閘道規則、ACL 或自訂路徑，或 Calico 及 Kubernetes 網路原則。

如果您已檢查網路元件，但仍然無法解決問題，請 收集工作者節點資料 並開立支援問題單。

如果叢集裡的所有工作者節點都受到影響

如果叢集中的所有工作者節點同時顯示 Critical 或 NotReady，則叢集 apiserver 或工作者節點與 apiserver 之間的網路路徑可能有問題。 請遵循下列疑難排解步驟來判斷原因並解決問題。

部分步驟特定於特殊化區域，例如網路或自動化。 在完成這些步驟之前，請諮詢組織中的相關管理者或團隊。

  1. 檢查叢集、環境或帳戶是否有任何可能影響工作者節點的最新變更。 若是如此，請回復變更，然後檢查工作者節點狀態，以判斷變更是否導致問題。

    • 若為標準叢集，請檢查任何防火牆或閘道，例如 Virtual Router Appliance、Vyatta 或 Juniper，以管理叢集工作者節點的資料流量。 尋找可能從叢集工作者節點捨棄或重新導向資料流量的變更或問題。
    • 若為 VPC 叢集，請檢查是否對 VPC 或工作者節點上的預設安全群組及 ACL 進行了任何變更。 如果已進行任何修改，請確保您容許從叢集工作者節點到叢集主節點、容器登錄及其他重要服務的所有必要資料流量。 如需詳細資訊，請參閱 瞭解安全預設群集 VPC 網路，以及 建立和管理 VPC 安全群組 和 使用 ACL 控制流量。
    • 若為 VPC 叢集，請檢查任何自訂遞送規則是否有變更可能封鎖來自叢集 apiserver 的資料流量。
    • 檢查套用至叢集的任何 Calico 或 Kubernetes 網路原則，並確保它們不會封鎖從工作者節點到叢集 apiservice、容器登錄或其他重要服務的資料流量。

  2. 檢查叢集裡的應用程式、安全或監視元件是否因要求而使叢集 apiserver 超載，這可能導致工作者節點中斷。

  3. 如果您最近將任何元件新增至叢集，請移除它們。 如果您對叢集中的任何現有元件進行變更，請回復變更。 然後，檢查工作者節點的狀態，以查看新元件或變更是否導致問題。

  4. 檢查任何叢集 Webhook 上的變更，這可能會中斷 apiserver 要求或封鎖工作者節點連接 apiserver 的能力。 檢查拒絕請求的 Webhook。 執行以下命令以取得拒絕請求的 Webhook 清單。

    kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds

  5. 查看具有 rejected="true" 狀態的 Webhook 的輸出。

  6. 移除並重新產生任何自訂 Docker 取回密碼，如果配置錯誤，則可防止工作者節點從 Docker 登錄取回映像檔。

    1. 執行 oc delete secret -n openshift pull-secret 及 oc delete secret -n openshift-config pull-secret 指令，以刪除自訂 Docker 取回密碼。
        oc delete secret -n openshift pull-secret
    ```
    ```sh {: pre}
    oc delete secret -n openshift-config pull-secret
    ```
1. 等待叢集重新產生自訂 Docker 取回密碼。 任何配置錯誤的元件都不再存在於重新產生的取回密鑰中。

  7. 請檢查您的工作節點狀態。 如果它們處於 Normal 狀態，請重新新增任何已刪除的元件，並逐一重建任何已回復的變更，直到您可以判定哪個配置或元件導致工作者節點毀壞為止。

  8. 如果問題仍未解決，請遵循 收集工作者節點資料 的步驟，並開立支援問題單。

如果工作者節點在正常與嚴重狀態之間切換

如果工作者節點在 Normal 與 Critical 或 NotReady 狀態之間切換，請檢查下列元件是否有任何問題或最新變更可能干擾工作者節點。

  1. 若為標準叢集，請檢查防火牆或閘道。 如果有頻寬限制或任何類型的故障，請解決問題。 然後，重新檢查工作者節點。

  2. 檢查叢集裡的應用程式、安全或監視元件是否因要求而使叢集 apiserver 超載，這可能導致工作者節點中斷。

  3. 如果您最近將任何元件新增至叢集，請移除它們。 如果您對叢集中的任何現有元件進行變更，請回復變更。 然後，檢查工作者節點的狀態，以查看新元件或變更是否導致問題。

  4. 檢查任何叢集 Webhook 上的變更，這可能會中斷 apiserver 要求或封鎖工作者節點連接 apiserver 的能力。 檢查拒絕請求的 Webhook。 執行以下命令以取得拒絕請求的 Webhook 清單。

    kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds

  5. 查看具有 rejected="true" 狀態的 Webhook 的輸出。

  6. 如果問題仍未解決，請遵循 收集工作者節點資料 的步驟，並開立支援問題單。

收集支援案例的資料

如果您無法解決疑難排解步驟的問題，請收集工作者節點的相關資訊。 然後，開立支援問題單，並包含您所收集的工作者節點資訊。

在開立支援問題單之前，請檢閱資訊，並遵循 對工作者節點進行除錯、工作者節點狀態 及 對 Critical 或 NotReady 狀態中的工作者節點進行疑難排解 中的任何疑難排解步驟。

如果叢集中或一個區域、子網路或 VLAN 中的所有工作程序節點都受到影響，您可以開立初始支援票證而無需收集資料。 不過，稍後可能會要求您收集相關資料。 如果只有一個或部分工作者節點受到影響，您必須收集相關資料以包含在支援問題單中。

開始之前

在收集資料之前，請先檢查工作者節點及叢集的狀況。

  1. 請檢查節點的 CPU 和記憶體層次。 如果任何節點的 CPU 或記憶體用量超過 80%，請考慮佈建更多節點或減少工作量。

    oc top node

    輸出範例

    NAME            CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
10.001.1.01     640m         16%    6194Mi          47%       
10.002.2.02     2686m        68%    4024Mi          30%       
10.003.3.03     2088m        53%    10735Mi         81%

  2. 檢查任何叢集 Webhook 上的變更，這可能會中斷 apiserver 要求或封鎖工作者節點連接 apiserver 的能力。 檢查拒絕請求的 Webhook。 執行以下命令以取得拒絕請求的 Webhook 清單。

    kubectl get --raw /metrics | grep apiserver_admission_webhook_admission_duration_seconds

  3. 查看具有 rejected="true" 狀態的 Webhook 的輸出。

正在收集資料

遵循步驟來收集相關工作者節點資料。

  1. 取得每一個節點的詳細資料。 儲存輸出詳細資料以包含在支援問題單中。

    oc describe node <node-ip-address>

  2. 取得 Webhook 詳細資料，以顯示未新增任何轉換或驗證叢集裡剩餘的 Webhook。 儲存指令輸出以包含在支援問題單中。 請注意，下列轉換 Webhook 可能仍然存在，且不需要刪除: alertmanagerconfigs.openshift、managed-storage-validation-webhooks、multus.openshift.io、performance-addon-operator、prometheusrules.openshift.io、snapshot.storage.k8s.io。

    kubectl get mutatingwebhookconfigurations

    kubectl get validatingwebhookconfigurations

  3. 標準叢集: 存取其中一個受影響工作者的 KVM 主控台。 然後，收集相關日誌及輸出。

    1. 遵循步驟以存取 KVM 主控台。
    2. 收集並儲存下列日誌。 請檢閱日誌，以找出工作者節點毀壞的可能原因，例如缺少記憶體或磁碟空間、磁碟進入唯讀模式，以及其他問題。
      • /var/log/boot.log
      • /var/log/calico/cni/cni.log
      • /var/log/crio.log
      • /var/log/cron
      • /var/log/messages
      • /var/log/secure
    3. 執行下列指令並儲存輸出，以連接至支援問題單。
      • ps -aux # 傾出執行中處理程序
      • df -H # 傾出磁碟使用情形資訊
      • vmstat # 傾出記憶體用量資訊
      • lshw # 傾出硬體資訊
      • last -Fxn2 shutdown reboot # 判定前次重新啟動是否正常
      • mount | grep -i "(ro" # 以排除磁碟唯讀問題。 附註: tmpfs is ro 是正常的
      • touch /this # 以排除磁碟唯讀問題

  4. VPC 群集：使用 kubectl top 命令收集工作節點的資源使用情況，如下例所示。

    kubectl top nodes

    範例輸出以毫微(m)為單位顯示 CPU 使用量，以 MB (Mi) 為單位顯示記憶體使用量。

    NAME          CPU(cores)    CPU%   MEMORY(bytes)   MEMORY%
k8s-node-1      250m              12%    800Mi                         40%
k8s-node-2      180m               9%     600Mi                         30%
k8s-node-3      250m               22%    700Mi                        50%
    名稱
    節點的名稱。
    CPU（核心數）
    目前的 CPU 使用量，單位為毫核 (m)。1000m 等於 1 個核心。
    CPU%
    節點上使用的 CPU 總容量百分比。
    記憶體（位元組數）
    目前的記憶體使用量，單位為 MiB (兆位元組) 或 GiB (千位元組)。
    記憶體
    已使用的總記憶體容量百分比。

    CPU% 或 MEMORY% 高的節點 (超過 80%) 可能已超載，可能需要額外的資源。 CPU% 或 MEMORY% 偏低 (低於 20%) 的節點可能未被充分利用，顯示有重新分配工作負載的空間。 如果節點的 CPU 或記憶體使用率達到 100%，新的工作負載可能無法排程或效能下降。

  5. 使用下列指令收集 Pod 的資源使用量。

    kubectl top pods --all-namespaces

    輸出範例

    NAMESPACE       NAME                                  CPU(cores)   MEMORY(bytes)
default            my-app-564bc58dad-hk5gn       120m            256Mi
default             my-db-789d9c6c4f-tn7mv         300m            512Mi
    名稱
    Pod 的名稱。
    CPU（核心數）
    pod 在其所有容器中使用的 CPU 總數。
    記憶體（位元組數）
    pod 在所有容器中使用的總記憶體。

    如果 pod 的 CPU 使用率很高，它可能正經歷 CPU 節流，這會影響效能。 若某個 Pod 的記憶體使用量接近其上限，則可能面臨記憶體不足（OOM）錯誤的風險，此時 Kubernetes 系統會終止部分程序以釋放記憶體。 資源使用率低的 pod 可能會有過度分配的請求，導致資源浪費。

  6. 透過執行 top pod 指令檢查容器層級指標。

    kubectl top pod pod-a --containers -n appns
```sh
{: pre}
Example output
```sh
NAME           CONTAINER      CPU(cores)   MEMORY(bytes)
pod-a            app-container        100m         300Mi
pod-a            db-container           50m          200Mi
```sh
{: screen}

  7. kubectl top 指令只會顯示實際使用量，而不會顯示要求的或有限的資源。 若要比較和分析 top 指令的輸出，請使用下列指令檢查 pod 規格。

    kubectl describe pod <pod-name> -n <namespace>

    輸出範例

    Containers:
 app-container:
   Requests:
  cpu: 250m
  memory: 512Mi
  Limits:
  cpu: 500m
  memory: 1Gi

    如果 CPU 或記憶體使用量超過要求，可能表示供應不足，導致效能問題。 如果使用量接近限制，容器可能會在資源受限時被節流或終止。 如果使用量遠低於請求，pod 可能已被過度配置，造成資源浪費。

  8. 找出消耗 CPU 最多的 pod。

    kubectl top pod --all-namespaces | sort -k3 -nr | head -10

  9. 識別高記憶體消耗的 pod。

    kubectl top pod --all-namespaces | sort -k4 -nr | head -10

  10. 監控系統 daemon 的資源使用情況。 DaemonSets, 如 或監控代理，可能會消耗意想不到的資源。kube-proxy

    kubectl top pod -n kube-system
```sh
{: pre}

  11. 如果某些系統 pod 消耗過多 CPU 或記憶體，可能需要調整請求和限制。 若要持續追蹤資源變更，請使用 watch 指令。

    watch -n 5 kubectl top pod --all-namespaces
```sh
{: pre}
This command updates the output every 5 seconds, helping to spot spikes or anomalies in resource usage.

  12. 檢查 OOMKilled 活動。 當 Kubernetes 報告 OOMKilled 時，pod 超過記憶體上限而被終止。 pod 的狀態變更為 crashloopbackoff。

    kubectl get events --field-selector involvedObject.name=your-pod-name -n your-namespace

  13. 在日誌中尋找 OOM 訊息。

    kubectl logs your-pod-name -n your-namespace | grep -i "out of memory"

  14. 檢查 OOM 終止容器的最後狀態。

    kubectl describe pod your-pod-name -n your-namespace | grep -A 10 "Last State"

收集工作站日誌

按照步驟 存取 Worker 並收集 Worker 節點記錄。

  1. 收集並儲存下列記錄檔。 請檢閱日誌，以找出工作者節點毀壞的可能原因，例如缺少記憶體或磁碟空間、磁碟進入唯讀模式，以及其他問題。

    • /var/log/containerd.log
    • /var/log/kern.log
    • /var/log/kube-proxy.log
    • /var/log/syslog
    • /var/log/kubelet.log

  2. 執行下列指令並儲存輸出，以連接至支援問題單。

    取得容器統計資料 (需要 SSH 存取節點)。

    crictl stats

    取得特定容器的詳細統計資料。

    crictl stats --id <container-id> --output json

    執行指令以轉儲執行中的進程。

    ps -aux

    動態、即時檢視執行中的進程和核心管理的任務，以及資源使用率，包括 CPU 和記憶體使用率。

    top

    取得目前的系統狀態。

    htop

    取得包含歷史資料的全面監控報告。

    atop

    取得系統程序的即時資訊。

    btop

    取得網路連線詳細資訊。

    netstat

    取得磁碟使用資訊。

    df -H

    執行 vmstat 以取得有關程序、記憶體、分頁、區塊 IO、陷阱和 CPU 活動的報告。 此指令以 2 秒的間隔取得資訊，共 5 次。

    vmstat 2 5

    執行 iostat 以收集磁碟使用統計資料，涵蓋吞吐量、使用率、佇列長度、交易率等。

    iostat -x 1 5

    收集硬體資訊。

    lshw

    使用以下指令找出上次重新啟動是否優美。

    last -Fxn2 shutdown reboot

    若要排除磁碟問題，請驗證磁碟是否可寫。

    mount | grep -i "(ro"
touch /this

  3. 如果問題仍然存在，請 開啟支援票單，並附上之前步驟中儲存的所有輸出。