Pengantar pemecahan masalah GKE

Halaman ini memperkenalkan teknik pemecahan masalah mendasar untuk Google Kubernetes Engine (GKE). Halaman ini ditujukan bagi pengguna baru Kubernetes dan GKE yang ingin mempelajari praktik pemecahan masalah yang efektif.

Halaman ini memberikan ringkasan alat dan teknik berikut untuk memantau, mendiagnosis, dan menyelesaikan masalah pada GKE:

• Tinjau kesehatan cluster dan beban kerja di konsol Google Cloud : dapatkan ringkasan tingkat tinggi untuk mengidentifikasi potensi masalah dengan cepat pada cluster dan aplikasi Anda.
• Selidiki status cluster dengan alat command line kubectl: gunakan perintah ini untuk melihat status aktif resource seperti node dan Pod.
• Lakukan analisis historis dengan Cloud Logging: kueri data log historis dan periksa peristiwa untuk mengidentifikasi penyebab utama kegagalan.
• Lakukan pemantauan proaktif dengan Cloud Monitoring: lacak metrik performa dari waktu ke waktu, visualisasikan tren, dan buat pemberitahuan untuk mendeteksi dan merespons masalah sebelum memengaruhi pengguna.
• Mempercepat diagnosis dengan Gemini Cloud Assist: menganalisis pesan error yang kompleks, mendapatkan panduan pemecahan masalah langkah demi langkah, dan menyelidiki masalah secara otomatis.
• Menggabungkan semuanya: Contoh skenario pemecahan masalah: lihat cara menggunakan alat ini bersama-sama dalam panduan langkah demi langkah untuk mendiagnosis dan menyelesaikan kegagalan aplikasi umum di dunia nyata.

Memahami konsep inti

Jika Anda baru menggunakan Kubernetes dan GKE, memahami konsep inti, seperti arsitektur cluster dan hubungan antara Pod dan node, sangat penting sebelum Anda mulai memecahkan masalah. Jika Anda ingin mempelajari lebih lanjut, lihat Mulai mempelajari GKE.

Sebaiknya pahami juga bagian GKE yang menjadi tanggung jawab Anda untuk dipelihara dan bagian yang menjadi tanggung jawab Google untuk dipelihara. Google Cloud Untuk mengetahui informasi selengkapnya, lihat Tanggung jawab bersama GKE.

Meninjau kesehatan cluster dan workload di konsol Google Cloud

Konsol Google Cloud adalah titik awal yang baik untuk memecahkan masalah karena memberikan tampilan cepat tentang kondisi cluster dan beban kerja Anda. Kondisi cluster mengacu pada kondisi infrastruktur GKE yang mendasarinya seperti node dan jaringan, sedangkan kondisi workload mengacu pada status dan performa aplikasi Anda yang berjalan di cluster.

Bagian berikut menjelaskan halaman cluster dan workload. Untuk memberikan gambaran lengkap tentang kesehatan aplikasi Anda, Google Cloud konsol juga memberi Anda akses ke alat pemantauan dan pencatatan log yang canggih, sehingga Anda dapat menyelidiki penyebab utama kegagalan di masa lalu dan mencegahnya secara proaktif di masa mendatang. Untuk mengetahui informasi selengkapnya tentang alat ini, lihat bagian Melakukan analisis historis dengan Cloud Logging dan Melakukan pemantauan proaktif dengan Cloud Monitoring.

Menemukan masalah cluster

Halaman Kubernetes clusters memberi Anda ringkasan performa cluster Anda. Untuk mengidentifikasi masalah pada cluster Anda, mulai di halaman ini.

• Untuk memulai, di Google Cloud konsol, buka halaman Kubernetes clusters.

  Buka cluster Kubernetes

Berikut beberapa contoh cara menggunakan halaman ini untuk memecahkan masalah:

• Untuk mendapatkan saran tentang cara meningkatkan kualitas cluster, strategi upgrade, dan pengoptimalan biaya, klik Lihat rekomendasi.
• Untuk mengidentifikasi cluster yang tidak responsif, tinjau kolom Status. Klaster yang tidak memiliki tanda centang hijau perlu diperhatikan.
• Untuk melihat potensi masalah, tinjau kolom Notifikasi. Klik pesan notifikasi untuk mengetahui informasi selengkapnya.

Menyelidiki cluster tertentu

Setelah Anda menemukan masalah pada cluster, pelajari halaman Detail cluster untuk mendapatkan informasi mendalam yang membantu Anda memecahkan masalah cluster dan memahami konfigurasinya.

Untuk membuka halaman Detail cluster, lakukan langkah berikut:

1. Buka halaman cluster Kubernetes.

   Buka cluster Kubernetes

2. Tinjau kolom Nama dan klik nama cluster yang ingin Anda selidiki.

Berikut beberapa contoh cara menggunakan halaman Details cluster untuk memecahkan masalah cluster Anda:

• Untuk pemeriksaan kesehatan umum, coba opsi berikut:

  • Untuk melihat dasbor tingkat cluster, buka tab Observability. Secara default, GKE mengaktifkan Cloud Monitoring saat Anda membuat cluster. Jika Cloud Monitoring diaktifkan, GKE akan otomatis menyiapkan dasbor di halaman ini. Berikut beberapa tampilan yang mungkin paling berguna untuk pemecahan masalah:

    • Ringkasan: lihat ringkasan umum tentang performa, pemanfaatan resource, dan peristiwa utama cluster Anda. Dasbor ini membantu Anda menilai kondisi keseluruhan cluster dengan cepat dan mengidentifikasi potensi masalah.
    • Metrik traffic: melihat metrik jaringan berbasis node untuk mendapatkan insight tentang traffic antara beban kerja Kubernetes Anda.
    • Status workload: melihat status Deployment, Pod, dan container. Identifikasi instance yang gagal atau tidak responsif, dan deteksi batasan resource.

    • Bidang kontrol: melihat kesehatan dan performa bidang kontrol. Dasbor ini memungkinkan Anda memantau metrik utama komponen seperti kube-apiserver dan etcd, mengidentifikasi hambatan performa, dan mendeteksi kegagalan komponen.

  • Untuk melihat error aplikasi terbaru, buka tab Error aplikasi. Informasi di tab ini dapat membantu Anda memprioritaskan dan menyelesaikan error dengan menunjukkan jumlah kemunculan, kapan error pertama kali muncul, dan kapan terakhir kali terjadi.

    Untuk menyelidiki error lebih lanjut, klik pesan error untuk melihat laporan error mendetail, termasuk link ke log yang relevan.

• Jika Anda memecahkan masalah setelah upgrade atau perubahan terbaru, periksa bagian Dasar-dasar cluster di tab Detail cluster. Pastikan bahwa versi yang tercantum di kolom Versi adalah versi yang Anda harapkan. Untuk penyelidikan lebih lanjut, klik Tampilkan histori upgrade di bagian Upgrade.

• Jika Anda menggunakan cluster Standard dan Pod Anda macet dalam status Pending, atau Anda mencurigai bahwa node kelebihan beban, periksa tab Nodes. Tab Nodes tidak tersedia untuk cluster Autopilot karena GKE mengelola node untuk Anda.

  • Di bagian Node Pools, periksa apakah penskalaan otomatis dikonfigurasi dengan benar dan jenis mesin sesuai untuk beban kerja Anda.
  • Di bagian Node, cari node dengan status selain Ready. Status NotReady menunjukkan masalah pada node itu sendiri, seperti tekanan resource atau masalah pada kubelet (kubelet adalah agen yang berjalan di setiap node untuk mengelola container).

Menemukan masalah workload

Jika Anda mencurigai adanya masalah pada aplikasi tertentu, seperti Deployment gagal, buka halaman Workloads di konsol Google Cloud . Halaman ini memberikan tampilan terpusat dari semua aplikasi yang berjalan dalam cluster Anda.

• Untuk memulai, di konsol Google Cloud , buka halaman Workloads.

  Buka Workloads

Berikut beberapa contoh cara menggunakan halaman ini untuk memecahkan masalah:

• Untuk mengidentifikasi workload yang tidak responsif, tinjau kolom Status. Setiap workload yang tidak memiliki tanda centang hijau perlu diperhatikan.
• Jika aplikasi tidak merespons, tinjau kolom Pod. Misalnya, status seperti 1/3 berarti hanya satu dari tiga replika aplikasi yang berjalan, yang menunjukkan adanya masalah.

Menyelidiki workload tertentu

Setelah mengidentifikasi beban kerja yang bermasalah dari ringkasan, buka halaman Detail beban kerja untuk mulai mengisolasi penyebab utamanya.

Untuk membuka halaman Detail workload, lakukan hal berikut:

1. Buka halaman Workloads.

   Buka Workloads

2. Lihat kolom Nama dan klik nama workload yang ingin Anda selidiki.

Berikut beberapa contoh cara menggunakan halaman Detail workload untuk memecahkan masalah workload Anda:

• Untuk memeriksa konfigurasi workload, gunakan tab Overview dan Details workload. Anda dapat menggunakan informasi ini untuk memverifikasi peristiwa seperti apakah tag image container yang benar telah di-deploy atau memeriksa permintaan dan batas resource beban kerja.

• Untuk menemukan nama Pod tertentu yang mengalami error, buka bagian Managed Pods. Anda mungkin memerlukan informasi ini untuk perintah kubectl. Bagian ini mencantumkan semua Pod yang dikontrol oleh workload, beserta statusnya. Untuk melihat histori perubahan terbaru pada workload, buka tab Histori revisi. Jika Anda melihat masalah performa setelah penerapan baru, gunakan bagian ini untuk mengidentifikasi revisi mana yang aktif. Kemudian, Anda dapat membandingkan konfigurasi revisi saat ini dengan revisi sebelumnya untuk menentukan sumber masalah. Jika tab ini tidak terlihat, beban kerja adalah jenis yang tidak menggunakan revisi atau belum memiliki update apa pun.

• Jika Deployment tampaknya gagal, buka tab Events. Halaman ini sering kali menjadi sumber informasi yang paling berharga karena menampilkan peristiwa tingkat Kubernetes.

• Untuk melihat log aplikasi, klik tab Log. Halaman ini membantu Anda memahami apa yang terjadi di dalam cluster Anda. Lihat di sini untuk menemukan pesan error dan stack trace yang dapat membantu Anda mendiagnosis masalah.

• Untuk mengonfirmasi apa yang di-deploy, lihat tab YAML. Halaman ini menampilkan manifes YAML langsung untuk workload sebagaimana adanya di cluster. Informasi ini berguna untuk menemukan perbedaan dari manifes yang dikontrol sumber Anda. Jika Anda melihat manifes YAML satu Pod, tab ini juga menampilkan status Pod, yang memberikan insight tentang kegagalan tingkat Pod.

Menyelidiki status cluster dengan alat command line kubectl

Meskipun konsol Google Cloud membantu Anda memahami apakah ada masalah, alat command line kubectl sangat penting untuk mengetahui mengapa. Dengan berkomunikasi langsung dengan bidang kontrol Kubernetes, alat command line kubectl memungkinkan Anda mengumpulkan informasi mendetail yang diperlukan untuk memecahkan masalah lingkungan GKE Anda.

Bagian berikut memperkenalkan beberapa perintah penting yang merupakan titik awal yang efektif untuk pemecahan masalah GKE.

Sebelum memulai

Sebelum memulai, lakukan tugas berikut:

• Instal kubectl.

• Konfigurasi alat command line kubectl untuk berkomunikasi dengan cluster Anda:

  gcloud container clusters get-credentials CLUSTER_NAME \
      --location=LOCATION
  

  Ganti kode berikut:

  • CLUSTER_NAME: nama cluster Anda.
  • LOCATION: lokasi Compute Engine bidang kontrol cluster Anda. Berikan region untuk cluster regional, atau zona untuk cluster zonal.

• Tinjau izin Anda. Untuk melihat apakah Anda memiliki izin yang diperlukan untuk menjalankan perintah kubectl, gunakan perintah kubectl auth can-i. Misalnya, untuk melihat apakah Anda memiliki izin untuk menjalankan kubectl get nodes, jalankan perintah kubectl auth can-i get nodes.

  Jika Anda memiliki izin yang diperlukan, perintah akan menampilkan yes; jika tidak, perintah akan menampilkan no.

  Jika tidak memiliki izin untuk menjalankan perintah kubectl, Anda mungkin melihat pesan error yang mirip dengan berikut:

  Error from server (Forbidden): pods "POD_NAME" is forbidden: User
  "USERNAME@DOMAIN.com" cannot list resource "pods" in API group "" in the
  namespace "default"
  

  Jika Anda tidak memiliki izin yang diperlukan, minta administrator cluster Anda untuk menetapkan peran yang diperlukan kepada Anda.

Mendapatkan ringkasan tentang apa yang sedang berjalan

Perintah kubectl get membantu Anda melihat gambaran umum tentang apa yang terjadi di cluster Anda. Gunakan perintah berikut untuk melihat status dua komponen cluster yang paling penting, yaitu node dan Pod:

1. Untuk memeriksa apakah node Anda dalam kondisi baik, lihat detail tentang semua node dan statusnya:

   kubectl get nodes
   

   Outputnya mirip dengan hal berikut ini:

   NAME                                        STATUS   ROLES    AGE     VERSION
   
   gke-cs-cluster-default-pool-8b8a777f-224a   Ready    <none>   4d23h   v1.32.3-gke.1785003
   gke-cs-cluster-default-pool-8b8a777f-egb2   Ready    <none>   4d22h   v1.32.3-gke.1785003
   gke-cs-cluster-default-pool-8b8a777f-p5bn   Ready    <none>   4d22h   v1.32.3-gke.1785003
   

   Status selain Ready memerlukan penyelidikan tambahan.

2. Untuk memeriksa apakah Pod Anda dalam kondisi baik, lihat detail tentang semua Pod dan statusnya:

   kubectl get pods --all-namespaces
   

   Outputnya mirip dengan hal berikut ini:

   NAMESPACE   NAME       READY   STATUS      RESTARTS   AGE
   kube-system netd-6nbsq 3/3     Running     0          4d23h
   kube-system netd-g7tpl 3/3     Running     0          4d23h
   

   Status selain Running memerlukan penyelidikan tambahan. Berikut beberapa status umum yang mungkin Anda lihat:

   • Running: status berjalan yang sehat.
   • Pending: Pod menunggu untuk dijadwalkan pada node.
   • CrashLoopBackOff: container dalam Pod berulang kali error dalam loop karena aplikasi dimulai, keluar dengan error, dan kemudian dimulai ulang oleh Kubernetes.
   • ImagePullBackOff: Pod tidak dapat menarik image container.

Perintah sebelumnya hanyalah dua contoh cara Anda dapat menggunakan perintah kubectl get. Anda juga dapat menggunakan perintah ini untuk mempelajari lebih lanjut berbagai jenis resource Kubernetes. Untuk mengetahui daftar lengkap resource yang dapat Anda jelajahi, lihat kubectl get dalam dokumentasi Kubernetes.

Mempelajari resource tertentu lebih lanjut

Setelah mengidentifikasi masalah, Anda perlu mendapatkan detail selengkapnya. Contoh masalahnya adalah Pod yang tidak memiliki status Running. Untuk mendapatkan detail selengkapnya, gunakan perintah kubectl describe.

Misalnya, untuk mendeskripsikan Pod tertentu, jalankan perintah berikut:

kubectl describe pod POD_NAME -n NAMESPACE_NAME

Ganti kode berikut:

• POD_NAME: nama Pod yang mengalami masalah.
• NAMESPACE_NAME: namespace tempat Pod berada. Jika Anda tidak yakin dengan namespace-nya, tinjau kolom Namespace dari output perintah kubectl get pods.

Output perintah kubectl describe mencakup informasi mendetail tentang resource Anda. Berikut beberapa bagian yang paling berguna untuk ditinjau saat Anda memecahkan masalah Pod:

• Status: status Pod saat ini.
• Conditions: keseluruhan kondisi dan kesiapan Pod.
• Restart Count: berapa kali container dalam Pod telah di-restart. Jumlah yang tinggi dapat menjadi penyebab kekhawatiran.
• Events: log hal-hal penting yang telah terjadi pada Pod ini, seperti dijadwalkan ke node, menarik image container-nya, dan apakah terjadi error. Bagian Events sering kali menjadi tempat Anda dapat menemukan petunjuk langsung mengapa Pod gagal.

Seperti perintah kubectl get, Anda dapat menggunakan perintah kubectl describe untuk mempelajari lebih lanjut beberapa jenis resource. Untuk mengetahui daftar lengkap resource yang dapat Anda jelajahi, lihat kubectl describe dalam dokumentasi Kubernetes.

Melakukan analisis historis dengan Cloud Logging

Meskipun alat command line kubectl sangat berharga untuk memeriksa status live objek Kubernetes Anda, tampilannya sering kali terbatas pada saat ini. Untuk memahami akar penyebab masalah, Anda sering kali perlu menyelidiki apa yang terjadi dari waktu ke waktu. Jika Anda memerlukan konteks historis tersebut, gunakan Cloud Logging.

Cloud Logging menggabungkan log dari cluster GKE, aplikasi yang di-container, dan layanan lainnya. Google Cloud

Memahami jenis log utama untuk pemecahan masalah

Cloud Logging secara otomatis mengumpulkan beberapa jenis log GKE yang berbeda yang dapat membantu Anda memecahkan masalah:

• Log node dan runtime (kubelet, containerd): log dari layanan node pokok. Karena kubelet mengelola siklus proses semua Pod di node, lognya sangat penting untuk memecahkan masalah seperti peluncuran container, peristiwa Kehabisan Memori (OOM), kegagalan probe, dan error pemasangan volume. Log ini juga penting untuk mendiagnosis masalah tingkat node, seperti node yang memiliki status NotReady.

  Karena containerd mengelola siklus proses container Anda, termasuk menarik image, lognya sangat penting untuk memecahkan masalah yang terjadi sebelum kubelet dapat memulai container. Log containerd membantu Anda mendiagnosis masalah tingkat node di GKE, karena log ini mendokumentasikan aktivitas spesifik dan potensi error runtime container.

• Log aplikasi (stdout, stderr): aliran output dan error standar dari proses dalam container Anda. Log ini sangat penting untuk men-debug masalah khusus aplikasi seperti error, error, atau perilaku yang tidak terduga.

• Log audit: log ini menjawab "siapa yang melakukan apa, di mana, dan kapan?" untuk cluster Anda. Log ini melacak tindakan administratif dan panggilan API yang dilakukan ke server Kubernetes API, yang berguna untuk mendiagnosis masalah yang disebabkan oleh perubahan konfigurasi atau akses yang tidak sah.

Skenario pemecahan masalah umum

Setelah mengidentifikasi masalah, Anda dapat membuat kueri log ini untuk mengetahui apa yang terjadi. Untuk membantu Anda memulai, meninjau log dapat membantu Anda mengatasi masalah berikut:

• Jika node memiliki status NotReady, tinjau log node-nya. Log kubelet dan containerd sering kali mengungkapkan penyebab yang mendasarinya, seperti masalah jaringan atau batasan resource.
• Jika node baru gagal disediakan dan bergabung dengan cluster, tinjau log port serial node. Log ini merekam aktivitas booting awal dan startup kubelet sebelum agen logging node aktif sepenuhnya.
• Jika Pod gagal dimulai di masa lalu, tinjau log aplikasi untuk Pod tersebut guna memeriksa apakah ada error. Jika log kosong atau Pod tidak dapat dijadwalkan, periksa log audit untuk mengetahui peristiwa yang relevan atau log node pada node target untuk mendapatkan petunjuk tentang tekanan resource atau error penarikan image.
• Jika Deployment penting dihapus dan tidak ada yang tahu alasannya, kueri log audit Aktivitas Admin. Log ini dapat membantu Anda mengidentifikasi akun pengguna atau layanan mana yang mengeluarkan panggilan API penghapusan, sehingga memberikan titik awal yang jelas untuk penyelidikan Anda.

Cara mengakses log

Gunakan Logs Explorer untuk membuat kueri, melihat, dan menganalisis log GKE di konsol Google Cloud . Logs Explorer menyediakan opsi pemfilteran canggih yang membantu Anda mengisolasi masalah.

Untuk mengakses dan menggunakan Logs Explorer, selesaikan langkah-langkah berikut:

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

   Buka Logs Explorer

2. Di panel kueri, masukkan kueri. Gunakan bahasa kueri Logging untuk menulis kueri bertarget. Berikut beberapa filter umum untuk membantu Anda memulai:

   Jenis filter	Deskripsi	Nilai contoh
   resource.type	Jenis resource Kubernetes.	k8s_cluster, k8s_node, k8s_pod, k8s_container
   log_id	Aliran log dari resource.	stdout, stderr
   resource.labels.RESOURCE_TYPE.name	Memfilter resource dengan nama tertentu. Ganti RESOURCE_TYPE dengan nama resource yang ingin Anda kueri. Misalnya, namespace atau pod.	example-namespace-name, example-pod-name
   severity	Tingkat keparahan log.	DEFAULT, INFO, WARNING, ERROR, CRITICAL
   jsonPayload.message=~	Penelusuran ekspresi reguler untuk teks dalam pesan log.	scale.down.error.failed.to.delete.node.min.size.reached

   Misalnya, untuk memecahkan masalah Pod tertentu, Anda mungkin ingin mengisolasi log error-nya. Untuk melihat hanya log dengan tingkat keparahan ERROR untuk Pod tersebut, gunakan kueri berikut:

   resource.type="k8s_container"
   resource.labels.pod_name="POD_NAME"
   resource.labels.namespace_name="NAMESPACE_NAME"
   severity=ERROR
   

   Ganti kode berikut:

   • POD_NAME: nama Pod yang mengalami masalah.
   • NAMESPACE_NAME: namespace tempat Pod berada. Jika Anda tidak yakin apa namespace-nya, tinjau kolom Namespace dari output perintah kubectl get pods.

   Untuk contoh lainnya, lihat Kueri terkait Kubernetes dalam dokumentasi Google Cloud Observability.

3. Klik Run query.

4. Untuk melihat pesan log lengkap, termasuk payload JSON, metadata, dan stempel waktu, klik entri log.

Untuk mengetahui informasi selengkapnya tentang log GKE, lihat Tentang log GKE.

Melakukan pemantauan proaktif dengan Cloud Monitoring

Setelah masalah terjadi, meninjau log adalah langkah penting dalam pemecahan masalah. Namun, sistem yang benar-benar tangguh juga memerlukan pendekatan proaktif untuk mengidentifikasi masalah sebelum menyebabkan gangguan.

Untuk mengidentifikasi masalah di masa mendatang secara proaktif dan melacak indikator performa utama dari waktu ke waktu, gunakan Cloud Monitoring. Cloud Monitoring menyediakan dasbor, metrik, dan kemampuan pemberitahuan. Alat ini membantu Anda menemukan peningkatan rasio error, peningkatan latensi, atau batasan resource, yang membantu Anda mengambil tindakan sebelum pengguna terpengaruh.

Meninjau metrik yang berguna

GKE secara otomatis mengirimkan serangkaian metrik ke Cloud Monitoring. Bagian berikut mencantumkan beberapa metrik paling penting untuk pemecahan masalah:

• Metrik performa dan kesehatan penampung
• Metrik performa dan kesehatan node
• Metrik performa dan kesehatan pod

Untuk mengetahui daftar lengkap metrik GKE, lihat Metrik sistem GKE.

Metrik performa dan kondisi container

Mulailah dengan metrik ini saat Anda mencurigai adanya masalah pada aplikasi tertentu. Metrik ini membantu Anda memantau kesehatan aplikasi, termasuk mengetahui apakah penampung sering dimulai ulang, kehabisan memori, atau dibatasi oleh batas CPU.

Metrik performa dan kesehatan node

Periksa metrik ini saat Anda perlu mendiagnosis masalah pada infrastruktur GKE yang mendasarinya. Metrik ini sangat penting untuk memahami kesehatan dan kapasitas keseluruhan node Anda, membantu Anda menyelidiki apakah node tidak sehat atau tertekan, atau apakah node memiliki memori yang cukup untuk menjadwalkan Pod baru.

Metrik performa dan kesehatan pod

Metrik ini membantu Anda memecahkan masalah terkait interaksi Pod dengan lingkungannya, seperti jaringan dan penyimpanan. Gunakan metrik ini saat Anda perlu mendiagnosis Pod yang lambat dimulai, menyelidiki potensi masalah konektivitas jaringan, atau mengelola penyimpanan secara proaktif untuk mencegah kegagalan penulisan dari volume yang penuh.

Memvisualisasikan metrik dengan Metrics Explorer

Untuk memvisualisasikan status lingkungan GKE, buat diagram berdasarkan metrik dengan Metrics Explorer.

Untuk menggunakan Metrics Explorer, selesaikan langkah-langkah berikut:

1. Di Google Cloud konsol, buka halaman Metrics Explorer.

   Buka Metrics Explorer

2. Di kolom Metrik, pilih atau masukkan metrik yang ingin Anda periksa.

3. Lihat hasilnya dan amati tren apa pun dari waktu ke waktu.

Misalnya, untuk menyelidiki konsumsi memori Pod di namespace tertentu, Anda dapat melakukan hal berikut:

1. Dalam daftar Select a metric, pilih metrik kubernetes.io/container/memory/used_bytes, lalu klik Apply.
2. Klik Tambahkan filter, lalu pilih namespace_name.
3. Dalam daftar Nilai, pilih namespace yang ingin Anda selidiki.
4. Di kolom Aggregation, pilih Sum > pod_name, lalu klik OK. Setelan ini menampilkan garis deret waktu terpisah untuk setiap Pod.
5. Klik Simpan diagram.

Diagram yang dihasilkan menunjukkan penggunaan memori untuk setiap Pod dari waktu ke waktu, yang dapat membantu Anda mengidentifikasi secara visual Pod apa pun dengan penggunaan memori yang sangat tinggi atau melonjak secara tidak biasa.

Metrics Explorer memiliki fleksibilitas yang tinggi dalam cara membuat metrik yang ingin Anda lihat. Untuk mengetahui informasi selengkapnya tentang opsi lanjutan Metrics Explorer, lihat artikel Membuat diagram dengan Metrics Explorer di dokumentasi Cloud Monitoring.

Membuat pemberitahuan untuk deteksi masalah proaktif

Untuk menerima notifikasi saat terjadi masalah atau saat metrik melanggar batas tertentu, siapkan kebijakan pemberitahuan di Cloud Monitoring.

Misalnya, untuk menyiapkan kebijakan pemberitahuan yang memberi tahu Anda saat batas CPU penampung melebihi 80% selama lima menit, lakukan hal berikut:

1. Di konsol Google Cloud , buka halaman Alerting.

   Buka Pemberitahuan

2. Klik Create policy.

3. Di kotak Select a metric, filter CPU limit utilization lalu pilih metrik berikut: kubernetes.io/container/cpu/limit_utilization.

4. Klik Terapkan.

5. Biarkan kolom Tambahkan filter kosong. Setelan ini memicu pemberitahuan saat ada cluster yang melanggar nilai minimum Anda.

6. Di bagian Transformasi data, lakukan tindakan berikut:

   1. Di daftar Rolling window, pilih 1 minute. Setelan ini berarti Google Cloud menghitung nilai rata-rata setiap menit.

   2. Di daftar Rolling window function, pilih mean.

      Kedua setelan ini merata-ratakan pemakaian batas CPU untuk setiap container setiap menit.

7. Klik Berikutnya.

8. Di bagian Konfigurasi pemberitahuan, lakukan hal berikut:

   1. Untuk Jenis kondisi, pilih Batas.
   2. Untuk Pemicu pemberitahuan, pilih Deret waktu mana pun melanggar.
   3. Untuk Posisi nilai minimum, pilih Di atas nilai minimum.
   4. Untuk Nilai minimum, masukkan 0.8. Nilai ini mewakili nilai minimum 80% yang ingin Anda pantau.
   5. Klik Advanced options.
   6. Di daftar Periode pengujian ulang, pilih 5 menit. Setelan ini berarti pemberitahuan hanya dipicu jika penggunaan CPU tetap di atas 80% selama periode lima menit berkelanjutan, yang mengurangi alarm palsu dari lonjakan singkat.
   7. Di kolom Nama kondisi, beri nama deskriptif untuk kondisi tersebut.
   8. Klik Berikutnya.

9. Di bagian Konfigurasi notifikasi dan finalisasi pemberitahuan, lakukan hal berikut:

   1. Di daftar Saluran notifikasi, pilih saluran tempat Anda ingin menerima pemberitahuan. Jika Anda tidak memiliki channel, klik Kelola saluran notifikasi untuk membuatnya.
   2. Di kolom Name the alert policy, beri kebijakan nama yang jelas dan deskriptif.
   3. Biarkan kolom lain tetap pada nilai defaultnya.
   4. Klik Berikutnya.

10. Tinjau kebijakan Anda, dan jika semuanya terlihat benar, klik Buat kebijakan.

Untuk mempelajari cara tambahan membuat pemberitahuan, lihat Ringkasan pemberitahuan di dokumentasi Cloud Monitoring.

Mempercepat diagnosis dengan Gemini Cloud Assist

Terkadang, penyebab masalah Anda tidak langsung terlihat, meskipun Anda menggunakan alat yang dibahas di bagian sebelumnya. Menyelidiki kasus yang kompleks dapat memakan waktu dan memerlukan keahlian yang mendalam. Untuk skenario seperti ini, Gemini Cloud Assist dapat membantu. Fitur ini dapat otomatis mendeteksi pola tersembunyi, menampilkan anomali, dan memberikan ringkasan untuk membantu Anda menemukan kemungkinan penyebabnya dengan cepat.

Mengakses Gemini Cloud Assist

Untuk mengakses Gemini Cloud Assist, selesaikan langkah-langkah berikut:

1. Di konsol Google Cloud , buka halaman mana pun.

2. Di toolbar konsol Google Cloud , klik spark Buka atau tutup chat Gemini Cloud Assist.

   Panel Cloud Assist akan terbuka. Anda dapat mengklik contoh perintah jika ditampilkan, atau Anda dapat memasukkan perintah di kolom Masukkan perintah.

Mempelajari contoh perintah

Untuk membantu Anda memahami cara Gemini Cloud Assist dapat membantu Anda, berikut beberapa contoh perintah:

Untuk informasi selengkapnya, lihat referensi berikut:

• Pelajari cara menulis perintah yang lebih baik.
• Pelajari cara menggunakan panel Gemini Cloud Assist.
• Baca Ringkasan Gemini untuk Google Cloud .
• Pelajari cara Gemini untuk Google Cloud menggunakan data Anda.

Menggunakan Investigasi Gemini Cloud Assist

Selain percakapan interaktif, Gemini Cloud Assist dapat melakukan analisis mendalam yang lebih otomatis melalui Investigasi Gemini Cloud Assist. Fitur ini terintegrasi langsung ke dalam alur kerja seperti Logs Explorer, dan merupakan alat analisis akar penyebab yang efektif.

Saat Anda memulai penyelidikan dari error atau resource tertentu, Gemini Cloud Assist akan menganalisis log, konfigurasi, dan metrik. Alat ini menggunakan data ini untuk menghasilkan pengamatan dan hipotesis yang diberi peringkat tentang kemungkinan penyebab utama, lalu memberikan langkah selanjutnya yang direkomendasikan kepada Anda. Anda juga dapat mentransfer hasil ini ke kasus dukungan Google Cloud untuk memberikan konteks berharga yang dapat membantu Anda menyelesaikan masalah lebih cepat.

Untuk mengetahui informasi selengkapnya, lihat Investigasi Gemini Cloud Assist dalam dokumentasi Gemini.

Menyatukan semuanya: Contoh skenario pemecahan masalah

Contoh ini menunjukkan cara menggunakan kombinasi alat GKE untuk mendiagnosis dan memahami masalah umum di dunia nyata: penampung yang berulang kali mengalami error karena memori yang tidak mencukupi.

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.

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

Konfirmasi masalah di konsol Google Cloud

Anda mulai 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 alasannya. 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 akan 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 penyebabnya. 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

• Untuk mendapatkan saran tentang cara menyelesaikan masalah tertentu, tinjau panduan pemecahan masalah GKE.

• Jika Anda tidak dapat menemukan solusi untuk masalah Anda dalam dokumentasi, lihat Mendapatkan dukungan untuk mendapatkan bantuan lebih lanjut, termasuk saran tentang topik berikut:

  • Membuka kasus dukungan dengan menghubungi Layanan Pelanggan Cloud.
  • Mendapatkan dukungan dari komunitas dengan mengajukan pertanyaan di StackOverflow dan menggunakan tag google-kubernetes-engine untuk menelusuri masalah serupa. Anda juga dapat bergabung ke #kubernetes-engine channel Slack untuk mendapatkan dukungan komunitas lainnya.
  • Membuka bug atau permintaan fitur menggunakan issue tracker publik.