Cassandra 疑難排解指南

本主題將說明如何排解及修正 Cassandra 資料儲存區的問題。Cassandra 是持續性資料儲存空間,可在混合式執行階段架構cassandra 元件中執行。另請參閱「執行階段服務設定總覽」。

Cassandra Pod 停滯在「Pending」狀態

症狀

啟動時,Cassandra Pod 會維持在「Pending」(待處理) 狀態。

錯誤訊息

使用 kubectl 查看 Pod 狀態時,您會發現一或多個 Cassandra Pod 停滯在 Pending 狀態。Pending 狀態表示 Kubernetes 無法在節點上排定 Pod,因此無法建立 Pod。例如:

kubectl get pods -n namespace

NAME                                     READY   STATUS      RESTARTS   AGE
adah-resources-install-4762w             0/4     Completed   0          10m
apigee-cassandra-default-0                       0/1     Pending     0          10m
...

可能原因

Pod 停滯在「待處理」狀態的原因有很多,例如:

原因 說明
資源不足 CPU 或記憶體不足,無法建立 Pod。
無法建立磁碟區 Pod 正在等待建立永久磁碟區。

診斷

使用 kubectl 說明 Pod,判斷錯誤來源。例如:

kubectl -n namespace describe pods pod_name

例如:

kubectl -n apigee describe pods apigee-cassandra-default-0

輸出內容可能會顯示下列其中一個可能問題:

  • 如果問題是資源不足,您會看到「警告」訊息,指出 CPU 或記憶體不足。
  • 如果錯誤訊息指出 Pod 有未繫結的即時 PersistentVolumeClaim (PVC),表示 Pod 無法建立 永久磁碟區

解決方法

資源不足

修改 Cassandra 節點集區,確保有足夠的 CPU 和記憶體資源。 詳情請參閱「 調整節點集區大小」。

未建立永久磁碟區

如果判斷是永久磁碟區問題,請說明 PersistentVolumeClaim (PVC),判斷為何未建立該磁碟區:

  1. 列出叢集中的 PVC:
    kubectl -n namespace get pvc
    
    NAME                                STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    cassandra-data-apigee-cassandra-default-0   Bound    pvc-b247faae-0a2b-11ea-867b-42010a80006e   10Gi       RWO            standard       15m
    ...
  2. 說明發生故障的 Pod 的 PVC。舉例來說,下列指令會說明繫結至 Pod apigee-cassandra-default-0 的 PVC:
    kubectl apigee describe pvc cassandra-data-apigee-cassandra-default-0
    
    Events:
      Type     Reason              Age                From                         Message
      ----     ------              ----               ----                         -------
      Warning  ProvisioningFailed  3m (x143 over 5h)  persistentvolume-controller  storageclass.storage.k8s.io "apigee-sc" not found

    請注意,在這個範例中,名為 apigee-sc 的 StorageClass 不存在。如要解決這個問題,請在叢集中建立缺少的 StorageClass,詳情請參閱「 變更預設的 StorageClass」。

另請參閱「 偵錯 Pod」。

Cassandra pod 停滯在 CrashLoopBackoff 狀態

症狀

啟動時,Cassandra Pod 會維持在 CrashLoopBackoff 狀態。

錯誤訊息

使用 kubectl 查看 Pod 狀態時,您會發現一或多個 Cassandra Pod 處於 CrashLoopBackoff 狀態。這個狀態表示 Kubernetes 無法建立 Pod。例如:

kubectl get pods -n namespace

NAME                                     READY   STATUS            RESTARTS   AGE
adah-resources-install-4762w             0/4     Completed         0          10m
apigee-cassandra-default-0                       0/1     CrashLoopBackoff           0          10m
...

可能原因

Pod 停滯在 CrashLoopBackoff 狀態的原因有很多種,例如:

原因 說明
資料中心與先前的資料中心不同 這項錯誤表示 Cassandra Pod 具有來自先前叢集的資料的持續性磁碟區,而新的 Pod 無法加入舊叢集。如果先前 Cassandra 叢集在同一個 Kubernetes 節點上保留過時的永久磁碟區,通常就會發生這種情況。如果您刪除並重新建立叢集中的 Cassandra,就可能發生這個問題。
找不到信任儲存區目錄 這項錯誤表示 Cassandra Pod 無法建立 TLS 連線。 如果提供的金鑰和憑證無效、遺失或有其他問題,通常會發生這種情況。

診斷

查看 Cassandra 錯誤記錄,判斷問題原因。

  1. 列出 Pod,取得發生故障的 Cassandra Pod ID:
    kubectl get pods -n namespace
  2. 檢查失敗的 Pod 記錄:
    kubectl logs pod_id -n namespace

解決方法

在 Pod 的記錄中尋找下列線索:

資料中心與先前的資料中心不同

如果看到這則記錄訊息:

Cannot start node if snitch's data center (us-east1) differs from previous data center
  • 檢查叢集中是否有任何過時或舊的 PVC,並將其刪除。
  • 如果是全新安裝,請刪除所有 PVC,然後重新嘗試設定。例如:
    kubectl -n namespace get pvc
    kubectl -n namespace delete pvc cassandra-data-apigee-cassandra-default-0

找不到信任儲存區目錄

如果看到這則記錄訊息:

Caused by: java.io.FileNotFoundException: /apigee/cassandra/ssl/truststore.p12
(No such file or directory)

確認覆寫檔案中提供的金鑰和憑證正確無誤且有效。例如:

cassandra:
  sslRootCAPath: path_to_root_ca-file
  sslCertPath: path-to-tls-cert-file
  sslKeyPath: path-to-tls-key-file

節點故障

症狀

啟動時,Cassandra Pod 會維持在 Pending 狀態。這個問題可能表示底層節點發生故障。

診斷

  1. 判斷哪些 Cassandra Pod 未執行:
    $ kubectl get pods -n your_namespace
        NAME          READY   STATUS    RESTARTS   AGE
        cassandra-default-0   0/1     Pending   0          13s
        cassandra-default-1   1/1     Running   0          8d
        cassandra-default-2   1/1     Running   0          8d
  2. 檢查工作站節點。如果其中一個節點處於 NotReady 狀態,則該節點就是失敗的節點:
    kubectl get nodes -n your_namespace
    NAME                          STATUS   ROLES    AGE   VERSION
    ip-10-30-1-190.ec2.internal   Ready    <none>   8d    v1.13.2
    ip-10-30-1-22.ec2.internal    Ready    master   8d    v1.13.2
    ip-10-30-1-36.ec2.internal    NotReady <none>   8d    v1.13.2
    ip-10-30-2-214.ec2.internal   Ready    <none>   8d    v1.13.2
    ip-10-30-2-252.ec2.internal   Ready    <none>   8d    v1.13.2
    ip-10-30-2-47.ec2.internal    Ready    <none>   8d    v1.13.2
    ip-10-30-3-11.ec2.internal    Ready    <none>   8d    v1.13.2
    ip-10-30-3-152.ec2.internal   Ready    <none>   8d    v1.13.2
    ip-10-30-3-5.ec2.internal     Ready    <none>   8d    v1.13.2

解決方法

  1. 從叢集中移除已停止運作的 Cassandra Pod。
    $ kubectl exec -it apigee-cassandra-default-0 -- nodetool status
    $ kubectl exec -it apigee-cassandra-default-0 -- nodetool removenode deadnode_hostID
  2. 從無效節點移除 VolumeClaim,以免 Cassandra Pod 嘗試在無效節點上啟動 (因為親和性):
    kubectl get pvc -n your_namespace
    kubectl delete pvc volumeClaim_name -n your_namespace
  3. 更新磁碟區範本,並為新加入的節點建立 PersistentVolume。以下是卷冊範本範例:
    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: cassandra-data-3
    spec:
      capacity:
        storage: 100Gi
      accessModes:
      - ReadWriteOnce
      persistentVolumeReclaimPolicy: Retain
      storageClassName: local-storage
      local:
        path: /apigee/data
      nodeAffinity:
        "required":
          "nodeSelectorTerms":
          - "matchExpressions":
            - "key": "kubernetes.io/hostname"
              "operator": "In"
              "values": ["ip-10-30-1-36.ec2.internal"]
  4. 將值替換為新的主機名稱/IP,然後套用範本:
    kubectl apply -f volume-template.yaml