Memecahkan masalah workload yang di-deploy

Halaman ini menunjukkan cara menyelesaikan error pada workload yang di-deploy di Google Kubernetes Engine (GKE).

Untuk saran yang lebih umum tentang pemecahan masalah aplikasi, lihat Pemecahan Masalah Aplikasi dalam dokumentasi Kubernetes.

Semua error: Periksa status Pod

Jika ada masalah dengan Pod workload, Kubernetes akan memperbarui status Pod dengan pesan error. Lihat error ini dengan memeriksa status Pod menggunakan konsol Google Cloud atau alat command line kubectl.

kubectl get pods

NAME       READY  STATUS             RESTARTS  AGE
POD_NAME   0/1    CrashLoopBackOff   23        8d

kubectl describe pod POD_NAME

kubectl logs POD_NAME

Setelah mengidentifikasi error, gunakan bagian berikut untuk mencoba menyelesaikan masalah tersebut.

Error: CrashLoopBackOff

Status CrashLoopBackOff tidak berarti ada error tertentu, tetapi menunjukkan bahwa container berulang kali mengalami error setelah dimulai ulang. Saat container mengalami error atau keluar segera setelah dimulai (CrashLoop), Kubernetes akan mencoba memulai ulang container. Dengan setiap kegagalan mulai ulang, penundaan (BackOff) sebelum upaya berikutnya meningkat secara eksponensial (10 dtk, 20 dtk, 40 dtk, dll.), hingga maksimum lima menit.

Bagian berikut membantu Anda mengidentifikasi penyebab kemungkinan error pada penampung.

Menggunakan playbook interaktif Crashlooping Pods

Mulai pecahkan masalah penyebab status CrashLoopBackOff dengan menggunakan playbook interaktif di konsol Google Cloud :

1. Buka playbook interaktif Crashlooping Pods:

   Buka Playbook

2. Di menu drop-down Cluster, pilih cluster yang ingin Anda pecahkan masalahnya. Jika Anda tidak dapat menemukan cluster, masukkan nama cluster di kolom filter_list Filter.

3. Di menu drop-down Namespace, pilih namespace yang ingin Anda pecahkan masalahnya. Jika Anda tidak dapat menemukan namespace, masukkan namespace di kolom filter_list Filter.

4. Pelajari setiap bagian untuk membantu Anda mengidentifikasi penyebabnya:

   1. Mengidentifikasi Error Aplikasi
   2. Menyelidiki Masalah Kehabisan Memori
   3. Menyelidiki Gangguan Node
   4. Menyelidiki Kegagalan Pemeriksaan Keaktifan
   5. Menghubungkan Peristiwa Perubahan

5. Opsional: Untuk mendapatkan notifikasi tentang error CrashLoopBackOff di masa mendatang, di bagian Tips Mitigasi di Masa Mendatang, pilih Buat Pemberitahuan.

Memeriksa log

Container mungkin mengalami error lagi karena berbagai alasan, dan memeriksa log Pod dapat membantu Anda memecahkan akar masalah.

Anda dapat memeriksa log dengan konsol Google Cloud atau alat command line kubectl.

Periksa kode keluar dari container yang mengalami error

Untuk lebih memahami penyebab error container, temukan kode keluar:

1. Deskripsikan Pod:

   kubectl describe pod POD_NAME
   

   Ganti POD_NAME dengan nama Pod yang bermasalah.

2. Tinjau nilai di kolom containers: CONTAINER_NAME: last state: exit code:

   • Jika exit code adalah 1, container mengalami error karena aplikasi mengalami error.
   • Jika exit code adalah 0, periksa berapa lama aplikasi Anda berjalan. Container berhenti saat proses utama aplikasi Anda berhenti. Jika aplikasi Anda menyelesaikan eksekusi dengan sangat cepat, container mungkin terus dimulai ulang. Jika Anda mengalami error ini, salah satu solusinya adalah menetapkan kolom restartPolicy ke OnFailure. Setelah Anda melakukan perubahan ini, aplikasi hanya dimulai ulang jika kode keluar bukan 0.

Menghubungkan ke container yang sedang berjalan

Untuk menjalankan perintah bash dari container agar Anda dapat menguji jaringan atau memeriksa apakah Anda memiliki akses ke file atau database yang digunakan oleh aplikasi, buka shell ke Pod:

kubectl exec -it POD_NAME -- /bin/bash

Jika ada lebih dari satu container di Pod, tambahkan -c CONTAINER_NAME.

Error: ImagePullBackOff dan ErrImagePull

Status ImagePullBackOff atau ErrImagePull menunjukkan bahwa image yang digunakan oleh container tidak dapat dimuat dari image registry.

Untuk mendapatkan panduan tentang cara memecahkan masalah status ini, lihat Memecahkan masalah penarikan gambar.

Error: Pod tidak dapat dijadwalkan

Status PodUnschedulable menunjukkan bahwa Pod Anda tidak dapat dijadwalkan karena resource tidak memadai atau adanya error konfigurasi.

Jika Anda telah mengonfigurasi metrik bidang kontrol, Anda dapat menemukan informasi selengkapnya tentang error ini di metrik scheduler dan metrik server API.

Menggunakan playbook interaktif Pod yang tidak dapat dijadwalkan

Anda dapat memecahkan masalah error PodUnschedulable menggunakan playbook interaktif di konsol Google Cloud :

1. Buka playbook interaktif Pod yang tidak dapat dijadwalkan:

   Buka Playbook

2. Di menu drop-down Cluster, pilih cluster yang ingin Anda pecahkan masalahnya. Jika Anda tidak dapat menemukan cluster, masukkan nama cluster di kolom filter_list Filter.

3. Di menu drop-down Namespace, pilih namespace yang ingin Anda pecahkan masalahnya. Jika Anda tidak dapat menemukan namespace, masukkan namespace di kolom filter_list Filter.

4. Untuk membantu Anda mengidentifikasi penyebabnya, pelajari setiap bagian dalam playbook:

   1. Menyelidiki CPU dan Memori
   2. Menyelidiki Pod Maksimum per Node
   3. Menyelidiki Perilaku Autoscaler
   4. Menyelidiki Mode Kegagalan Lainnya
   5. Menghubungkan Peristiwa Perubahan

5. Opsional: Untuk mendapatkan notifikasi tentang error PodUnschedulable di masa mendatang, di bagian Tips Mitigasi di Masa Mendatang, pilih Buat Pemberitahuan .

Error: Resource tidak cukup

Anda mungkin mengalami error yang menunjukkan kurangnya CPU, memori, atau resource lainnya. Misalnya: No nodes are available that match all of the predicates: Insufficient cpu (2) yang menunjukkan bahwa di dua node, tidak ada CPU yang cukup untuk memenuhi permintaan Pod.

Jika permintaan resource Pod Anda melebihi permintaan yang tersedia pada satu node dari setiap node pool yang memenuhi syarat, GKE tidak akan menjadwalkan Pod tersebut dan juga tidak akan memicu peningkatan skala untuk menambahkan node baru. Agar GKE dapat menjadwalkan Pod, Anda harus meminta lebih sedikit resource untuk Pod, atau membuat node pool baru dengan resource yang memadai.

Anda juga dapat mengaktifkan penyediaan otomatis node sehingga GKE dapat otomatis membuat node pool dengan node tempat Pod yang tidak terjadwal dapat dijalankan.

Permintaan CPU default adalah 100 m atau 10% dari satu CPU (atau satu core). Jika Anda ingin meminta lebih banyak atau lebih sedikit resource, tentukan nilai dalam spesifikasi Pod di bagian spec: containers: resources: requests.

Error: MatchNodeSelector

MatchNodeSelector menunjukkan bahwa tidak ada node yang cocok dengan pemilih label Pod.

Untuk memastikan hal ini, periksa label yang ditentukan dalam kolom nodeSelector spesifikasi Pod, pada bagian spec: nodeSelector.

Untuk melihat label pada node di cluster Anda, jalankan perintah berikut:

kubectl get nodes --show-labels

Untuk melampirkan label ke node, jalankan perintah berikut:

kubectl label nodes NODE_NAME LABEL_KEY=LABEL_VALUE

Ganti kode berikut:

• NODE_NAME: node yang ingin Anda tambahi label.
• LABEL_KEY: kunci label.
• LABEL_VALUE: nilai label.

Untuk mengetahui informasi selengkapnya, lihat bagian Menetapkan Pod ke Node dalam dokumentasi Kubernetes.

Error: PodToleratesNodeTaints

PodToleratesNodeTaints menunjukkan bahwa Pod tidak dapat dijadwalkan ke node mana pun karena Pod tidak memiliki toleransi yang sesuai dengan taint node yang ada.

Untuk memastikan bahwa hal ini memang terjadi, jalankan perintah berikut:

kubectl describe nodes NODE_NAME

Di output, periksa kolom Taints, yang mencantumkan key-value pair dan dampak pada penjadwalan.

Jika dampak yang tercantum adalah NoSchedule, tidak ada Pod yang dapat dijadwalkan pada node tersebut kecuali jika memiliki tolerasi yang cocok.

Salah satu cara untuk mengatasi masalah ini adalah dengan menghapus taint. Misalnya, untuk menghapus taint NoSchedule, jalankan perintah berikut:

kubectl taint nodes NODE_NAME key:NoSchedule-

Error: PodFitsHostPorts

Error PodFitsHostPorts berarti bahwa node mencoba menggunakan port yang sudah digunakan.

Untuk mengatasi masalah ini, sebaiknya ikuti praktik terbaik Kubernetes dan gunakan NodePort, bukan hostPort.

Jika Anda harus menggunakan hostPort, periksa manifes Pod dan pastikan semua Pod di node yang sama memiliki nilai unik yang ditentukan untuk hostPort.

Error: Tidak memiliki ketersediaan minimum

Jika node memiliki resource yang memadai, tetapi Anda masih melihat pesan Does not have minimum availability, periksa status Pod. Jika statusnya adalah SchedulingDisabled atau Cordoned, node tidak dapat menjadwalkan Pod baru. Anda dapat memeriksa status node menggunakan konsol Google Cloud atau alat command line kubectl.

kubectl get nodes

kubectl uncordon NODE_NAME

Error: Batas Pod maksimum per node tercapai

Jika batas Pod Maksimum per node dicapai oleh semua node dalam cluster, Pod akan terjebak dalam status Tidak dapat dijadwalkan. Di bagian tab Peristiwa Pod, Anda akan melihat pesan yang menyertakan frasa Too many pods.

Untuk mengatasi error ini, selesaikan langkah-langkah berikut:

1. Periksa konfigurasi Maximum pods per node dari tab Node pada detail cluster GKE di konsol Google Cloud .

2. Mendapatkan daftar node:

   kubectl get nodes
   

3. Untuk setiap node, pastikan jumlah Pod yang berjalan di node:

   kubectl get pods -o wide | grep NODE_NAME | wc -l
   

4. Jika batas tercapai, tambahkan node pool baru atau tambahkan node lain ke node pool yang ada.

Masalah: Ukuran maksimum node pool tercapai dengan autoscaler cluster diaktifkan

Jika node pool telah mencapai ukuran maksimum sesuai dengan konfigurasi autoscaler cluster-nya, GKE tidak akan memicu peningkatan skala untuk Pod yang seharusnya dijadwalkan dengan node pool ini. Jika Anda menginginkan agar Pod dijadwalkan dengan node pool ini, ubah konfigurasi autoscaler cluster-nya.

Masalah: Ukuran maksimum node pool tercapai dengan autoscaler cluster dinonaktifkan

Jika node pool telah mencapai jumlah maksimum node, dan autoscaler cluster dinonaktifkan, GKE tidak dapat menjadwalkan Pod dengan node pool. Tingkatkan ukuran node pool atau aktifkan autoscaler cluster agar GKE dapat otomatis mengubah ukuran cluster Anda.

Error: PersistentVolumeClaims yang tidak terikat

Unbound PersistentVolumeClaims menunjukkan bahwa Pod mereferensikan PersistentVolumeClaim yang telah dilepas. Error ini dapat terjadi jika PersistentVolume Anda gagal disediakan. Anda dapat memastikan bahwa penyediaan gagal dengan mendapatkan peristiwa untuk PersistentVolumeClaim dan memeriksanya untuk melihat apakah memang terjadi kegagalan.

Untuk mendapatkan peristiwa, jalankan perintah berikut:

kubectl describe pvc STATEFULSET_NAME-PVC_NAME-0

Ganti kode berikut:

• STATEFULSET_NAME: nama objek StatefulSet.
• PVC_NAME: nama objek PersistentVolumeClaim.

Hal ini juga dapat terjadi jika ada error konfigurasi selama pra-penyediaan PersistentVolume manual Anda dan dalam proses bindingnya ke PersistentVolumeClaim.

Untuk mengatasi error ini, coba lakukan pra-penyediaan volume lagi.

Error: Kuota tidak mencukupi

Pastikan project Anda memiliki kuota Compute Engine yang memadai untuk GKE guna meningkatkan skala cluster Anda. Jika GKE mencoba menambahkan node ke cluster Anda untuk menjadwalkan Pod, dan peningkatan skala melebihi kuota project yang tersedia, Anda akan menerima pesan error scale.up.error.quota.exceeded.

Untuk mempelajari lebih lanjut, lihat Error ScaleUp.

Masalah: API yang tidak digunakan lagi

Pastikan Anda tidak menggunakan API yang sudah tidak digunakan lagi dan dihapus dengan versi minor cluster Anda. Untuk mempelajari lebih lanjut, lihat Penghentian penggunaan fitur dan API.

Error: Tidak memiliki port kosong untuk port Pod yang diminta

Jika Anda melihat error yang mirip dengan berikut, kemungkinan Anda memiliki beberapa Pod di node yang sama dengan nilai yang sama yang ditentukan di kolom hostPort:

0/1 nodes are available: 1 node(s) didn't have free ports for the requested pod ports. preemption: 0/1 nodes are available: 1 No preemption victims found for incoming pod.

Mengikat Pod ke hostPort membatasi tempat GKE dapat menjadwalkan Pod karena setiap kombinasi hostIP, hostPort, dan protocol harus unik.

Untuk mengatasi masalah ini, sebaiknya ikuti praktik terbaik Kubernetes dan gunakan NodePort, bukan hostPort.

Jika Anda harus menggunakan hostPort, periksa manifes Pod dan pastikan semua Pod di node yang sama memiliki nilai unik yang ditentukan untuk hostPort.

Langkah berikutnya

• Jika Anda tidak dapat menemukan solusi untuk masalah Anda dalam dokumentasi, lihat Mendapatkan dukungan untuk mendapatkan bantuan lebih lanjut, termasuk saran tentang topik berikut:

  • Membuka kasus dukungan dengan menghubungi Layanan Pelanggan Cloud.
  • Mendapatkan dukungan dari komunitas dengan mengajukan pertanyaan di StackOverflow dan menggunakan tag google-kubernetes-engine untuk menelusuri masalah serupa. Anda juga dapat bergabung ke #kubernetes-engine channel Slack untuk mendapatkan dukungan komunitas lainnya.
  • Membuka bug atau permintaan fitur menggunakan issue tracker publik.