Memecahkan masalah peristiwa CrashLoopBackOff

Halaman ini membantu Anda menyelesaikan masalah pada Pod yang mengalami peristiwa CrashLoopBackOff di Google Kubernetes Engine (GKE).

Halaman ini ditujukan untuk developer Aplikasi yang ingin mengidentifikasi masalah tingkat aplikasi, seperti error konfigurasi atau bug terkait kode, yang menyebabkan penampung mereka error. Fitur ini juga ditujukan untuk Admin dan operator platform yang perlu mengidentifikasi akar masalah tingkat platform untuk restart container, seperti kelelahan sumber daya, gangguan node, atau pemeriksaan keaktifan yang salah dikonfigurasi. Untuk mengetahui informasi selengkapnya tentang peran umum dan contoh tugas yang kami referensikan dalam Trusted Cloud by S3NS konten, lihat Peran dan tugas pengguna GKE umum.

Memahami peristiwa CrashLoopBackOff

Jika Pod Anda macet dalam status CrashLoopBackOff, container di dalamnya akan berulang kali dimulai dan mengalami error atau keluar. CrashLoop ini memicu Kubernetes untuk mencoba memulai ulang container dengan mematuhi restartPolicy-nya. Dengan setiap mulai ulang yang gagal, penundaan BackOff sebelum upaya berikutnya meningkat secara eksponensial (misalnya, 10 dtk, 20 dtk, 40 dtk), hingga maksimum lima menit.

Meskipun peristiwa ini menunjukkan adanya masalah dalam penampung Anda, peristiwa ini juga merupakan sinyal diagnostik yang berharga. Peristiwa CrashLoopBackOff mengonfirmasi bahwa banyak langkah dasar pembuatan Pod, seperti penugasan ke node dan menarik image container, telah selesai. Dengan pengetahuan ini, Anda dapat memfokuskan penyelidikan pada aplikasi atau konfigurasi penampung, bukan infrastruktur cluster.

Status CrashLoopBackOff terjadi karena cara Kubernetes, khususnya kubelet, menangani penghentian container berdasarkan kebijakan mulai ulang Pod. Siklus biasanya mengikuti pola ini:

  1. Penampung dimulai.
  2. Container keluar.
  3. Kubelet mengamati container yang dihentikan dan memulainya ulang sesuai dengan restartPolicy Pod.
  4. Siklus ini berulang, dengan container dimulai ulang setelah penundaan back-off eksponensial yang terus meningkat.

restartPolicy Pod adalah kunci untuk perilaku ini. Kebijakan default, Always, adalah penyebab paling umum dari loop ini karena kebijakan tersebut memulai ulang container jika container keluar karena alasan apa pun, bahkan setelah keluar dengan berhasil. Kebijakan OnFailure lebih kecil kemungkinannya menyebabkan loop karena hanya dimulai ulang pada kode keluar bukan nol, dan kebijakan Never menghindari mulai ulang sepenuhnya.

Mengidentifikasi gejala peristiwa CrashLoopBackOff

Pod dengan status CrashLoopBackOff adalah indikasi utama peristiwa CrashLoopBackOff.

Namun, Anda mungkin mengalami beberapa gejala yang kurang jelas dari peristiwa CrashLoopBackOff:

  • Nol replika yang sehat untuk workload.
  • Penurunan tajam pada replika yang sehat.
  • Workload dengan penskalaan otomatis Pod horizontal yang diaktifkan menskalakan secara lambat atau gagal menskalakan.

Jika workload system (misalnya, agen logging atau metrik) memiliki status CrashLoopBackOff, Anda mungkin juga melihat gejala berikut:

  • Beberapa metrik GKE tidak dilaporkan.
  • Beberapa dasbor dan grafik GKE memiliki kesenjangan.
  • Masalah konektivitas pada jaringan tingkat Pod.

Jika Anda mengamati salah satu gejala yang kurang jelas ini, langkah berikutnya adalah mengonfirmasi apakah peristiwa CrashLoopBackOff terjadi.

Mengonfirmasi peristiwa CrashLoopBackOff

Untuk mengonfirmasi dan menyelidiki peristiwa CrashLoopBackOff, kumpulkan bukti dari peristiwa Kubernetes dan log aplikasi penampung. Kedua sumber ini memberikan pandangan yang berbeda, tetapi saling melengkapi tentang masalah tersebut:

  • Peristiwa Kubernetes mengonfirmasi bahwa Pod mengalami error.
  • Log aplikasi container dapat menunjukkan alasan kegagalan proses di dalam container.

Untuk melihat informasi ini, pilih salah satu opsi berikut:

Konsol

Untuk melihat peristiwa Kubernetes dan log aplikasi, lakukan hal berikut:

  1. Di konsol Trusted Cloud , buka halaman Workloads.

    Buka Workloads

  2. Pilih beban kerja yang ingin Anda selidiki. Tab Ringkasan atau Detail menampilkan informasi selengkapnya tentang status beban kerja.

  3. Dari bagian Managed Pods, klik nama Pod yang bermasalah.

  4. Di halaman detail Pod, selidiki hal berikut:

    • Untuk melihat detail tentang peristiwa Kubernetes, buka tab Events.
    • Untuk melihat log aplikasi container, buka tab Logs. Di halaman ini, Anda dapat menemukan pesan error atau stack trace khusus aplikasi.

kubectl

Untuk melihat peristiwa Kubernetes dan log aplikasi, lakukan hal berikut:

  1. Melihat status semua Pod yang berjalan di cluster Anda:

    kubectl get pods

    Outputnya mirip dengan hal berikut ini:

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

    Pada output, tinjau kolom berikut:

    • Ready: meninjau jumlah container yang siap. Dalam contoh ini, 0/1 menunjukkan bahwa nol dari satu penampung yang diharapkan berada dalam status siap. Nilai ini adalah tanda jelas adanya masalah.
    • Status: mencari Pod dengan status CrashLoopBackOff.
    • Restarts: nilai tinggi menunjukkan bahwa Kubernetes berulang kali mencoba dan gagal memulai container.

  2. Setelah mengidentifikasi Pod yang gagal, deskripsikan Pod tersebut untuk melihat peristiwa tingkat cluster yang terkait dengan status Pod:

    kubectl describe pod POD_NAME -n NAMESPACE_NAME

    Ganti kode berikut:

    • POD_NAME: nama Pod yang Anda identifikasi dalam output perintah kubectl get.
    • NAMESPACE_NAME: namespace Pod.

    Outputnya mirip dengan hal berikut ini:

    Containers:
container-name:
...
  State:          Waiting
    Reason:       CrashLoopBackOff
  Last State:     Terminated
    Reason:       StartError
    Message:      failed to create containerd task: failed to create shim task: context deadline exceeded: unknown
    Exit Code:    128
    Started:      Thu, 01 Jan 1970 00:00:00 +0000
    Finished:     Fri, 27 Jun 2025 16:20:03 +0000
  Ready:          False
  Restart Count:  3459
...
Conditions:
Type                        Status
PodReadyToStartContainers   True
Initialized                 True
Ready                       False
ContainersReady             False
PodScheduled                True
...
Events:
Type     Reason   Age                     From     Message
----     ------   ----                    ----     -------
Warning  Failed   12m (x216 over 25h)     kubelet  Error: context deadline exceeded
Warning  Failed   8m34s (x216 over 25h)   kubelet  Error: context deadline exceeded
Warning  BackOff  4m24s (x3134 over 25h)  kubelet  Back-off restarting failed container container-name in pod failing-pod(11111111-2222-3333-4444-555555555555)

    Dalam output, tinjau kolom berikut untuk melihat tanda-tanda peristiwa CrashLoopBackOff:

    • State: status penampung kemungkinan menunjukkan Waiting dengan alasan CrashLoopBackOff.
    • Last State: status container yang dihentikan sebelumnya. Cari status Terminated dan tinjau kode keluar untuk melihat apakah terjadi error (kode keluar bukan nol) atau keluar berhasil yang tidak terduga (kode keluar nol).
    • Events: tindakan yang dilakukan oleh cluster itu sendiri. Cari pesan tentang container yang dimulai, diikuti dengan kegagalan pemeriksaan keaktifan atau peringatan penundaan seperti Back-off restarting failed container.

  3. Untuk mempelajari lebih lanjut alasan Pod gagal, lihat log aplikasinya:

    kubectl logs POD_NAME --previous

    Flag --previous mengambil log dari penampung yang sebelumnya dihentikan, tempat Anda dapat menemukan pesan error atau stack trace spesifik yang mengungkapkan penyebab error. Penampung saat ini mungkin terlalu baru sehingga belum mencatat log apa pun.

    Pada output, cari error khusus aplikasi yang akan menyebabkan proses keluar. Jika Anda menggunakan aplikasi buatan khusus, developer yang menulisnya adalah orang yang paling tepat untuk menafsirkan pesan error ini. Jika Anda menggunakan aplikasi bawaan, aplikasi ini sering kali memberikan petunjuk pen-debug-an sendiri.

Menggunakan playbook interaktif Crashlooping Pods

Setelah Anda mengonfirmasi peristiwa CrashLoopBackOff, mulailah memecahkan masalah dengan playbook interaktif:

  1. Di konsol Trusted Cloud , buka halaman GKE Interactive Playbook - Crashlooping Pods.

    Buka Pod Crashlooping

  2. Di daftar Cluster, pilih cluster yang ingin Anda pecahkan masalahnya. Jika Anda tidak dapat menemukan cluster, masukkan nama cluster di kolom Filter.

  3. Dalam daftar Namespace, pilih namespace yang ingin Anda pecahkan masalahnya. Jika Anda tidak dapat menemukan namespace, masukkan namespace di kolom Filter.

  4. Pelajari setiap bagian untuk membantu Anda menjawab pertanyaan berikut:

    1. Mengidentifikasi Error Aplikasi: container mana yang dimulai ulang?
    2. Menyelidiki Masalah Kehabisan Memori: apakah ada kesalahan konfigurasi atau error terkait aplikasi?
    3. Menyelidiki Gangguan Node: apakah gangguan pada resource node menyebabkan container dimulai ulang?
    4. Menyelidiki Kegagalan Pemeriksaan Keaktifan: apakah pemeriksaan keaktifan menghentikan container Anda?
    5. Menghubungkan Peristiwa Perubahan: apa yang terjadi sekitar waktu penampung mulai error?

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

Jika masalah berlanjut setelah menggunakan playbook, baca panduan lainnya untuk mengetahui informasi selengkapnya tentang cara menyelesaikan peristiwa CrashLoopBackOff.

Menyelesaikan peristiwa CrashLoopBackOff

Bagian berikut membantu Anda menyelesaikan penyebab paling umum dari peristiwa CrashLoopBackOff:

Mengatasi kehabisan resource

Peristiwa CrashLoopBackOff sering kali disebabkan oleh masalah Kehabisan Memori (OOM). Anda dapat mengonfirmasi apakah ini penyebabnya jika output kubectl describe menampilkan berikut ini:

Last State: Terminated
  Reason: OOMKilled

Untuk mengetahui informasi tentang cara mendiagnosis dan menyelesaikan peristiwa OOM, lihat Memecahkan masalah peristiwa OOM.

Mengatasi kegagalan pemeriksaan keaktifan

Pemeriksaan keaktifan adalah health check berkala yang dilakukan oleh kubelet. Jika pemeriksaan gagal sebanyak beberapa kali (jumlah defaultnya adalah tiga), kubelet akan memulai ulang container, yang berpotensi menyebabkan peristiwa CrashLoopBackOff jika kegagalan pemeriksaan terus berlanjut.

Konfirmasi apakah pemeriksaan keaktifan adalah penyebabnya

Untuk mengonfirmasi apakah kegagalan pemeriksaan keaktifan memicu peristiwa CrashLoopBackOff atau tidak, kueri log kubelet Anda. Log ini sering kali berisi pesan eksplisit yang menunjukkan kegagalan pemeriksaan dan memulai ulang berikutnya.

  1. Di konsol Trusted Cloud , buka halaman Logs Explorer.

    Buka Logs Explorer

  2. Di panel kueri, filter untuk memulai ulang terkait pemeriksaan keaktifan dengan memasukkan kueri berikut:

    resource.type="k8s_node"
log_id("kubelet")
jsonPayload.MESSAGE:"failed liveness probe, will be restarted"
resource.labels.cluster_name="CLUSTER_NAME"

    Ganti CLUSTER_NAME dengan nama cluster Anda.

  3. Tinjau output-nya. Jika kegagalan pemeriksaan keaktifan adalah penyebab peristiwa CrashLoopBackOff Anda, kueri akan menampilkan pesan log yang mirip dengan berikut:

    Container probe failed liveness probe, will be restarted

Setelah Anda mengonfirmasi bahwa pemeriksaan keaktifan adalah penyebab peristiwa CrashLoopBackOff, lanjutkan untuk memecahkan masalah penyebab umum:

Meninjau konfigurasi pemeriksaan keaktifan

Probe yang salah dikonfigurasi sering menjadi penyebab peristiwa CrashLoopBackOff. Periksa setelan berikut dalam manifes probe Anda:

  • Verifikasi jenis probe: konfigurasi probe Anda harus cocok dengan cara aplikasi Anda melaporkan kesehatannya. Misalnya, jika aplikasi Anda memiliki URL health check (seperti /healthz), gunakan jenis probe httpGet. Jika kondisinya ditentukan dengan menjalankan perintah, gunakan jenis pemeriksaan exec. Misalnya, untuk memeriksa apakah port jaringan terbuka dan mendengarkan, gunakan jenis probe tcpSocket.
  • Periksa parameter probe:
    • Jalur (untuk jenis probe httpGet): pastikan jalur HTTP sudah benar dan aplikasi Anda melayani health check di jalur tersebut.
    • Port: verifikasi bahwa port yang dikonfigurasi dalam probe benar-benar digunakan dan diekspos oleh aplikasi.
    • Perintah (untuk jenis probe exec): pastikan perintah ada dalam penampung, menampilkan kode keluar 0 untuk keberhasilan, dan selesai dalam periode timeoutSeconds yang dikonfigurasi.
    • Waktu tunggu: pastikan nilai timeoutSeconds cukup agar aplikasi dapat merespons, terutama saat startup atau dalam beban.
    • Penundaan awal (initialDelaySeconds): periksa apakah penundaan awal cukup bagi aplikasi untuk dimulai sebelum probe dimulai.

Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi Pemeriksaan Keaktifan, Kesiapan, dan Startup di dokumentasi Kubernetes.

Memeriksa pemakaian CPU dan I/O disk

Persaingan resource menyebabkan waktu tunggu habis untuk pemeriksaan, yang merupakan penyebab utama kegagalan pemeriksaan keaktifan. Untuk melihat apakah penggunaan resource menjadi penyebab kegagalan pemeriksaan keaktifan, coba solusi berikut:

  • Analisis penggunaan CPU: pantau penggunaan CPU container yang terpengaruh dan node tempat container tersebut berjalan selama interval pemeriksaan. Metrik utama yang perlu dilacak adalah kubernetes.io/container/cpu/core_usage_time. Penggunaan CPU yang tinggi di container atau node dapat mencegah aplikasi merespons probe tepat waktu.
  • Pantau I/O disk: periksa metrik I/O disk untuk node. Anda dapat menggunakan metrik compute.googleapis.com/guest/disk/operation_time untuk menilai jumlah waktu yang dihabiskan untuk operasi disk, yang dikategorikan menurut baca dan tulis. I/O disk yang tinggi dapat memperlambat startup penampung, inisialisasi aplikasi, atau performa aplikasi secara keseluruhan secara signifikan, sehingga menyebabkan waktu tunggu pemeriksaan habis.

Mengatasi deployment besar

Dalam skenario saat sejumlah besar Pod di-deploy secara bersamaan (misalnya, oleh alat CI/CD seperti ArgoCD), lonjakan tiba-tiba Pod baru dapat membebani resource cluster, sehingga menyebabkan kelelahan resource bidang kontrol. Kurangnya resource ini menunda peluncuran aplikasi dan dapat menyebabkan pemeriksaan keaktifan gagal berulang kali sebelum aplikasi siap.

Untuk mengatasi masalah ini, coba solusi berikut:

  • Terapkan deployment bertahap: Terapkan strategi untuk men-deploy Pod dalam batch atau selama jangka waktu yang lebih lama untuk menghindari kelebihan beban pada resource node.
  • Mengonfigurasi ulang atau menskalakan node: jika deployment bertahap tidak memungkinkan, pertimbangkan untuk mengupgrade node dengan disk yang lebih cepat atau lebih besar, atau Klaim Volume Persisten, untuk menangani peningkatan permintaan I/O dengan lebih baik. Pastikan penskalaan otomatis cluster Anda dikonfigurasi dengan tepat.
  • Tunggu dan amati: Dalam beberapa kasus, jika cluster tidak kekurangan resource secara parah, workload mungkin akhirnya di-deploy setelah penundaan yang signifikan (terkadang 30 menit atau lebih).

Mengatasi error sementara

Aplikasi mungkin mengalami error atau pelambatan sementara selama startup atau inisialisasi yang menyebabkan probe gagal pada awalnya. Jika aplikasi akhirnya pulih, pertimbangkan untuk meningkatkan nilai yang ditentukan di kolom initialDelaySeconds atau failureThreshold dalam manifes pemeriksaan keaktifan Anda.

Mengatasi konsumsi resource probe

Dalam kasus yang jarang terjadi, eksekusi pemeriksaan keaktifan itu sendiri dapat menggunakan resource yang signifikan, yang dapat memicu batasan resource yang berpotensi menyebabkan container dihentikan karena error kehabisan memori (OOM). Pastikan perintah pemeriksaan Anda ringan. Probe ringan lebih cenderung dieksekusi dengan cepat dan andal, sehingga memberikan akurasi yang lebih tinggi dalam melaporkan kondisi sebenarnya aplikasi Anda secara akurat.

Mengatasi kesalahan konfigurasi aplikasi

Kesalahan konfigurasi aplikasi menyebabkan banyak peristiwa CrashLoopBackOff. Untuk memahami alasan aplikasi Anda berhenti, langkah pertama adalah memeriksa kode keluar aplikasi. Kode ini menentukan jalur pemecahan masalah Anda:

  • Kode keluar 0 menunjukkan keluar yang berhasil, yang tidak diharapkan untuk layanan yang berjalan lama dan menunjukkan masalah pada titik entri penampung atau desain aplikasi.
  • Kode keluar non-nol menandakan error aplikasi, yang mengarahkan fokus Anda ke error konfigurasi, masalah dependensi, atau bug dalam kode.

Menemukan kode keluar

Untuk menemukan kode keluar aplikasi Anda, lakukan hal berikut:

  1. Deskripsikan Pod:

    kubectl describe pod POD_NAME -n NAMESPACE_NAME

    Ganti kode berikut:

    • POD_NAME: nama Pod yang bermasalah.
    • NAMESPACE_NAME: namespace Pod.

  2. Pada output, tinjau kolom Exit Code yang terletak di bagian Last State untuk container yang relevan. Jika kode keluar adalah 0, lihat Memecahkan masalah keluar yang berhasil (kode keluar 0). Jika kode keluar adalah angka selain 0, lihat Memecahkan masalah error aplikasi (kode keluar bukan nol).

Memecahkan masalah keluar yang berhasil (exit code 0)

Kode keluar 0 biasanya berarti proses container berhasil diselesaikan. Meskipun ini adalah hasil yang Anda inginkan untuk Job berbasis tugas, hal ini dapat menandakan adanya masalah untuk pengontrol yang berjalan lama seperti Deployment, StatefulSet, atau ReplicaSet.

Pengontrol ini bekerja untuk memastikan Pod selalu berjalan, sehingga mereka memperlakukan setiap keluar sebagai kegagalan yang harus diperbaiki. kubelet menerapkan perilaku ini dengan mematuhi restartPolicy Pod (yang secara default adalah Always), memulai ulang container bahkan setelah keluar dengan berhasil. Tindakan ini membuat loop, yang pada akhirnya memicu status CrashLoopBackOff.

Alasan paling umum untuk keluar berhasil yang tidak terduga adalah sebagai berikut:

  • Perintah penampung tidak memulai proses persisten: penampung tetap berjalan selama proses awalnya (command atau entrypoint) berjalan. Jika proses ini bukan layanan yang berjalan lama, container akan keluar segera setelah perintah selesai. Misalnya, perintah seperti ["/bin/bash"] akan segera keluar karena tidak memiliki skrip untuk dijalankan. Untuk mengatasi masalah ini, pastikan proses awal container Anda memulai proses yang berjalan terus-menerus.

  • Aplikasi pekerja keluar saat antrean tugas kosong: banyak aplikasi pekerja didesain untuk memeriksa antrean tugas dan keluar dengan benar jika antrean kosong. Untuk mengatasinya, Anda dapat menggunakan pengontrol Job (yang dirancang untuk tugas yang berjalan hingga selesai) atau mengubah logika aplikasi agar berjalan sebagai layanan persisten.

  • Aplikasi keluar karena konfigurasi tidak ada atau tidak valid: Aplikasi Anda mungkin keluar segera jika tidak ada petunjuk mulai yang diperlukan, seperti argumen command line, variabel lingkungan, atau file konfigurasi penting.

    Untuk mengatasi masalah ini, periksa terlebih dahulu log aplikasi Anda untuk menemukan pesan error spesifik terkait pemuatan konfigurasi atau parameter yang tidak ada. Kemudian, verifikasi hal berikut:

    • Argumen atau lingkungan aplikasi: pastikan semua argumen command line dan variabel lingkungan yang diperlukan diteruskan dengan benar ke penampung seperti yang diharapkan oleh aplikasi Anda.
    • Keberadaan file konfigurasi: pastikan bahwa semua file konfigurasi yang diperlukan ada di jalur yang diharapkan dalam penampung.
    • Konten file konfigurasi: validasi konten dan format file konfigurasi Anda untuk mengetahui apakah ada error sintaksis, kolom wajib diisi yang tidak ada, atau nilai yang salah.

    Contoh umum masalah ini adalah saat aplikasi dikonfigurasi untuk membaca dari file yang di-mount dengan volume ConfigMap. Jika ConfigMap tidak dilampirkan, kosong, atau memiliki kunci yang salah nama, aplikasi yang dirancang untuk keluar saat konfigurasinya tidak ada dapat berhenti dengan kode keluar 0. Dalam kasus tersebut, verifikasi setelan berikut: - Nama ConfigMap dalam definisi volume Pod Anda cocok dengan nama sebenarnya. - Kunci dalam ConfigMap cocok dengan yang diharapkan aplikasi Anda sebagai nama file dalam volume yang di-mount.

Memecahkan masalah error aplikasi (kode keluar bukan nol)

Jika container keluar dengan kode bukan nol, Kubernetes akan memulainya ulang. Jika masalah mendasar yang menyebabkan error terus berlanjut, aplikasi akan error lagi dan siklus berulang, yang berpuncak pada status CrashLoopBackOff.

Kode keluar non-nol adalah sinyal yang jelas bahwa terjadi error dalam aplikasi itu sendiri, yang mengarahkan upaya penelusuran bug Anda ke cara kerja dan lingkungan internalnya. Masalah berikut sering menyebabkan penghentian ini:

  • Error konfigurasi: kode keluar non-nol sering kali menunjukkan masalah pada konfigurasi aplikasi atau lingkungan tempat aplikasi berjalan. Periksa aplikasi Anda untuk menemukan masalah umum berikut:

    • File konfigurasi tidak ada: aplikasi mungkin tidak dapat menemukan atau mengakses file konfigurasi yang diperlukan.
    • Konfigurasi tidak valid: file konfigurasi mungkin berisi error sintaksis, nilai yang salah, atau setelan yang tidak kompatibel, sehingga menyebabkan aplikasi error.
    • Masalah izin: aplikasi mungkin tidak memiliki izin yang diperlukan untuk membaca atau menulis file konfigurasi.
    • Variabel lingkungan: variabel lingkungan yang salah atau tidak ada dapat menyebabkan aplikasi tidak berfungsi atau gagal dimulai.
    • entrypoint atau command tidak valid: perintah yang ditentukan di kolom entrypoint atau command penampung mungkin salah. Masalah ini dapat terjadi pada image yang baru di-deploy jika jalur ke file yang dapat dieksekusi salah atau file itu sendiri tidak ada di image container. Kesalahan konfigurasi ini sering kali menghasilkan kode keluar 128.

    • Update gambar yang tidak terkontrol (tag :latest): jika gambar beban kerja Anda menggunakan tag :latest, Pod baru dapat menarik versi gambar yang diperbarui yang menyebabkan perubahan yang merusak.

      Untuk membantu memastikan konsistensi dan kemampuan reproduksi, selalu gunakan tag image yang spesifik dan tidak dapat diubah (misalnya, v1.2.3) atau ringkasan SHA (misalnya, sha256:45b23dee08...) di lingkungan produksi. Praktik ini membantu memastikan konten gambar yang sama persis ditarik setiap saat.

  • Masalah dependensi: aplikasi Anda mungkin error jika tidak dapat terhubung ke layanan lain yang menjadi dependensinya, atau jika gagal mengautentikasi atau tidak memiliki izin yang memadai untuk mengaksesnya.

    • Layanan eksternal tidak tersedia: aplikasi mungkin bergantung pada layanan eksternal (misalnya, database atau API) yang tidak dapat dijangkau karena masalah konektivitas jaringan atau gangguan layanan. Untuk memecahkan masalah ini, hubungkan ke Pod. Untuk mengetahui informasi selengkapnya, lihat Men-debug Pod yang Sedang Berjalan dalam dokumentasi Kubernetes.

      Setelah terhubung ke Pod, Anda dapat menjalankan perintah untuk memeriksa akses ke file, database, atau untuk menguji jaringan. Misalnya, Anda dapat menggunakan alat seperti curl untuk mencoba menjangkau URL layanan. Tindakan ini membantu Anda menentukan apakah masalah disebabkan oleh kebijakan jaringan, DNS, atau layanan itu sendiri.

    • Kegagalan autentikasi: aplikasi mungkin tidak dapat melakukan autentikasi dengan layanan eksternal karena kredensial yang salah. Periksa log penampung untuk menemukan pesan seperti 401 Unauthorized (kredensial salah) atau 403 Forbidden (izin tidak memadai), yang sering menunjukkan bahwa akun layanan untuk Pod tidak memiliki peran IAM yang diperlukan untuk melakukan panggilan layanan eksternal Trusted Cloud by S3NS.

      Jika Anda menggunakan GKE Workload Identity Federation, verifikasi bahwa ID utama memiliki izin yang diperlukan untuk tugas tersebut. Untuk mengetahui informasi selengkapnya tentang pemberian peran IAM kepada principal dengan menggunakan GKE Workload Identity Federation, lihat Mengonfigurasi otorisasi dan principal. Anda juga harus memastikan bahwa penggunaan resource Server Metadata GKE tidak melebihi batasnya.

    • Waktu tunggu habis: aplikasi mungkin mengalami waktu tunggu habis saat menunggu respons dari layanan eksternal, sehingga menyebabkan error.

  • Error khusus aplikasi: jika konfigurasi dan dependensi eksternal tampak benar, error mungkin ada dalam kode aplikasi. Periksa log aplikasi untuk error internal umum berikut:

    • Pengecualian yang tidak tertangani: log aplikasi mungkin berisi pelacakan tumpukan atau pesan error yang menunjukkan pengecualian yang tidak tertangani atau bug terkait kode lainnya.
    • Deadlock atau livelock: aplikasi mungkin mengalami deadlock, di mana beberapa proses saling menunggu untuk selesai. Dalam skenario ini, aplikasi mungkin tidak keluar, tetapi berhenti merespons tanpa batas waktu.
    • Konflik port: aplikasi mungkin gagal dimulai jika mencoba mengikat ke port yang sudah digunakan oleh proses lain.
    • Library yang tidak kompatibel: aplikasi mungkin bergantung pada library atau dependensi yang tidak ada atau tidak kompatibel dengan lingkungan runtime.

    Untuk menemukan penyebab utama, periksa log penampung untuk menemukan pesan error atau pelacakan tumpukan tertentu. Informasi ini membantu Anda memutuskan apakah akan memperbaiki kode aplikasi, menyesuaikan batas resource, atau memperbaiki konfigurasi lingkungan. Untuk mengetahui informasi selengkapnya tentang log, lihat Tentang log GKE.

Langkah berikutnya