Container Compute Service:Troubleshoot pod issues

Dalam topik ini

Proses diagnosis

1. Periksa apakah terdapat status pod yang abnormal. Untuk informasi selengkapnya, lihat Periksa status pod.

   1. Jika pod berada dalam status abnormal, periksa event, log, dan konfigurasinya untuk mengidentifikasi penyebabnya. Untuk informasi selengkapnya, lihat Metode troubleshooting umum. Informasi tentang status pod abnormal umum dan cara menanganinya tersedia di Status pod abnormal umum dan solusinya.

   2. Jika pod berada dalam status Running tetapi tidak berfungsi sebagaimana mestinya, lihat Pod berada dalam status Running tetapi tidak berfungsi sebagaimana mestinya.

2. Jika Anda memastikan adanya masalah OOM pada pod, lihat Troubleshoot masalah OOM pada pod.

3. Jika masalah berlanjut, ajukan Tiket.

Status pod abnormal umum dan solusinya

Metode troubleshooting umum

Periksa status pod

1. Login ke ACS console. Di panel navigasi kiri, klik Clusters.

2. Di halaman Clusters, klik nama kluster target. Di panel navigasi kiri, pilih Workloads > Pods.

3. Di pojok kiri atas halaman Pods, pilih Namespace pod tersebut dan periksa statusnya.

   • Jika statusnya Running, pod berfungsi sebagaimana mestinya.

   • Jika statusnya bukan Running, pod berada dalam status abnormal. Solusinya tersedia di Status pod abnormal umum dan solusinya.

Periksa detail pod

Periksa konfigurasi pod

Periksa event pod

1. Login ke ACS console. Di panel navigasi kiri, klik Clusters.

2. Di halaman Clusters, klik nama kluster target. Di panel navigasi kiri, pilih Workloads > Pods.

3. Di pojok kiri atas halaman Pods, pilih Namespace pod tersebut. Lalu, klik nama pod target atau klik Details di kolom Actions.

4. Di pojok kanan atas halaman detail pod, klik Edit untuk melihat file YAML dan konfigurasi detail pod tersebut.

5. Di halaman detail pod, klik tab Events.

   Catatan

   Secara default, Kubernetes menyimpan event dari satu jam terakhir. Untuk menyimpan event lebih lama, lihat Create and use a Kubernetes event center.

Periksa log pod

1. Login ke ACS console. Di panel navigasi kiri, klik Clusters.

2. Di halaman Clusters, klik nama kluster target. Di panel navigasi kiri, pilih Workloads > Pods.

3. Di pojok kiri atas halaman Pods, pilih Namespace pod tersebut. Lalu, klik nama pod target atau klik Details di kolom Actions.

4. Di halaman detail pod, klik tab Logs.

   Catatan

   Kluster Alibaba Cloud Container Service for Kubernetes (ACK) terintegrasi dengan Simple Log Service. Aktifkan Simple Log Service saat membuat kluster untuk mengumpulkan log kontainer, termasuk output standar dan file teks di dalam kontainer. Untuk informasi selengkapnya, lihat Configure application log collection by using pod environment variables.

Periksa data pemantauan pod

1. Login ke ACS console. Di panel navigasi kiri, klik Clusters.

2. Di halaman Clusters, klik nama kluster target. Di panel navigasi kiri, pilih Workloads > Prometheus Monitoring.

3. Di halaman Prometheus Monitoring, klik tab Cluster Overview untuk melihat dashboard pemantauan CPU, memori, dan I/O jaringan pod.

Sambungkan ke kontainer via terminal

1. Login ke ACS console. Di panel navigasi kiri, klik Clusters.

2. Di halaman Clusters, klik nama kluster target. Di panel navigasi kiri, pilih Workloads > Pods.

3. Di halaman Pods, temukan pod target dan klik Terminal di kolom Actions.

   Catatan

   Gunakan terminal untuk memeriksa file lokal dan informasi lain di dalam kontainer.

Diagnosis kegagalan pod

1. Login ke ACS console. Di panel navigasi kiri, klik Clusters.

2. Di halaman Clusters, klik nama kluster target. Di panel navigasi kiri, pilih Workloads > Pods.

3. Di pojok kiri atas halaman Pods, pilih Namespace pod tersebut. Lalu, klik nama pod target atau klik Details di kolom Actions.

4. Di halaman Pods, temukan pod target dan klik Diagnose di kolom Actions.

   Catatan

   Jalankan diagnostik pada pod dan atasi masalah berdasarkan hasilnya. Untuk informasi selengkapnya, lihat Use cluster diagnostics.

Pod berada dalam status Pending

Penyebab

Pod dalam status Pending tidak dapat dijadwalkan, biasanya karena ketergantungan sumber daya atau kuota yang salah konfigurasi.

Gejala

Status pod adalah Pending.

Solusi

Periksa event pod untuk mengidentifikasi mengapa pod tidak dapat dijadwalkan. Penyebab utamanya meliputi:

• Ketergantungan sumber daya

  Pod mungkin bergantung pada sumber daya kluster lain seperti ConfigMap atau persistent volume claim (PVC). Misalnya, persistent volume claim harus terikat ke persistent volume sebelum dapat digunakan oleh pod.

• Kuota yang salah konfigurasi

  Periksa event dan log audit.

Status pod: Init, Error, atau CrashLoopBackOff

Penyebab

• Jika pod terjebak dalam status Init:N/M, artinya pod memiliki M init container, tetapi hanya N yang berhasil dimulai, sehingga M-N container lainnya gagal dimulai.

• Jika pod berada dalam status Init:Error, artinya salah satu init container di dalam pod gagal dimulai.

• Jika pod berada dalam status Init:CrashLoopBackOff, artinya salah satu init container gagal dimulai dan terus-menerus melakukan restart.

Gejala

• Status pod adalah Init:N/M.

• Status pod adalah Init:Error.

• Status pod adalah Init:CrashLoopBackOff.

Solusi

1. Periksa event pod untuk melihat apakah ada masalah pada init container yang belum dimulai. Untuk informasi selengkapnya, lihat Periksa event pod.

2. Periksa log init container yang belum dimulai untuk melakukan troubleshooting. Untuk informasi selengkapnya, lihat Periksa log pod.

3. Periksa konfigurasi pod untuk memverifikasi bahwa konfigurasi init container yang belum dimulai sudah benar. Untuk informasi selengkapnya, lihat Periksa konfigurasi pod. Informasi selengkapnya tentang init container tersedia di Debug Init Containers.

Pod berada dalam status ImagePullBackOff

Penyebab

Pod dalam status ImagePullBackOff telah dijadwalkan tetapi gagal mengambil image kontainernya.

Gejala

Status pod adalah ImagePullBackOff.

Solusi

Periksa deskripsi event pod untuk menemukan nama image yang gagal diambil.

1. Verifikasi bahwa nama image kontainer sudah benar.

2. Jika Anda menggunakan repositori image pribadi, lihat Use an image from an image repository to create an ACK workload untuk solusinya.

Pod berada dalam status CrashLoopBackOff

Penyebab

Status CrashLoopBackOff menunjukkan adanya masalah aplikasi di dalam kontainer.

Gejala

Status pod adalah CrashLoopBackOff.

Solusi

1. Periksa event pod untuk memastikan apakah pod memiliki masalah. Untuk informasi selengkapnya, lihat Periksa event pod.

2. Periksa log pod untuk melakukan troubleshooting. Untuk informasi selengkapnya, lihat Periksa log pod.

3. Periksa konfigurasi pod untuk memverifikasi bahwa konfigurasi pemeriksaan kesehatan kontainer sudah benar. Untuk informasi selengkapnya, lihat Periksa konfigurasi pod. Informasi selengkapnya tentang pemeriksaan kesehatan pod tersedia di Configure Liveness, Readiness, and Startup Probes.

Pod berada dalam status Completed

Penyebab

Pod memasuki status Completed setelah semua proses kontainernya berhenti.

Gejala

Status pod adalah Completed.

Solusi

1. Periksa konfigurasi pod untuk mengidentifikasi perintah startup kontainer di dalam pod. Untuk informasi selengkapnya, lihat Periksa konfigurasi pod.

2. Periksa log pod untuk melakukan troubleshooting. Untuk informasi selengkapnya, lihat Periksa log pod.

Pod dalam status Running tidak berfungsi

Penyebab

File YAML yang digunakan untuk penerapan mengandung kesalahan.

Gejala

Pod berada dalam status Running tetapi tidak berfungsi sebagaimana mestinya.

Solusi

1. Periksa konfigurasi pod untuk memastikan konfigurasi kontainer sesuai harapan Anda. Untuk informasi selengkapnya, lihat Periksa konfigurasi pod.

2. Gunakan metode berikut untuk memeriksa kesalahan penulisan pada kunci variabel lingkungan.

   Contoh berikut menunjukkan cara mengidentifikasi kesalahan penulisan jika command salah ditulis sebagai commnd.

   Catatan

   Saat Anda membuat pod, kluster mengabaikan kesalahan penulisan pada kunci variabel lingkungan. Misalnya, jika Anda salah menulis Command sebagai Commnd, Anda tetap dapat menggunakan file YAML untuk membuat resource tersebut. Namun, saat runtime, kontainer mengabaikan perintah yang salah ketik tersebut dan menjalankan perintah default dari image-nya.

   1. Sebelum menjalankan perintah kubectl apply -f, tambahkan --validate, lalu jalankan perintah kubectl apply --validate -f XXX.yaml.

      Jika Anda salah menulis command sebagai commnd, Anda akan melihat pesan error XXX] unknown field: commnd XXX] this may be a false alarm, see https://gXXXb.XXX/6842pods/test.

   2. Jalankan perintah berikut dan bandingkan file output pod.yaml dengan file asli yang Anda gunakan untuk membuat pod.

        kubectl get pods [$Pod] -o yaml > pod.yaml

      Catatan

      [$Pod] adalah nama pod yang bermasalah. Anda dapat menjalankan perintah kubectl get pods untuk melihat nama pod tersebut.

      • Jika file pod.yaml memiliki beberapa baris tambahan dibandingkan file yang Anda gunakan untuk membuat pod, artinya pod yang dibuat sesuai dengan harapan Anda.

      • Jika satu baris kode dari file asli Anda tidak ada di file pod.yaml, artinya terdapat kesalahan penulisan di file asli Anda.

3. Periksa log pod untuk melakukan troubleshooting. Untuk informasi selengkapnya, lihat Periksa log pod.

4. Akses kontainer melalui terminal untuk memeriksa apakah file lokal di dalamnya sesuai harapan. Untuk informasi selengkapnya, lihat Sambungkan ke kontainer menggunakan terminal.

Pod berada dalam status Terminating

Penyebab

Pod sedang dalam proses dimatikan.

Gejala

Status pod adalah Terminating.

Solusi

Pod dalam status Terminating akan dihapus secara otomatis setelah periode tenggang. Jika pod tetap terjebak, jalankan perintah berikut untuk menghapusnya secara paksa:

kubectl delete pod [$Pod] -n [$namespace] --grace-period=0 --force

Troubleshoot masalah OOM pada pod

Penyebab

Ketika kontainer melebihi batas memorinya, sistem akan menghentikannya dengan event OOM (Out of Memory), menyebabkan keluar secara tak terduga. Informasi selengkapnya tentang event OOM tersedia di Assign Memory Resources to Containers and Pods.

Gejala

• Jika proses yang dihentikan adalah proses blocking, kontainer mungkin melakukan restart secara tak terduga.

• Jika terjadi masalah OOM, di halaman detail pod di konsol, tab Events akan menampilkan event OOM pod was OOM killed.

Solusi

1. Tinjau kurva pertumbuhan memori dalam data pemantauan pod untuk menentukan kapan masalah terjadi. Untuk informasi selengkapnya, lihat Periksa data pemantauan pod.

2. Berdasarkan data pemantauan, garis waktu pertumbuhan memori, log, dan nama proses, periksa apakah proses yang bersangkutan mengalami kebocoran memori.

   • Jika OOM disebabkan oleh kebocoran memori proses, lakukan troubleshooting akar masalah berdasarkan aplikasi Anda.

   • Jika proses berjalan normal, tingkatkan batas memori pod sesuai kebutuhan beban kerja Anda. Kami merekomendasikan agar penggunaan memori aktual pod tidak melebihi 80% dari batas memorinya. Informasi selengkapnya tersedia di Manage pods.