Merangkai semuanya: Contoh skenario pemecahan masalah

Memahami alat pemecahan masalah individual untuk Google Kubernetes Engine (GKE) memang berguna, tetapi melihat alat tersebut digunakan bersama untuk memecahkan masalah di dunia nyata dapat membantu memantapkan pengetahuan Anda.

Ikuti contoh terpandu yang menggabungkan penggunaan konsol Google Cloud , alat command line kubectl, Cloud Logging, dan Cloud Monitoring secara bersamaan untuk mengidentifikasi akar masalah error OutOfMemory (OOMKilled).

Contoh ini bermanfaat bagi siapa pun yang ingin melihat penerapan praktis dari teknik pemecahan masalah yang dijelaskan dalam seri ini, terutama Admin dan operator platform serta Developer aplikasi. Untuk mengetahui informasi selengkapnya tentang peran umum dan contoh tugas yang kami referensikan dalam kontenGoogle Cloud , lihat Peran dan tugas pengguna GKE umum.

Skenario

Anda adalah engineer yang bertugas untuk aplikasi web bernama product-catalog yang berjalan di GKE.

Investigasi Anda dimulai saat Anda menerima pemberitahuan otomatis dari Cloud Monitoring:

Alert: High memory utilization for container 'product-catalog' in 'prod' cluster.

Pemberitahuan ini memberi tahu Anda bahwa ada masalah dan menunjukkan bahwa masalah tersebut terkait dengan workload product-catalog.

Konfirmasi masalah di konsol Google Cloud

Anda memulai dengan tampilan tingkat tinggi workload untuk mengonfirmasi masalah.

  1. Di konsol Google Cloud , Anda membuka halaman Workloads dan memfilter workload product-catalog Anda.
  2. Anda melihat kolom status Pod. Alih-alih 3/3 yang responsif, Anda melihat nilai yang terus-menerus menunjukkan status tidak responsif: 2/3. Nilai ini memberi tahu Anda bahwa salah satu Pod aplikasi Anda tidak memiliki status Ready.
  3. Anda ingin menyelidiki lebih lanjut, jadi Anda mengklik nama workload product-catalog untuk membuka halaman detailnya.
  4. Di halaman detail, Anda dapat melihat bagian Managed Pods. Anda segera mengidentifikasi masalah: kolom Restarts untuk Pod Anda menunjukkan 14, angka yang sangat tinggi.

Jumlah mulai ulang yang tinggi ini mengonfirmasi bahwa masalah menyebabkan ketidakstabilan aplikasi, dan menunjukkan bahwa container gagal dalam health check atau mengalami error.

Menemukan alasan dengan perintah kubectl

Sekarang setelah mengetahui bahwa aplikasi Anda terus dimulai ulang, Anda perlu mencari tahu penyebabnya. Perintah kubectl describe adalah alat yang tepat untuk melakukan hal ini.

  1. Anda mendapatkan nama persis Pod yang tidak stabil:

    kubectl get pods -n prod

    Outputnya adalah sebagai berikut:

    NAME                             READY  STATUS            RESTARTS  AGE
product-catalog-d84857dcf-g7v2x  0/1    CrashLoopBackOff  14        25m
product-catalog-d84857dcf-lq8m4  1/1    Running           0         2h30m
product-catalog-d84857dcf-wz9p1  1/1    Running           0         2h30m

  2. Anda mendeskripsikan Pod yang tidak stabil untuk mendapatkan histori peristiwa yang mendetail:

    kubectl describe pod product-catalog-d84857dcf-g7v2x -n prod

  3. Anda meninjau output dan menemukan petunjuk di bagian Last State dan Events:

    Containers:
  product-catalog-api:
    ...
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       OOMKilled
      Exit Code:    137
      Started:      Mon, 23 Jun 2025 10:50:15 -0700
      Finished:     Mon, 23 Jun 2025 10:54:58 -0700
    Ready:          False
    Restart Count:  14
...
Events:
  Type     Reason     Age                           From                Message
  ----     ------     ----                          ----                -------
  Normal   Scheduled  25m                           default-scheduler   Successfully assigned prod/product-catalog-d84857dcf-g7v2x to gke-cs-cluster-default-pool-8b8a777f-224a
  Normal   Pulled     8m (x14 over 25m)             kubelet             Container image "us-central1-docker.pkg.dev/my-project/product-catalog/api:v1.2" already present on machine
  Normal   Created    8m (x14 over 25m)             kubelet             Created container product-catalog-api
  Normal   Started    8m (x14 over 25m)             kubelet             Started container product-catalog-api
  Warning  BackOff    3m (x68 over 22m)             kubelet             Back-off restarting failed container

    Output memberikan dua petunjuk penting:

    • Pertama, bagian Last State menunjukkan bahwa container dihentikan dengan Reason: OOMKilled, yang memberi tahu Anda bahwa container kehabisan memori. Alasan ini dikonfirmasi oleh Exit Code: 137, yang merupakan kode keluar Linux standar untuk proses yang telah dihentikan karena konsumsi memori yang berlebihan.
    • Kedua, bagian Events menampilkan peristiwa Warning: BackOff dengan pesan Back-off restarting failed container. Pesan ini mengonfirmasi bahwa penampung berada dalam loop kegagalan, yang merupakan penyebab langsung dari status CrashLoopBackOff yang Anda lihat sebelumnya.

Memvisualisasikan perilaku dengan metrik

Perintah kubectl describe memberi tahu Anda apa yang terjadi, tetapi Cloud Monitoring dapat menunjukkan perilaku lingkungan Anda dari waktu ke waktu.

  1. Di konsol Google Cloud , Anda membuka Metrics Explorer.
  2. Anda memilih metrik container/memory/used_bytes.
  3. Anda memfilter output ke cluster, namespace, dan nama Pod tertentu.

Diagram menunjukkan pola yang berbeda: penggunaan memori terus meningkat, lalu tiba-tiba turun ke nol saat container dihentikan karena OOM dan dimulai ulang. Bukti visual ini mengonfirmasi kebocoran memori atau batas memori yang tidak memadai.

Menemukan akar masalah dalam log

Sekarang Anda tahu bahwa container kehabisan memori, tetapi Anda masih belum tahu persisnya mengapa. Untuk menemukan akar masalah, gunakan Logs Explorer.

  1. Di konsol Google Cloud , Anda membuka Logs Explorer.

  2. Tulis kueri untuk memfilter log container tertentu dari waktu tepat sebelum error terakhir (yang Anda lihat di output perintah kubectl describe):

    resource.type="k8s_container"
resource.labels.cluster_name="example-cluster"
resource.labels.namespace_name="prod"
resource.labels.pod_name="product-catalog-d84857dcf-g7v2x"
timestamp >= "2025-06-23T17:50:00Z"
timestamp < "2025-06-23T17:55:00Z"

  3. Di log, Anda menemukan pola pesan yang berulang tepat sebelum setiap error:

    {
  "message": "Processing large image file product-image-large.jpg",
  "severity": "INFO"
},
{
  "message": "WARN: Memory cache size now at 248MB, nearing limit.",
  "severity": "WARNING"
}

Entri log ini memberi tahu Anda bahwa aplikasi mencoba memproses file gambar besar dengan memuatnya sepenuhnya ke dalam memori, yang pada akhirnya menghabiskan batas memori container.

Temuan

Dengan menggunakan alat ini bersama-sama, Anda akan mendapatkan gambaran lengkap tentang masalah tersebut:

  • Pemberitahuan pemantauan memberi tahu Anda bahwa ada masalah.
  • Konsol Google Cloud menunjukkan bahwa masalah tersebut memengaruhi pengguna (mulai ulang).
  • Perintah kubectl menunjukkan alasan pasti untuk memulai ulang (OOMKilled).
  • Metrics Explorer memvisualisasikan pola kebocoran memori dari waktu ke waktu.
  • Logs Explorer mengungkapkan perilaku spesifik yang menyebabkan masalah memori.

Sekarang Anda siap menerapkan solusi. Anda dapat mengoptimalkan kode aplikasi untuk menangani file besar secara lebih efisien atau, sebagai perbaikan jangka pendek, meningkatkan batas memori penampung (khususnya, nilai spec.containers.resources.limits.memory) dalam manifes YAML beban kerja.

Langkah berikutnya