排解 Apigee Hybrid 卡在建立或釋出狀態的問題

您正在查看 Apigee 和 Apigee Hybrid 說明文件。
這個主題沒有對應的 Apigee Edge 說明文件。

本文說明如何在 Apigee 混合元件卡在 creating 或 releasing 狀態時重設元件。

執行下列指令，列出 Apigee Hybrid 安裝的主要元件：

kubectl get crd | grep apigee

apigeeorganization (apigeeorganizations.apigee.cloud.google.com)
apigeeenvironment (apigeeenvironments.apigee.cloud.google.com)
apigeedatastore (apigeedatastores.apigee.cloud.google.com)
apigeetelemetries (apigeetelemetries.apigee.cloud.google.com)
apigeeredis (apigeeredis.apigee.cloud.google.com)

執行下列指令，查看目前的狀態：

kubectl get apigeedatastore -n NAMESPACE

當這些元件完全運作時，每個元件都會處於 running 狀態。例如：

NAME      STATE     AGE
default   running   5d6h

如果安裝作業失敗，元件可能會卡在 creating (或 releasing) 狀態。例如：

NAME      STATE     AGE
default   creating   5d6h

識別問題

如要找出問題的原因，請先說明每個元件。元件的結構如下：

每個 ApigeeOrganization 自訂資源都會以以下階層表示：

ApigeeOrganization/HASHED_VALUE
├─ApigeeDeployment/apigee-connect-agent-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-connect-agent-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-connect-agent-HASHED_VALUE
│ ├─ReplicaSet/apigee-connect-agent-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-connect-agent-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-mart-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-mart-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-mart-HASHED_VALUE
│ ├─ReplicaSet/apigee-mart-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-mart-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-watcher-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-watcher-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-watcher-HASHED_VALUE
│ ├─ReplicaSet/apigee-watcher-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-watcher-HASHED_VALUE-VER-xxxx

每個 ApigeeEnvironment 自訂資源都會以以下階層表示：

ApigeeEnvironment/HASHED_VALUE
├─ApigeeDeployment/apigee-runtime-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-runtime-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-runtime-HASHED_VALUE
│ ├─ReplicaSet/apigee-runtime-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-runtime-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-synchronizer-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-synchronizer-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-synchronizer-HASHED_VALUE
│ ├─ReplicaSet/apigee-synchronizer-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-synchronizer-HASHED_VALUE-VER-xxxx
├─ApigeeDeployment/apigee-udca-HASHED_VALUE
│ ├─HorizontalPodAutoscaler/apigee-udca-HASHED_VALUE-VER-xxxx
│ ├─PodDisruptionBudget/apigee-udca-HASHED_VALUE
│ ├─ReplicaSet/apigee-udca-HASHED_VALUE-VER-xxxx
│ │ └─Pod/apigee-udca-HASHED_VALUE-VER-xxxx

開始找出問題時，請先說明問題的根源元件。例如：

kubectl describe apigeeorganization -n NAMESPACE COMPONENT_NAME

檢查元件的 State 是否為 running：

      Replicas:
        Available:  1
        Ready:      1
        Total:      1
        Updated:    1
      State:        running
  State:            running
Events:             <none>

如果這個層級沒有記錄任何事件，請重複執行此程序，先執行 apigeedeployments，再執行 ReplicaSet。例如：

kubectl get apigeedeployment -n NAMESPACE AD_NAME>

如果 apigeedeployments 和 ReplicaSet 沒有顯示任何錯誤，請專注於未就緒的 Pod：

kubectl get pods -n NAMESPACE

NAME                                                              READY   STATUS
apigee-cassandra-default-0                                        1/1     Running
apigee-connect-agent-apigee-b56a362-150rc2-42gax-dbrrn            1/1     Running
apigee-logger-apigee-telemetry-s48kb                              1/1     Running
apigee-mart-apigee-b56a362-150rc2-bcizm-7jv6w                     0/2     Running
apigee-runtime-apigee-test-0d59273-150rc2-a5mov-dfb29             0/1     Running

在這個範例中，mart 和 runtime 尚未就緒。檢查 Pod 記錄以找出錯誤：

kubectl logs -n NAMESPACE POD_NAME

刪除元件

如果您在任何這些元件中犯錯，請刪除該元件，然後使用 Helm 重新建立環境：

kubectl delete -n apigee apigeeenv HASHED_ENV_NAME

接著建立環境 (在完成必要的修正後)：

helm upgrade ENV_NAME apigee-env/ \
--install \
--namespace APIGEE_NAMESPACE \
--set env=ENV_NAME \
--atomic \
-f OVERRIDES_FILE \
--dry-run=server

請務必加入所有顯示的設定，包括 --atomic，

安裝圖表：

helm upgrade ENV_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  --atomic \
  -f OVERRIDES_FILE

檢查控制器

如果 Pod 中沒有明顯的錯誤訊息，但元件尚未轉換至 running 狀態，請檢查 apigee-controller 是否有錯誤訊息。

kubectl logs -n NAMESPACE $(k get pods -n NAMESPACE | sed -n '2p' | awk '{print $1}') | grep -i error

這樣一來，使用者就能瞭解為何控制器無法處理要求 (create/delete/update 等)。

Apigee 資料儲存庫

Apache Cassandra 會以 StatefulSet 的形式實作。每個 Cassandra 例項都包含：

ApigeeDatastore/default
├─Certificate/apigee-cassandra-default
│ └─CertificateRequest/apigee-cassandra-default-wnd7s
├─Secret/config-cassandra-default
├─Service/apigee-cassandra-default
│ ├─EndpointSlice/apigee-cassandra-default-7m9kx
│ └─EndpointSlice/apigee-cassandra-default-gzqpr
└─StatefulSet/apigee-cassandra-default
  ├─ControllerRevision/apigee-cassandra-default-6976b77bd
  ├─ControllerRevision/apigee-cassandra-default-7fc76588cb
  └─Pod/apigee-cassandra-default-0

這個範例顯示一個 Pod，但實際的正式安裝作業通常會包含三個以上的 Pod。

如果 Cassandra 的狀態為 creating 或 releasing，則必須重設狀態。某些問題 (例如 Cassandra 密碼變更) 和與網路無關的問題，可能需要您刪除元件。在這種情況下，您很可能無法刪除執行個體 (即kubectl delete apigeedatastore -n NAMESPACE default)。使用 --force 或 --grace-period=0 也無法解決問題。

reset 的目標是將元件 (apigeedatastore) 的狀態從 creating 或 releasing 變更回 running。以這種方式變更狀態通常不會解決潛在問題。在大多數情況下，您應在重設後刪除元件。

  1. 嘗試刪除 (不會成功)：

    kubectl delete -n NAMESPACE apigeedatastore default

    這個指令通常不會完成。使用 Ctrl+C 鍵終止呼叫。

  2. 重設狀態：

    在視窗 1 中：

    kubectl proxy

    使用 Window 2：

    curl -X PATCH -H "Accept: application/json" -H "Content-Type: application/json-patch+json" --data '[{"op": "replace", "path": "/status/nestedState", "value": ""},{"op": "replace", "path": "/status/state", "value": "running"}]' 'http://127.0.0.1:8001/apis/apigee.cloud.google.com/v1alpha1/namespaces/apigee/apigeedatastores/default/status'

    移除 finalizer (視窗 2)：

    kubectl edit -n NAMESPACE apigeedatastore default

    找出並刪除以下兩行：

    finalizers:
- apigeedatastore.apigee.cloud.google.com

常見錯誤情況

執行階段無法使用 Proxy 設定

這項錯誤可能會以下列任一方式顯示：

  • runtime 並未處於 ready 狀態。
  • runtime 尚未收到最新版的 API。

  1. 請先從 synchronizer 容器開始。

    檢查 synchronizer 的記錄。常見錯誤如下：

    • 缺乏網路連線 (至 *.googleapi.com)
    • IAM 存取權不正確 (服務帳戶無法使用，或未由 Synchronizer Manager 權限提供)
    • 未叫用 setSyncAuthorization API

  2. 檢查 runtime Pod。

    檢查 runtime Pod 的記錄，即可瞭解 runtime 為何未載入設定。控制層會盡力避免大部分的設定錯誤傳送至資料層。如果無法驗證或未正確實作驗證，runtime 就會無法載入驗證。

控制層中的「No runtime pods」

  1. 請先從 synchronizer 容器開始。

    檢查 synchronizer 的記錄。常見錯誤如下：

    • 缺乏網路連線 (至 *.googleapi.com)
    • IAM 存取權不正確 (服務帳戶無法使用，或未由 Synchronizer Manager 權限提供)
    • 未叫用 setSyncAuthorization API。也許設定從未傳送至資料層。

  2. 檢查 runtime Pod。

    檢查 runtime Pod 的記錄，即可瞭解 runtime 為何未載入設定。

  3. 檢查 watcher Pod。

    watcher 元件會設定入口 (路由)，並將 Proxy 和入口部署狀態回報給控制層。檢查這些記錄，找出 watcher 未回報狀態的原因。常見原因包括 overrides.yaml 檔案中的名稱與控制平面中的環境名稱和/或環境群組名稱不符。

偵錯工作階段未顯示在控制層

  1. 請先從 synchronizer 容器開始。

    檢查 synchronizer 的記錄。常見錯誤如下：

    • 缺乏網路連線 (至 *.googleapi.com)
    • IAM 存取權不正確 (服務帳戶無法使用，或未由 Synchronizer Manager 權限提供)
    • 未叫用 setSyncAuthorization API。
  2. 檢查 runtime Pod。
    檢查 runtime pod 中的記錄，即可瞭解 runtime 為何未將偵錯記錄傳送至 UDCA。
  3. 檢查 UDCA Pod。
    檢查 UDCA 的記錄，即可瞭解 UDCA 為何未將偵錯工作階段資訊傳送至控制平面。

Cassandra 傳回大型快取回應

以下警告訊息表示 Cassandra 收到的讀取或寫入要求具有較大的酬載，但由於警告門檻已設為較低值，用於指出回應酬載大小，因此可以安全地忽略這項警告。

Batch for [cache_ahg_gap_prod_hybrid.cache_map_keys_descriptor, cache_ahg_gap_prod_hybrid.cache_map_entry] is of size 79.465KiB, exceeding specified threshold of 50.000KiB by 29.465KiB