針對工作者節點進行除錯

虛擬私有雲 經典基礎設施

檢閱針對工作者節點進行除錯的選項，並尋找故障的主要原因。

檢查工作者節點通知及維護更新

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

  1. 標準叢集 檢查性能儀表板 是否有任何 IBM Cloud 緊急維護通知可能會影響您帳戶中的標準工作者節點。 視維護通知的本質而定，您可能需要重新開機或重新載入工作者節點。
  2. 請檢查 IBM Cloud 狀態儀表板，以找出可能影響工作者節點或叢集的任何已知問題。 如果下列任何元件顯示錯誤狀態，則該元件可能是工作者節點中斷的原因。
    • 對於所有叢集，請檢查 Kubernetes Service 及 Container Registry 元件。
    • 對於 Red Hat OpenShift 集群，請檢查 Red Hat OpenShift on IBM Cloud 元件。
    • 若為 VPC 叢集，請檢查 Virtual Private Cloud、Virtual Private Endpoint 及 Virtual Server for VPC 元件。
    • 若為標準叢集，請檢查 標準基礎架構供應 及 Virtual Servers 元件。

解決工作者節點問題的快速步驟

如果工作者節點未如預期般運作，您可以遵循下列步驟來更新叢集及指令行工具，或執行診斷測試。 如果問題持續存在，請參閱 對工作者節點進行除錯，以取得其他步驟。

  1. 將叢集和工作者節點更新至最新版本。
  2. 更新指令行工具。

對工作者節點進行除錯

步驟 1: 取得工作者節點狀態

如果叢集處於 Critical、Delete failed 或 Warning 狀況，或停留在 Pending 狀況很長一段時間，請檢閱工作者節點的狀況。

ibmcloud oc worker ls --cluster CLUSTER_NAME_OR_ID

步驟 2: 檢閱工作者節點狀態

請檢閱 CLI 輸出中每個工作者節點的 State 及 Status 欄位。

如需相關資訊，請參閱 工作者節點狀態。

步驟 3：取得每個工作節點的詳細資訊

取得工作節點的詳細資訊。 如果詳細資料包含錯誤訊息，請檢閱工作者節點的一般錯誤訊息清單，以瞭解如何解決問題。

ibmcloud oc worker get --cluster CLUSTER_NAME_OR_ID --worker WORKER_NODE_ID

步驟 4: 檢閱工作者節點的基礎架構提供者

請檢閱基礎架構環境，以檢查可能導致工作者節點問題的其他原因。

  1. 請洽詢您的網路團隊，以確保最近沒有任何維護 (例如防火牆或子網路更新項目) 可能會影響工作者節點連線。
  2. 檢閱 IBM Cloud for Red Hat OpenShift on IBM Cloud 及基礎架構提供者，例如 Virtual Servers for Classic、VPC 相關元件或 Satellite。
  3. 如果您有權存取基礎架構 (例如標準 Virtual Servers)，請檢閱工作者節點對應機器的詳細資料。

步驟 5：收集工作節點的日誌和其他詳細資訊

執行 must-gather 指令

oc adm must-gather CLI 指令會從您的群集收集資訊，用於除錯問題。 必須收集的工具可收集資源定義、服務日誌等資料。 請注意，為了減少檔案大小，稽核記錄不會作為預設資訊集的一部分來收集。

當您執行 oc adm must-gather 時，會在群集上的新專案中建立一個具有隨機名稱的新 pod。 資料會在該 pod 上收集，並儲存在以 must-gather.local 開頭的新目錄中。

請檢視以下範例指令。

oc adm must-gather

範例指令若要收集與一個或多個特定特徵相關的資料，請使用 --image 參數搭配特定影像。

oc adm must-gather \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.5

收集稽核記錄的範例指令。

oc adm must-gather -- /usr/bin/gather_audit_logs

在特定命名空間執行 must-gather 的範例指令。

oc adm must-gather --run-namespace NAMESPACE \
--image=registry.redhat.io/container-native-virtualization/cnv-must-gather-rhel9:v4.17.5

收集指定時間內的日誌的範例指令。

oc adm must-gather --since=24h

oc adm must-gather --since-time=$(date -d '-24 hours' +%Y-%m-%dT%T.%9N%:z )

收集網路日誌的範例指令。

oc adm must-gather -- gather_network_logs

如需更多範例和參數，請執行下列指令

oc adm must-gather -h

從必須收集目錄建立壓縮檔案的範例指令。

tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/

將壓縮檔附加到您的支援個案。

收集 SOS 報告

sosreport 是一個從 (RHEL) 和 (RHCOS) 系統收集組態詳細資訊、系統資訊和診斷資料的工具。Red Hat Enterprise Linux Red Hat Enterprise Linux CoreOS 它提供了收集節點相關診斷資訊的標準化方式，可提供給支援人員進行問題診斷。

在某些支援互動中，支援人員可能會要求您收集特定 OpenShift Container Platform 節點的 sosreport 存檔。 例如，可能需要檢閱 oc adm must-gather 輸出中未包含的系統日誌或其他特定節點資料。

收集 sosreport 的方法會因工作節點的作業系統而異。 RHCOS 節點使用 toolbox 指令。 RHEL 8 和 RHEL 9 節點不支援 toolbox``；請改用 Red Hat sosreport 指令檔。

為 OpenShift Container Platform 叢集節點產生 sosreport 的建議方式是透過 debug pod。

存取您的 Red Hat OpenShift 集群。

  1. 請列出您的工作節點，以便識別目標節點及其作業系統。

    oc get nodes -o wide

    請記下您要從其收集 sosreport 的工作節點名稱。 「OS-IMAGE」欄位用以標示該節點是執行 RHCOS 還是 RHEL。

  2. 在目標節點上啟動除錯會話。

    oc debug node/node_name

    若要在沾有 NoExecute 效應的目標節點上進入除錯會話，請在臨時命名空間中加入容忍度，並在臨時命名空間中啟動除錯 pod。

    oc new-project temp oc patch namespace temp --type=merge -p '{"metadata": {"annotations": { "scheduler.alpha.kubernetes.io/defaultTolerations": "[{\"operator\": \"Exists\"}]"}}}'

    oc debug node/my-cluster-node

  3. 設定 /host 為 debug shell 內的根目錄。 除錯 Pod 會將主機的根檔案系統掛載至 Pod 內的 /host 目錄中。 將根目錄變更為 /host 後，即可執行主機可執行路徑中包含的二進位檔。

    chroot /host

    OpenShift Container Platform 運行紅帽企業開源系統（ Red Hat Enterprise LinuxCoreOS，簡稱 RHCOS）的叢集節點具有不可變性，需透過操作員（Operators）來執行叢集變更。 不建議使用 SSH 存取群集節點。 然而，若目標節點上無法使用 OpenShift Container Platform API，或 kubelet 運作異常，則可能影響 oc 操作的執行。 在這種情況下，可以改用 ssh core@NODE.CLUSTER_NAME.BASE_DOMAIN 來存取節點。

  4. 請根據工作節點的作業系統，採用相應的方法來擷取 sosreport 。

    • RHCOS 節點：請使用 toolbox 指令。

      1. 啟動工具箱容器，其中包含執行 sosreport 所需的二進位檔和外掛程式。 toolbox 指令僅在 RHCOS 節點上受支援。

        toolbox

        如果現有的 toolbox pod 已經在執行，toolbox 指令會輸出 'toolbox-' already exists. Trying to start…. 移除正在執行的工具箱容器，podman rm toolbox-，並啟動一個新的工具箱容器。

      2. 執行 sos report 指令，並依照提示收集故障排除資料。

        sos report -k crio.all=on -k crio.logs=on -k podman.all=on -k podman.logs=on

        在報告中包含節點的 OVN- Kubernetes 網路組態資訊的範例指令。

        sos report --all-logs

        sosreport 的輸出內容會提供存檔的位置與校驗和。 以下範例輸出引用支援案例 ID 01234567。 該檔案路徑位於 chroot 環境之外，這是因為工具箱容器將主機的根目錄掛載至 /host。

        Your sosreport has been generated and saved in:
/host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz
The checksum is: 382ffc167510fd71b4f12a4f40b97a4e

    • RHEL 8 和 RHEL 9 節點 ：RHEL 節點不支援 toolbox 指令。 請改為使用 Red Hat 中的 sosreport 彙整腳本。

      1. 請依照 Red Hat 知識庫文章中的指示，下載並執行 Red Hat 中的 sosreport 指令檔。

      2. 請依照腳本中的提示，收集疑難排解資料。 請根據腳本的輸出結果，記下生成的壓縮檔所在位置。

  5. 輸出 sosreport 到檔案。

    除錯容器將主機的根目錄掛載至 /host。 在指定要串接的目標檔案時，請以除錯容器的根目錄為起點，包含 /host 在內，來指定絕對路徑。

    oc debug node/my-cluster-node -- bash -c 'cat /host/var/tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz' > /tmp/sosreport-my-cluster-node-01234567-2020-05-28-eyjknxt.tar.xz

    OpenShift Container Platform 運行紅帽企業開源系統（ Red Hat Enterprise LinuxCoreOS，簡稱 RHCOS）的叢集節點具有不可變性，需透過操作員（Operators）來執行叢集變更。 不建議使用 scp 從叢集節點傳輸 sosreport 存檔。 然而，若目標節點上無法使用 OpenShift Container Platform API，或 kubelet 運作異常 oc，作業流程可能受到影響。 在這種情況下，可以透過執行 scp core@<node>.<cluster_name>.<base_domain>:<file_path> <local_path> 從節點複製 sosreport 存檔。

  6. 將檔案上傳至您的支援個案。