Menyatukan semuanya: Contoh skenario pemecahan masalah

Memahami alat pemecahan masalah individual untuk Google Kubernetes Engine (GKE) memang bermanfaat, tetapi melihat alat tersebut digunakan bersama-sama 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 penyebab error OutOfMemory (OOMKilled).

Contoh ini bermanfaat bagi siapa saja 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 notifikasi 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 beban kerja product-catalog.

Konfirmasi masalah di konsol Google Cloud

Anda memulai dengan melihat workload secara umum untuk mengonfirmasi masalah tersebut.

  1. Di konsol Google Cloud , Anda membuka halaman Workloads dan memfilter workload product-catalog Anda.
  2. Anda melihat kolom status Pods. Daripada 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 menampilkan 14, jumlah 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 berulang kali dimulai ulang, Anda perlu mencari tahu penyebabnya. Perintah kubectl describe adalah alat yang tepat untuk melakukannya.

  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 menjelaskan Pod yang tidak stabil untuk mendapatkan histori peristiwa 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 penampung dihentikan dengan Reason: OOMKilled, yang memberi tahu Anda bahwa penampung 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 container 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 meningkat secara stabil, lalu tiba-tiba turun menjadi nol saat container dihentikan karena kehabisan memori 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 masalahnya, gunakan Logs Explorer.

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

  2. Anda menulis kueri untuk memfilter log penampung tertentu dari tepat sebelum waktu 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. Dalam 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 penampung.

Temuan

Dengan menggunakan alat ini secara bersamaan, 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 terjadinya mulai 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