本頁面的部分或所有資訊可能不適用於 S3NS 的 Cloud de Confiance。詳情請參閱「與 Google Cloud 的差異」。

Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

排解 IBM Spectrum Symphony 連接器問題

本文說明如何解決 IBM Spectrum Symphony 整合 Cloud de Confiance by S3NS的常見問題。具體來說，本文提供 IBM Spectrum Symphony 主機工廠服務、Compute Engine 和 GKE 供應商的連接器，以及 Kubernetes 適用的 Symphony 運算子的疑難排解指引。

Symphony 主機工廠服務問題

這些問題與中央 Symphony 主機工廠服務有關。您可以在 Linux 的下列位置找到這項服務的主要記錄檔：

$EGO_TOP/hostfactory/log/hostfactory.hostname.log

您會在載入主機工廠環境變數時設定 $EGO_TOP 環境變數。在 IBM Spectrum Symphony 中，$EGO_TOP 指向 Enterprise Grid Orchestrator (EGO) 的安裝根目錄，這是叢集的核心資源管理工具。Linux 上的 $EGO_TOP 預設安裝路徑通常為 /opt/ibm/spectrumcomputing。

叢集不會為待處理的工作負載新增 VM

如果 Symphony 佇列包含工作，但主機出廠設定無法佈建新的虛擬機器 (VM) 來管理負載，就會發生這個問題。主機工廠記錄檔不含 SCALE-OUT 訊息。

如果 Symphony 請求者未正確設定或啟用，通常會發生這個問題。如要解決這個問題，請檢查已設定的請求者狀態，確認請求者已啟用，且有待處理的工作負載。

找出要求者設定檔。這個檔案通常位於：
```
$HF_TOP/conf/requestors/hostRequestors.json
```
使用 source 指令時，環境中會定義 $HF_TOP 環境變數。這個值是 IBM Spectrum Symphony 主機工廠服務的頂層安裝目錄路徑。
開啟 hostRequestors.json 檔案，並找出 symAinst 項目。在該區段中，確認 enabled 參數設為 1 值，且供應商清單包含已設定的 Cloud de Confiance by S3NS 供應商執行個體名稱。
- 如果是 Compute Engine 設定，供應商清單必須顯示您在「啟用供應商執行個體」中建立的 Compute Engine 供應商名稱，也就是 Compute Engine 供應商安裝程序。
- 如果是 GKE 設定，供應商清單必須顯示您在啟用供應商例項時建立的 GKE 供應商名稱。
確認已啟用 symAinst 要求者後，請檢查是否有待處理的工作負載需要擴充。

查看所有消費者及其工作負載狀態的清單：
```
egosh consumer list
```
在輸出內容中，找出與工作負載相關聯的消費者，並確認工作負載處於待處理狀態。如果要求者已啟用，且工作負載處於待處理狀態，但主機 Factory 服務未啟動擴充要求，請檢查 HostFactory 服務記錄是否有錯誤。

主機工廠服務未啟動

如果主機原廠服務未執行，請按照下列步驟解決問題：

檢查 HostFactory 服務的狀態：
```
egosh service list
```
在輸出內容中，找出 HostFactory 服務，並確認 STATE 欄位顯示的狀態為 STARTED。

如果 HostFactory 服務未啟動，請重新啟動：

egosh service stop HostFactory
egosh service start HostFactory

其他錯誤和記錄

如果主機出廠服務發生其他錯誤，請提高記錄詳細程度，取得更詳盡的記錄。若要這樣做，請完成下列步驟：

開啟 hostfactoryconf.json 檔案進行編輯。這個檔案通常位於：
```
$EGO_TOP/hostfactory/conf/
```
如要進一步瞭解 $EGO_TOP 環境變數的值，請參閱「Symphony 主機 Factory 服務問題」。

將 HF_LOGLEVEL 值從 LOG_INFO 更新為 LOG_DEBUG：

{
  ...
  "HF_LOGLEVEL": "LOG_DEBUG",
  ...
}

變更完成後，請儲存檔案。

如要讓變更生效，請重新啟動 HostFactory 服務：

egosh service stop HostFactory
egosh service start HostFactory

重新啟動後，HostFactory 服務會產生更詳細的記錄，可用於排解複雜問題。您可以在主機工廠記錄檔中查看這些記錄，該記錄檔位於 Linux 的 $EGO_TOP/hostfactory/log/hostfactory.hostname.log。

主機原廠供應商問題

下列問題發生在 Compute Engine 或 Google Kubernetes Engine 的主機工廠供應商指令碼中。

查看供應商記錄 (hf-gce.log 或 hf-gke.log)，瞭解詳細的錯誤訊息。hf-gce.log 和 hf-gke.log 檔案的位置取決於啟用供應商執行個體中供應商設定檔內設定的 LOGFILE 變數。

未佈建虛擬機器或 Pod

如果主機原廠供應商記錄顯示呼叫 requestMachines.sh 指令碼，但資源未顯示在專案中，就可能發生這個問題。 Cloud de Confiance by S3NS

如要解決這個問題，請按照下列步驟操作：

查看供應商指令碼記錄 (hf-gce.log 或 hf-gke.log)，瞭解 Cloud de Confiance by S3NS API 是否傳回錯誤訊息。hf-gce.log 和 hf-gke.log 檔案的位置取決於啟用供應商執行個體中供應商設定檔內設定的 LOGFILE 變數。
確認服務帳戶具備正確的 IAM 權限：
1. 請按照「查看目前的存取權」中的指示操作。
2. 確認服務帳戶在專案中具有 Compute 執行個體管理員 (v1) (roles/compute.instanceAdmin.v1) IAM 角色。如要進一步瞭解如何授予角色，請參閱「管理專案、資料夾和機構的存取權」。
為確保主機範本中的 Compute Engine 參數有效，您必須驗證下列項目：
1. 主機範本參數必須位於您在 Compute Engine 供應商安裝期間設定供應商執行個體時建立的 gcpgceinstprov_templates.json 檔案中。最常驗證的參數是 gcp_zone 和 gcp_instance_group。
2. 確認 gcp_instance_group 參數設定的執行個體群組存在。如要確認執行個體群組，請按照「查看 MIG 的屬性」一文中的操作說明，使用範本檔案中的 gcp_instance_group 名稱和 gcp_zone 區域值。

Pod 在 GKE 中停滯於 `Pending` 或 `Error` 狀態

如果 hf-gke 記錄檔顯示已建立 GCPSymphonyResource 資源，但 GKE 叢集中的對應 Pod 從未達到 Running 狀態，且可能顯示 Pending、ImagePullBackOff 或 CrashLoopBackOff 等狀態，就可能發生這個問題。

如果 Kubernetes 叢集發生問題，例如容器映像檔名稱無效、CPU 或記憶體資源不足，或是磁碟區或網路設定錯誤，就會發生這個問題。

如要解決這個問題，請使用 kubectl describe 檢查自訂資源和 Pod 的事件，找出根本原因：

kubectl describe gcpsymphonyresource RESOURCE_NAME
kubectl describe pod POD_NAME

更改下列內容：

RESOURCE_NAME：資源名稱。
POD_NAME：Pod 的名稱。

排解 Kubernetes 運算子問題

Kubernetes 運算子會管理 Symphony Pod 的生命週期。以下各節有助於排解運算子和這些資源的常見問題。

診斷資源狀態欄位問題

Kubernetes 運算子會透過兩種主要資源類型，管理 GKE 中的 Symphony 工作負載：

GCPSymphonyResource (GCPSR) 資源會管理 Symphony 工作負載的運算 Pod 生命週期。
MachineReturnRequest (MRR) 資源會處理運算資源的傳回和清除作業。

使用這些狀態欄位診斷 GCPSymphonyResource 資源的問題：

phase：資源目前的生命週期階段。選項為 Pending、Running、WaitingCleanup 或 Completed。
availableMachines：準備就緒的運算 Pod 數量。
conditions：詳細狀態條件和時間戳記。
returnedMachines：傳回的 Pod 清單。

使用這些狀態欄位診斷 MachineReturnRequest 資源的問題：

phase：退貨要求的目前階段。選項包括 Pending、InProgress、Completed、Failed 或 PartiallyCompleted。
totalMachines：要傳回的機器總數。
returnedMachines：成功退回的機器數量。
failedMachines：無法退回的機器數量。
machineEvents：每部機器的狀態詳細資料。

`GCPSymphonyResource` 資源停留在 `Pending` 狀態

如果 GCPSymphonyResource 資源仍處於 Pending 狀態，且 availableMachines 的值未增加，就會發生這個問題。

可能原因如下：

叢集中的節點容量不足。
提取容器映像檔時發生問題。
資源配額限制。

如何解決這個問題：

檢查 Pod 的狀態，找出映像檔提取或資源分配方面的問題：
```
kubectl describe pods -n gcp-symphony -l symphony.requestId=REQUEST_ID
```
將 REQUEST_ID 替換為要求 ID。
檢查節點，確保容量充足：
```
kubectl get nodes -o wide
```
Pod 可能會顯示 Pending 狀態。如果 Kubernetes 叢集需要擴大，但時間超出預期，通常就會發生這個問題。監控節點，確保控制層可以水平擴展。

未退還 Pod

建立 MachineReturnRequest (MRR) 時，如果 returnedMachines 數量未增加，就會發生這個問題。

發生這個問題的原因如下：

Pod 停滯在 Terminating 狀態。
節點連線發生問題。

如何解決這個問題：

檢查是否有 pod 停滯在 Terminating 狀態：

kubectl get pods -n gcp-symphony --field-selector=status.phase=Terminating

說明 MachineReturnRequest，取得退貨程序詳細資料：
```
kubectl describe mrr MRR_NAME -n gcp-symphony
```
將 MRR_NAME 替換為您的 MachineReturnRequest 名稱。
手動刪除自訂資源物件。這項刪除作業會啟動最終清除邏輯：
```
kubectl delete gcpsymphonyresource RESOURCE_NAME
```
將 RESOURCE_NAME 替換為 GCPSymphonyResource 資源的名稱。

`MachineReturnRequest` 中有大量機器故障

如果 MachineReturnRequest 狀態中的 failedMachines 計數大於 0，就會發生這個問題。發生這個問題的原因如下：

Pod 刪除作業逾時。
節點無法使用。

如何解決這個問題：

查看特定錯誤訊息的 MachineReturnRequest 狀態中的 machineEvents：
```
kubectl describe mrr MRR_NAME -n gcp-symphony
```
找出節點故障事件或控制層效能問題：
1. 取得所有節點的狀態：
```
kubectl get nodes -o wide
```
2. 檢查特定節點：
```
kubectl describe node NODE_NAME
```

不會刪除 Pod

如果已刪除的 Pod 卡在 Terminating 或 Error 狀態，就會發生這個問題。

發生這個問題的原因如下：

控制層或運算子負載過重，可能導致逾時或 API 節流事件。
手動刪除父項 GCPSymphonyResource 資源。

如何解決這個問題：

檢查上層 GCPSymphonyResource 資源是否仍可使用，且不處於 WaitingCleanup 狀態：
```
kubectl describe gcpsymphonyresource RESOURCE_NAME
```
如果父項 GCPSymphonyResource 資源已不在系統中，請從 Pod 手動移除終結器。終結器會告知 Kubernetes 等待 Symphony 運算子完成清理工作，再完全刪除 Pod。首先，請檢查 YAML 設定，找出終結器：
```
kubectl get pods -n gcp-symphony -l symphony.requestId=REQUEST_ID -o yaml
```
將 REQUEST_ID 替換為與 Pod 相關聯的要求 ID。
在輸出內容中，找出中繼資料區段內的終結器欄位。畫面會顯示類似如下的輸出：
```
metadata:
...
finalizers:
-   symphony-operator/finalizer
```

如要手動從 Pod 移除終結器，請使用 kubectl patch 指令：

kubectl patch pod -n gcp-symphony -l symphony.requestId=REQUEST_ID --type json -p '[{"op": "remove", "path": "/metadata/finalizers", "value": "symphony-operator/finalizer"}]'

將 REQUEST_ID 替換為與 Pod 相關聯的要求 ID。

舊的 Symphony 資源不會自動從 GKE 叢集刪除

工作負載完成且 GKE 停止 Pod 後，相關的 GCPSymphonyResource 和 MachineReturnRequest 物件會保留在 GKE 叢集中，時間會超過預期的 24 小時清除期。

如果 GCPSymphonyResource 物件缺少必要的 Completed status 條件，就會發生這個問題。運算子的自動清理程序會根據這個狀態移除物件。如要解決這個問題，請完成下列步驟：

查看有問題的 GCPSymphonyResource 資源詳細資料：
```
kubectl get gcpsr GCPSR_NAME -o yaml
```
將 GCPSR_NAME 替換為發生問題的 GCPSymphonyResource 資源名稱。

查看狀態為 True 的 Completed 類型條件：

status:
  availableMachines: 0
  conditions:
  -   lastTransitionTime: "2025-04-14T14:22:40.855099+00:00"
    message: GCPSymphonyResource g555dc430-f1a3-46bb-8b69-5c4c481abc25-2pzvc has
      no pods.
    reason: NoPods
    status: "True"        # This condition will ensure this
    type: Completed       # custom resource is cleaned up by the operator
  phase: WaitingCleanup
  returnedMachines:
  -   name: g555dc430-f1a3-46bb-8b69-5c4c481abc25-2pzvc-pod-0
    returnRequestId: 7fd6805f-9a00-41f9-afe9-c38aa35002db
    returnTime: "2025-04-14T14:22:39.373216+00:00"

如果 GCPSymphonyResource 詳細資料中未顯示此條件，而是顯示 phase: WaitingCleanup，表示 Completed 事件已遺失。

檢查與 GCPSymphonyResource 相關聯的 Pod：
```
kubectl get pods -l symphony.requestId=REQUEST_ID
```
將 REQUEST_ID 替換為要求 ID。
如果沒有任何 Pod，請安全地刪除 GCPSymphonyResource 資源：
```
kubectl delete gcpsr GCPSR_NAME
```
將 GCPSR_NAME 替換為您的 GCPSymphonyResource 名稱。
如果 Pod 在您刪除 GCPSymphonyResource 前就已存在，則必須刪除這些 Pod。如果 Pod 仍存在，請按照「Pod 未刪除」一節中的步驟操作。

Pod 未加入 Symphony 叢集

如果 Pod 在 GKE 中執行，但未顯示為 Symphony 叢集中的有效主機，就會發生這個問題。

如果 Pod 內執行的 Symphony 軟體無法連線至 Symphony 主要主機並註冊，就會發生這個問題。這個問題通常是由於網路連線問題，或是容器內的 Symphony 用戶端設定錯誤所致。

如要解決這個問題，請檢查 Pod 內執行的 Symphony 服務記錄。

使用 SSH 或 exec 存取 Pod 並查看記錄：
```
kubectl exec -it POD_NAME -- /bin/bash
```
將 POD_NAME 替換為 Pod 名稱。
如果 Pod 內有 sh，EGO 和 LIM 精靈的記錄會位於 $EGO_TOP/kernel/log 目錄。$EGO_TOP環境變數會指向 IBM Spectrum Symphony 安裝作業的根目錄：
```
cd $EGO_TOP/kernel/log
```
如要進一步瞭解 $EGO_TOP 環境變數的值，請參閱「Symphony 主機 Factory 服務」。
檢查記錄檔，找出導致 GKE Pod 無法連線至地端部署 Symphony 主要 Pod 的設定或網路錯誤。

機器退貨要求失敗

在縮減作業期間建立 MachineReturnRequest 自訂資源時，可能會發生這個問題，但物件會停滯，且運算子不會終止對應的 Symphony Pod。

運算子的終結器邏輯發生故障，導致系統無法乾淨地刪除 Pod 和相關聯的自訂資源。這個問題可能會導致資源成為孤立資源，並產生不必要的費用。

如要解決這個問題，請手動刪除自訂資源，這應該會啟動運算子的清除邏輯：

kubectl delete gcpsymphonyresource RESOURCE_NAME

將 RESOURCE_NAME 替換為資源名稱。

排解 IBM Spectrum Symphony 連接器問題

Symphony 主機工廠服務問題

叢集不會為待處理的工作負載新增 VM

主機工廠服務未啟動

其他錯誤和記錄

主機原廠供應商問題

未佈建虛擬機器或 Pod

Pod 在 GKE 中停滯於 Pending 或 Error 狀態

排解 Kubernetes 運算子問題

診斷資源狀態欄位問題

GCPSymphonyResource 資源停留在 Pending 狀態

未退還 Pod

MachineReturnRequest 中有大量機器故障

不會刪除 Pod

舊的 Symphony 資源不會自動從 GKE 叢集刪除

Pod 未加入 Symphony 叢集

機器退貨要求失敗

Pod 在 GKE 中停滯於 `Pending` 或 `Error` 狀態

`GCPSymphonyResource` 資源停留在 `Pending` 狀態

`MachineReturnRequest` 中有大量機器故障