このトピックでは、Cassandra データストアのトラブルシューティングと問題の修正の手順について説明します。Cassandra は、ハイブリッド ランタイム アーキテクチャの cassandra
コンポーネントで実行される永続データストアです。ランタイム サービス構成の概要もご覧ください。
Cassandra Pod が Pending 状態のままになる
症状
起動時の 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)の状態を確認し、作成されない理由を特定します。
- クラスタ内の 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 ...
- 障害が発生した 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 のエラーログを確認してください。
- Pod を一覧表示して、失敗した Cassandra Pod の ID を取得します。
kubectl get pods -n namespace
- 失敗した 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 のままです。このような問題は、基になるノードの障害を示している場合があります。
診断
- 実行されていない 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
- ワーカーノードを確認します。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
解決策
- ダウンしている Cassandra Pod をクラスタから削除します。
$ kubectl exec -it apigee-cassandra-default-0 -- nodetool status
$ kubectl exec -it apigee-cassandra-default-0 -- nodetool removenode deadnode_hostID
- アフィニティによって Cassandra Pod がデッドノードで起動しないようにするため、デッドノードから VolumeClaim を削除します。
kubectl get pvc -n your_namespace
kubectl delete pvc volumeClaim_name -n your_namespace
- ボリューム テンプレートを更新し、新しく追加されたノードの 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"]
- 値を新しいホスト名または IP に置き換えて、テンプレートを適用します。
kubectl apply -f volume-template.yaml
デバッグ用のクライアント コンテナを作成する
このセクションでは、cqlsh
などの Cassandra デバッグ ユーティリティにアクセスできるクライアント コンテナを作成する方法について説明します。これらのユーティリティを使用すると、Cassandra テーブルに対してクエリを実行できるので、デバッグに役立ちます。
クライアント コンテナを作成する
クライアント コンテナを作成する手順は次のとおりです。
- コンテナは、
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
。 - 次に、データストアの Secret 名を取得します。
kubectl get secrets -n apigee | grep "datastore.*-creds" | awk '{print $1}'
- 新しいファイルを開き、次の 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: "gcr.io/apigee-release/hybrid/apigee-hybrid-cassandra-client:1.5.10" 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
.yaml
という拡張子を付けてファイルを保存します。例:my-spec.yaml
- クラスタに仕様を適用します。
kubectl apply -f your-spec-file.yaml -n apigee
- コンテナにログインします。
kubectl exec -n apigee cassandra-client -it -- bash
- 次のコマンドを使用して、Cassandra
cqlsh
インターフェースに接続します。次のコマンドを正確に入力します。cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl
クライアント Pod の削除
次のコマンドを使用して、Cassandra クライアント Pod を削除します。
kubectl delete pods -n apigee cassandra-client
参考情報
Apigee と Apigee ハイブリッドのハンドブックの概要をご覧ください。