All Products
Search
Document Center

Container Service for Kubernetes:Troubleshoot pod anomalies

Last Updated:Feb 10, 2026

Panduan komprehensif ini menyediakan pendekatan sistematis untuk mendiagnosis dan menyelesaikan anomali Pod umum di lingkungan Kubernetes, mencakup masalah penjadwalan, kendala gambar (image), kegagalan startup, isu kesiapan (readiness), serta batasan sumber daya.

Panduan referensi cepat

Gunakan referensi cepat ini untuk mengidentifikasi dan menangani masalah Pod umum berdasarkan gejala:

Gejala

Kemungkinan penyebab

Aksi segera

Pending status

Batasan penjadwalan atau ketidakcukupan sumber daya

Periksa sumber daya node dan kebijakan penjadwalan

ImagePullBackOff/ErrImagePull

Masalah konektivitas atau otentikasi ke registri image

Verifikasi image pull secrets dan akses registri

CrashLoopBackOff

Kegagalan startup aplikasi atau kesalahan konfigurasi

Periksa log kontainer dan perintah startup

Running tetapi Ready: False

Kegagalan pemeriksaan kesehatan (health check probe)

Validasi konfigurasi pemeriksaan kesiapan (readiness probe)

OOMKilled

Alokasi memori tidak mencukupi atau kebocoran memori

Sesuaikan batas memori dan periksa penggunaan memori aplikasi

Proses diagnosis sistematis

Ikuti pendekatan terstruktur berikut untuk mengidentifikasi dan menyelesaikan anomali Pod secara sistematis:

Pemecahan Masalah Alur Kerja

image

Fase 1: Penilaian awal

  1. Periksa status Pod menggunakan Konsol atau kubectl:

    kubectl get pods -n <namespace>
  2. Periksa event Pod untuk pesan kesalahan:

    kubectl describe pod <pod-name> -n <namespace>
  3. Tinjau log kontainer untuk kesalahan tingkat aplikasi:

    kubectl logs <pod-name> -n <namespace> --previous

Fase 2: Masalah penjadwalan

Pod terjebak dalam status Pending

Jika Pod tetap berada dalam status Pending, selidiki batasan penjadwalan dan ketersediaan sumber daya.

Pesan kesalahan

Akar penyebab

Langkah penyelesaian

no nodes available to schedule pods

Tidak ada node sehat yang tersedia di kluster

  1. Periksa status kesehatan node

  2. Verifikasi kapasitas kelompok node

  3. Tinjau batasan penjadwalan (nodeSelector, affinity)

Insufficient cpu
Insufficient memory

Permintaan sumber daya melebihi kapasitas node

  1. Periksa tingkat alokasi permintaan sumber daya node

  2. Optimalkan permintaan sumber daya workload

  3. Lakukan scale out kelompok node jika diperlukan

didn't match Pod's node affinity/selector

Ketidaksesuaian label node dengan persyaratan penjadwalan Pod

  1. Verifikasi bahwa label node sesuai dengan persyaratan Pod

  2. Sesuaikan kebijakan penjadwalan workload

  3. Perbarui label node jika sesuai

Strategi optimasi sumber daya

Manajemen sumber daya yang efektif mencegah masalah penjadwalan dan mengoptimalkan pemanfaatan kluster.

Optimasi berbasis Konsol

  1. Buka halaman manajemen node kluster

  2. Tinjau tingkat alokasi permintaan CPU/Memori

  3. Identifikasi workload yang kurang dimanfaatkan untuk rightsizing

  4. Aktifkan Auto Scaling (HPA) untuk penyesuaian replika dinamis

Optimasi berbasis command-line

# Lihat pemanfaatan sumber daya node
kubectl top nodes

# Periksa permintaan sumber daya Pod
kubectl describe pod <pod-name> -n <namespace> | grep -A 10 "Resources:"

# Aktifkan profiling sumber daya untuk rekomendasi
# (Fitur Konsol untuk optimasi sumber daya otomatis)

Fase 3: Kegagalan pull image

Kesalahan pull image umum

Jenis kesalahan

Penyebab

Solusi

ErrImagePull

Masalah konektivitas jaringan ke registri image

Uji konektivitas registri dari node

ImagePullBackOff

Kegagalan otentikasi atau kredensial tidak tersedia

Verifikasi konfigurasi imagePullSecrets

ErrImageNeverPull

Image tidak ditemukan secara lokal dengan kebijakan PullNever

Ubah kebijakan pull atau pastikan ketersediaan image

Langkah-langkah pemecahan masalah image pull

  1. Verifikasi keakuratan URL dan tag repository image

  2. Periksa apakah imagePullSecrets tersedia dan dirujuk dengan benar

  3. Uji konektivitas registri dari node pekerja:

    crictl pull <registry-address>/<image>:<tag>
    curl -v https://<registry-address>
  4. Validasi kredensial otentikasi registri

  5. Periksa kebijakan jaringan yang mengizinkan akses registri

Fase 4: Masalah startup aplikasi

Analisis CrashLoopBackOff

Crash kontainer berulang menunjukkan adanya masalah mendasar pada aplikasi atau konfigurasi.

Pendekatan investigasi

  1. Periksa log kontainer sebelumnya untuk mengetahui alasan crash:

    kubectl logs <pod-name> --previous -n <namespace>
  2. Periksa perintah dan argumen startup kontainer

  3. Verifikasi variabel lingkungan dan konfigurasi

  4. Validasi dependensi dan layanan yang dibutuhkan

  5. Tinjau konfigurasi pemeriksaan kesehatan aplikasi

Penyebab crash umum

  • Perintah startup tidak tersedia atau salah

  • Kesalahan file konfigurasi atau file tidak tersedia

  • Layanan dependensi tidak tersedia

  • Izin tidak mencukupi atau batasan keamanan

  • Konflik port atau kegagalan binding

  • Pelanggaran batas sumber daya saat startup

Fase 5: Masalah pemeriksaan kesiapan dan kesehatan

Pod berstatus Running tetapi tidak siap (Ready: False)

Jika Pod menunjukkan status Running tetapi gagal pada pemeriksaan kesiapan, selidiki konfigurasi pemeriksaan kesehatan.

Daftar validasi

  • Verifikasi titik akhir pemeriksaan kesiapan tersedia dan merespons dengan benar

  • Konfirmasi pengaturan timeout dan ambang batas kegagalan probe

  • Periksa konektivitas jaringan ke titik akhir probe

  • Validasi bahwa port probe sesuai dengan port yang didengarkan aplikasi

  • Pastikan path probe sesuai dengan entri rute aplikasi

Solusi sementara

Nonaktifkan sementara pemeriksaan kesiapan untuk mengizinkan trafik selama investigasi:

  1. Akses terminal Pod melalui Konsol atau gunakan kubectl exec

  2. Uji secara manual titik akhir kesehatan menggunakan perintah curl atau wget

  3. Verifikasi bahwa aplikasi berfungsi dengan benar tanpa pemeriksaan kesiapan

  4. Kumpulkan metrik dan log untuk memahami akar penyebab

  5. Sesuaikan konfigurasi pemeriksaan kesiapan berdasarkan temuan Anda

  6. Aktifkan kembali pemeriksaan kesiapan setelah masalah terselesaikan

Catatan

Solusi sementara ini hanya boleh digunakan untuk tujuan investigasi. Selalu aktifkan kembali pemeriksaan kesiapan di lingkungan produksi.

Fase 6: Masalah sumber daya dan memori

Analisis status OOMKilled

Kondisi kehabisan memori menyebabkan terminasi Pod dan memerlukan manajemen sumber daya yang cermat.

Langkah investigasi

  1. Tinjau log OOM kill:

    kubectl logs <pod-name> --previous -n <namespace> | grep -i oom
  2. Analisis pola dan lonjakan penggunaan memori

  3. Periksa kebocoran memori pada kode aplikasi

  4. Tinjau pengaturan heap JVM untuk aplikasi Java (parameter -Xmx)

  5. Validasi batas sumber daya memori terhadap penggunaan aktual

Optimasi memori

  • Tingkatkan batas memori jika aplikasi benar-benar membutuhkan lebih banyak RAM

  • Terapkan profiling memori untuk mengidentifikasi pola penggunaan

  • Optimalkan alokasi memori aplikasi dan pengumpulan sampah

  • Pertimbangkan vertical pod autoscaling untuk penyesuaian memori dinamis

  • Tetapkan permintaan memori yang sesuai untuk menjamin kualitas layanan

Pertanyaan umum

Pod berjalan tetapi tidak berfungsi dengan benar

Masalah konfigurasi aplikasi dapat menyebabkan Pod berjalan tanpa berfungsi sebagaimana mestinya.

  1. Verifikasi konfigurasi kontainer sesuai ekspektasi

  2. Periksa kesalahan sintaks konfigurasi YAML

  3. Validasi nilai variabel lingkungan dan rahasia

  4. Konfirmasi penemuan layanan dan resolusi DNS

  5. Uji komunikasi antar-kontainer jika berlaku

Memahami status Completed

Pod yang memasuki status Completed adalah hal normal untuk workload tertentu seperti Job dan init container ketika prosesnya berhasil keluar.

Antarmuka troubleshooting umum

Akses antarmuka berikut melalui Container Service Management Console untuk troubleshooting Pod yang komprehensif:

Operasi

Antarmuka Konsol

Lihat status dan informasi dasar Pod

Cluster > Workloads > Pods

Periksa konfigurasi Pod

Halaman Pod details > tab Configuration

Tinjau event Pod

Halaman Pod details > tab Events

Akses log kontainer

Halaman Pod details > tab Logs

Sambungkan ke terminal kontainer

Halaman Pod details > Terminal access

Aktifkan diagnostik Pod

Halaman Pod details > Diagnostics tools