Cassandra 疑難排解指南

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

Cassandra pod 卡在待處理狀態

症狀

啟動時，Cassandra 會維持在「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。

另請參閱「 偵錯 Pods」。

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 無法加入舊叢集。這通常是因為在同一個 Kubernetes 節點上，先前的 Cassandra 叢集中仍保留了過時的永久磁碟區。如果您在叢集中刪除 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 會維持在待處理狀態。這可能表示基礎節點發生故障。

診斷

  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. 檢查 worker 節點。如果其中一個節點處於「NotReady」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