Topik ini membahas langkah-langkah yang dapat Anda lakukan untuk memecahkan dan memperbaiki masalah pada penyimpanan data Cassandra. Cassandra adalah
penyimpanan data persisten
yang berjalan di komponen cassandra dari
arsitektur runtime hybrid.
Lihat juga
Ringkasan konfigurasi layanan runtime.
Pod Cassandra macet dalam status Pending
Gejala
Saat dimulai, pod Cassandra tetap dalam status Pending.
Pesan error
Saat menggunakan kubectl untuk melihat status pod, Anda akan melihat bahwa satu atau beberapa pod Cassandra mengalami masalah dan berada dalam status Pending. Status
Pending menunjukkan bahwa Kubernetes tidak dapat menjadwalkan pod
di sebuah node: pod tidak dapat dibuat. Contoh:
kubectl get pods -n namespace
NAME READY STATUS RESTARTS AGE
adah-resources-install-4762w 0/4 Completed 0 10m
apigee-cassandra-0 0/1 Pending 0 10m
...Kemungkinan penyebab
Pod yang macet dalam status Tertunda dapat disebabkan oleh beberapa hal. Contoh:
| Penyebab | Deskripsi |
|---|---|
| Resource tidak cukup | CPU atau memori yang tersedia tidak cukup untuk membuat pod. |
| Volume tidak dibuat | Pod sedang menunggu volume persisten dibuat. |
Diagnosis
Gunakan kubectl
untuk mendeskripsikan pod guna menentukan sumber error. Contoh:
kubectl -n namespace describe pods pod_name
Contoh:
kubectl -n apigee describe pods apigee-cassandra-0
Output dapat menunjukkan salah satu kemungkinan masalah berikut:
- Jika masalahnya adalah resource yang tidak memadai, Anda akan melihat pesan Peringatan yang menunjukkan CPU atau memori yang tidak memadai.
- Jika pesan error menunjukkan bahwa pod telah melepaskan PersistentVolumeClaim (PVC) langsung, artinya pod tidak dapat membuat Volume persisten.
Resolusi
Resource tidak cukup
Ubah node pool Cassandra agar memiliki resource CPU dan memori yang memadai. Lihat Mengubah ukuran node pool untuk mengetahui detailnya.
Volume persisten tidak dibuat
Jika Anda menentukan masalah volume persisten, deskripsikan PersistentVolumeClaim (PVC) untuk menentukan mengapa PVC tidak dibuat:
- Cantumkan PVC di cluster:
kubectl -n namespace get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE cassandra-data-apigee-cassandra-0 Bound pvc-b247faae-0a2b-11ea-867b-42010a80006e 10Gi RWO standard 15m ...
- Jelaskan PVC untuk pod yang gagal. Misalnya, perintah berikut
menjelaskan PVC yang terikat ke pod
apigee-cassandra-0:kubectl apigee describe pvc cassandra-data-apigee-cassandra-0 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ProvisioningFailed 3m (x143 over 5h) persistentvolume-controller storageclass.storage.k8s.io "apigee-sc" not found
Perhatikan bahwa dalam contoh ini, StorageClass bernama
apigee-sctidak ada. Untuk mengatasi masalah ini, buat StorageClass yang tidak ada di cluster, seperti yang dijelaskan dalam Mengubah StorageClass default.
Lihat juga Men-debug Pod.
Pod Cassandra macet dalam status CrashLoopBackoff
Gejala
Saat dimulai, pod Cassandra tetap dalam status CrashLoopBackoff.
Pesan error
Saat menggunakan kubectl untuk melihat status pod, Anda akan melihat bahwa satu atau beberapa pod Cassandra berada dalam status CrashLoopBackoff.
Status ini menunjukkan bahwa Kubernetes tidak dapat membuat pod. Contoh:
kubectl get pods -n namespace
NAME READY STATUS RESTARTS AGE
adah-resources-install-4762w 0/4 Completed 0 10m
apigee-cassandra-0 0/1 CrashLoopBackoff 0 10m
...Kemungkinan penyebab
Pod yang macet dalam status CrashLoopBackoff dapat disebabkan oleh beberapa hal. Contoh:
| Penyebab | Deskripsi |
|---|---|
| Pusat data berbeda dari pusat data sebelumnya | Error ini menunjukkan bahwa pod Cassandra memiliki volume persisten yang berisi data dari cluster sebelumnya, dan pod baru tidak dapat bergabung dengan cluster lama. Hal ini biasanya terjadi saat volume persisten yang tidak aktif tetap ada dari cluster Cassandra sebelumnya di node Kubernetes yang sama. Masalah ini dapat terjadi jika Anda menghapus dan membuat ulang Cassandra di cluster. |
| Direktori Truststore tidak ditemukan | Error ini menunjukkan bahwa pod Cassandra tidak dapat membuat koneksi TLS. Hal ini biasanya terjadi jika kunci dan sertifikat yang diberikan tidak valid, tidak ada, atau memiliki masalah lainnya. |
Diagnosis
Periksa log error Cassandra untuk mengetahui penyebab masalah.
- Buat daftar pod untuk mendapatkan ID pod Cassandra yang gagal:
kubectl get pods -n namespace
- Periksa log pod yang gagal:
kubectl logs pod_id -n namespace
Resolusi
Cari petunjuk berikut dalam log pod:
Pusat data berbeda dari pusat data sebelumnya
Jika Anda melihat pesan log ini:
Cannot start node if snitch's data center (us-east1) differs from previous data center
- Periksa apakah ada PVC yang tidak aktif atau lama di cluster dan hapus PVC tersebut.
- Jika ini adalah penginstalan baru, hapus semua PVC dan coba lagi penyiapan. Contoh:
kubectl -n namespace get pvckubectl -n namespace delete pvc cassandra-data-apigee-cassandra-0
Direktori Truststore tidak ditemukan
Jika Anda melihat pesan log ini:
Caused by: java.io.FileNotFoundException: /apigee/cassandra/ssl/truststore.p12 (No such file or directory)
Pastikan kunci dan sertifikat yang diberikan dalam file penggantian sudah benar dan valid. Misalnya:
cassandra: sslRootCAPath: path_to_root_ca-file sslCertPath: path-to-tls-cert-file sslKeyPath: path-to-tls-key-file
Kegagalan node
Gejala
Saat dimulai, pod Cassandra tetap dalam status Pending. Masalah ini dapat menunjukkan kegagalan node yang mendasarinya.
Diagnosis
- Tentukan pod Cassandra mana yang tidak berjalan:
$ kubectl get pods -n your_namespace NAME READY STATUS RESTARTS AGE cassandra-0 0/1 Pending 0 13s cassandra-1 1/1 Running 0 8d cassandra-2 1/1 Running 0 8d
- Periksa node pekerja. Jika salah satunya dalam status NotReady, maka
node tersebut adalah node yang gagal:
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
Resolusi
- Hapus pod Cassandra yang tidak aktif dari cluster.
$ kubectl exec -it apigee-cassandra-0 -- nodetool status
$ kubectl exec -it apigee-cassandra-0 -- nodetool removenode deadnode_hostID - Hapus VolumeClaim dari node yang tidak aktif untuk mencegah
pod Cassandra mencoba muncul di node yang tidak aktif karena
afinitas:
kubectl get pvc -n your_namespace
kubectl delete pvc volumeClaim_name -n your_namespace - Perbarui template volume dan buat PersistentVolume untuk
node yang baru ditambahkan. Berikut adalah contoh template volume:
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"]
- Ganti nilai dengan nama host/IP baru dan terapkan template:
kubectl apply -f volume-template.yaml