Cassandra のトラブルシューティング ガイド

このトピックでは、Cassandra データストアのトラブルシューティングと問題の修正の手順について説明します。Cassandra は、ハイブリッド ランタイム アーキテクチャcassandra コンポーネントで実行される永続データストアです。ランタイム サービス構成の概要もご覧ください。

Cassandra Pod が保留状態のままになる

症状

起動時の Cassandra Pod の状態が Pending のままです。

エラー メッセージ

kubectl を使用して Pod の状態を表示すると、1 つ以上の 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 が保留状態のままになる原因は、いくつかあります。例:

原因 説明
リソースの不足 Pod を作成するのに十分な CPU またはメモリがありません。
ボリュームが作成されていない Pod は、永続ボリュームの作成を待機しています。

診断

kubectl を使用して Pod を記述し、エラーの原因を特定します。例:

kubectl -n namespace describe pods pod_name

例:

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

出力に次のいずれかの問題が表示されることがあります。

  • 問題で十分なリソースがない場合は、CPU またはメモリの不足を示す警告メッセージが表示されます。
  • エラー メッセージに、Pod にバインドされていない即時 PersistentVolumeClaims(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 の状態を表示すると、1 つ以上の 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 の状態が 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. アフィニティによって Cassandra Pod がデッドノードで起動しないようにするため、デッドノードから VolumeClaim を削除します。
    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

デバッグ用のクライアント コンテナを作成する

このセクションでは、cqlsh などの Cassandra デバッグ ユーティリティにアクセスできるクライアント コンテナを作成する方法について説明します。これらのユーティリティを使用すると、Cassandra のテーブルに対してクエリを実行でき、デバッグに役立ちます。

クライアント コンテナを作成する

クライアント コンテナを作成する手順は次のとおりです。

  1. コンテナは、apigee-cassandra-user-setup Pod からの TLS 証明書を使用します。最初に、この証明書名をフェッチします。
    kubectl get secrets -n apigee |grep "kubernetes.io/tls"|grep apigee-cassandra-user-setup|awk '{print $1}'

    このコマンドは、証明書名を返します。例: apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls

  2. 次に、データストアのシークレット名を取得します。
    kubectl get secrets -n apigee | grep "datastore.*-creds" | awk '{print $1}' 
  3. 新しいファイルを開き、次の Pod 仕様を貼り付けます。
    apiVersion: v1
    kind: Pod
    metadata:
      labels:
      name: cassandra-client-name   # For example: my-cassandra-client
      namespace: apigee
    spec:
      containers:
      - name: cassandra-client-name
        image: "google/apigee-hybrid-cassandra-client:1.5.0"
        imagePullPolicy: Always
        command:
        - sleep
        - "3600"
        env:
        - name: CASSANDRA_SEEDS
          value: apigee-cassandra-default.apigee.svc.cluster.local
        - name: APIGEE_DML_USER
          valueFrom:
            secretKeyRef:
              key: dml.user
              name: default-datastore-creds  # The datastore secret name fetched previously.
        - name: APIGEE_DML_PASSWORD
          valueFrom:
            secretKeyRef:
              key: dml.password
              name: default-datastore-creds  # The datastore secret name fetched previously.
        volumeMounts:
        - mountPath: /opt/apigee/ssl
          name: tls-volume
          readOnly: true
      volumes:
      - name: tls-volume
        secret:
          defaultMode: 420
          secretName: your-secret-name    # For example: apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls
      restartPolicy: Never
  4. ファイルに .yaml 拡張子を付けて保存します。例: my-spec.yaml
  5. クラスタに仕様を適用します。
    kubectl apply -f your-spec-file.yaml -n apigee
  6. コンテナにログインします。
    kubectl exec -n apigee cassandra-client -it -- bash
  7. 次のコマンドを使用して、Cassandra cqlsh インターフェースに接続します。次のようにコマンドを正確に入力します。
    cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl

クライアント Pod を削除する

次のコマンドを使用して、Cassandra クライアント Pod を削除します。

kubectl delete pods -n apigee cassandra-client