Memecahkan masalah upgrade cluster

Jika upgrade bidang kontrol atau node pool Google Kubernetes Engine (GKE) Anda gagal, macet, atau menyebabkan perilaku workload yang tidak terduga, Anda mungkin perlu memecahkan masalah proses tersebut. Memastikan panel kontrol dan kumpulan node Anda selalu diupdate sangat penting untuk keamanan dan performa, dan menyelesaikan masalah apa pun akan membantu memastikan lingkungan Anda tetap stabil.

Untuk mengatasi masalah upgrade umum, langkah pertama yang baik adalah memantau proses upgrade cluster. Kemudian, Anda dapat menemukan saran tentang cara menyelesaikan masalah Anda:

Informasi ini penting bagi admin dan operator Platform yang ingin mendiagnosis penyebab utama upgrade yang macet atau gagal, mengelola kebijakan pemeliharaan, dan menyelesaikan ketidakcocokan versi. Developer aplikasi dapat menemukan panduan tentang cara mengatasi masalah workload pasca-upgrade dan memahami cara konfigurasi workload, seperti PodDisruptionBudgets, dapat memengaruhi durasi upgrade. Untuk mengetahui informasi selengkapnya tentang peran umum dan contoh tugas yang kami referensikan dalam konten Trusted Cloud by S3NS , lihat Peran dan tugas pengguna GKE umum.

Memantau proses upgrade cluster

Untuk menyelesaikan masalah upgrade secara lebih efektif, mulailah dengan memahami apa yang terjadi selama proses upgrade. GKE menyediakan beberapa alat yang memberi Anda visibilitas ke dalam proses ini.

Di konsol Trusted Cloud , dasbor upgrade menawarkan tampilan seluruh project dari semua upgrade cluster yang sedang berlangsung, linimasa peristiwa terbaru, dan peringatan tentang kemungkinan pemblokir seperti pengecualian pemeliharaan aktif atau penghentian penggunaan versi mendatang. Untuk pemeriksaan command line atau otomatis, Anda dapat menggunakan perintah gcloud container operations list untuk mendapatkan status operasi upgrade tertentu. Untuk mengetahui informasi selengkapnya, lihat Mendapatkan visibilitas ke dalam upgrade cluster.

Untuk penyelidikan yang lebih mendetail, Cloud Logging adalah sumber informasi utama Anda. GKE mencatat informasi mendetail tentang proses upgrade panel kontrol dan node pool dalam Cloud Logging. Hal ini mencakup log audit tingkat tinggi yang melacak operasi upgrade utama, serta log yang lebih terperinci seperti Peristiwa Kubernetes dan log dari komponen node, yang dapat menunjukkan informasi lebih lanjut tentang error tertentu.

Bagian berikut menjelaskan cara membuat kueri log ini menggunakan Logs Explorer atau gcloud CLI. Untuk mengetahui informasi selengkapnya, lihat Memeriksa log upgrade.

Mengidentifikasi operasi upgrade dengan log audit

Jika tidak mengetahui operasi upgrade mana yang gagal, Anda dapat menggunakan log audit GKE. Log audit melacak tindakan administratif dan memberikan catatan resmi tentang kapan upgrade dimulai dan status akhirnya. Gunakan kueri berikut di Logs Explorer untuk menemukan operasi yang relevan.

Jenis peristiwa Kueri log
Upgrade otomatis bidang kontrol 
resource.type="gke_cluster"
protoPayload.methodName="google.container.internal.ClusterManagerInternal.UpdateClusterInternal"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.metadata.operationType="UPGRADE_MASTER"
resource.labels.cluster_name="CLUSTER_NAME"

Ganti CLUSTER_NAME dengan nama cluster yang ingin Anda selidiki.

Kueri ini menampilkan versi bidang kontrol target dan versi bidang kontrol sebelumnya.
Upgrade manual bidang kontrol 
resource.type="gke_cluster"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.response.operationType="UPGRADE_MASTER"
resource.labels.cluster_name="CLUSTER_NAME"

 
Upgrade otomatis node pool (hanya versi target) 
resource.type="gke_nodepool"
protoPayload.methodName="google.container.internal.ClusterManagerInternal.UpdateClusterInternal"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.metadata.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.nodepool_name="NODEPOOL_NAME"

Ganti NODEPOOL_NAME dengan nama node pool yang termasuk dalam cluster.
Upgrade manual node pool 
resource.type="gke_nodepool"
protoPayload.methodName="google.container.v1.ClusterManager.UpdateNodePool"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.response.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.nodepool_name="NODEPOOL_NAME"

Untuk menemukan versi kumpulan node sebelumnya, periksa log Kubernetes API:

resource.type="k8s_cluster"
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.methodName="nodes.patch"

Menemukan pesan error mendetail di log GKE

Setelah log audit menunjukkan operasi mana yang gagal dan kapan, Anda dapat menelusuri pesan error yang lebih mendetail dari komponen GKE pada waktu yang sama. Log ini dapat berisi alasan spesifik kegagalan upgrade, seperti objek PodDisruptionBudget yang salah dikonfigurasi.

Misalnya, setelah menemukan operasi UPGRADE_NODES yang gagal dalam log audit, Anda dapat menggunakan stempel waktunya untuk mempersempit penelusuran. Di Logs Explorer, masukkan kueri berikut, lalu gunakan pemilih rentang waktu untuk berfokus pada waktu saat kegagalan terjadi:

resource.type="k8s_node"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.node_name="NODE_NAME"
severity=ERROR

Ganti kode berikut:

  • CLUSTER_NAME: nama cluster Anda.
  • NODE_NAME: nama node dalam cluster yang ingin Anda periksa apakah ada error.

Menggunakan gcloud CLI untuk melihat peristiwa upgrade

Selain Logs Explorer, Anda dapat menggunakan perintah gcloud CLI untuk meninjau peristiwa upgrade.

Untuk mencari upgrade bidang kontrol, jalankan perintah berikut:

gcloud container operations list --filter="TYPE=UPGRADE_MASTER"

Outputnya mirip dengan hal berikut ini:

NAME: operation-1748588803271-cfd407a2-bfe7-4b9d-8686-9f1ff33a2a96
TYPE: UPGRADE_MASTER
LOCATION: LOCATION
TARGET: CLUSTER_NAME
STATUS_MESSAGE:
STATUS: DONE
START_TIME: 2025-05-30T07:06:43.271089972Z
END_TIME: 2025-05-30T07:18:02.639579287Z

Output ini mencakup nilai-nilai berikut:

  • LOCATION: region atau zona Compute Engine (misalnya, us-central1 atau us-central1-a) untuk cluster.
  • CLUSTER_NAME: nama cluster Anda.

Untuk mencari upgrade node pool, jalankan perintah berikut:

gcloud container operations list --filter="TYPE=UPGRADE_NODES"

Outputnya mirip dengan hal berikut ini:

NAME: operation-1748588803271-cfd407a2-bfe7-4b9d-8686-9f1ff33a2a96
TYPE: UPGRADE_NODES
LOCATION: LOCATION
TARGET: CLUSTER_NAME
STATUS_MESSAGE:
STATUS: DONE
START_TIME: 2025-05-30T07:06:43.271089972Z
END_TIME: 2025-05-30T07:18:02.639579287Z

Contoh: Menggunakan log untuk memecahkan masalah upgrade bidang kontrol

Contoh berikut menunjukkan cara menggunakan log untuk memecahkan masalah upgrade bidang kontrol yang tidak berhasil:

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

    Buka Logs Explorer

  2. Di panel kueri, filter log upgrade panel kontrol dengan memasukkan kueri berikut:

    resource.type="gke_cluster"
protoPayload.metadata.operationType=~"(UPDATE_CLUSTER|UPGRADE_MASTER)"
resource.labels.cluster_name="CLUSTER_NAME"

    Ganti CLUSTER_NAME dengan nama cluster yang ingin Anda selidiki.

  3. Klik Run query.

  4. Tinjau output log untuk mengetahui informasi berikut:

  5. Konfirmasi bahwa upgrade telah dimulai: cari peristiwa UPGRADE_MASTER terkini di sekitar waktu Anda memulai upgrade. Kehadiran peristiwa ini mengonfirmasi bahwa Anda atau GKE memicu proses upgrade.

    • Verifikasi versi: periksa kolom berikut untuk mengonfirmasi versi sebelumnya dan target:

      • protoPayload.metadata.previousMasterVersion: menampilkan versi bidang kontrol sebelum upgrade.

      • protoPayload.metadata.currentMasterVersion: menampilkan versi yang digunakan GKE untuk mencoba mengupgrade bidang kontrol.

        Misalnya, jika Anda ingin mengupgrade ke versi 1.30.1-gke.1234, tetapi secara tidak sengaja menentukan 1.30.2-gke.4321 (versi yang lebih baru dan berpotensi tidak kompatibel untuk workload Anda), meninjau kedua kolom ini akan menunjukkan perbedaan tersebut. Atau, jika kolom currentMasterVersion masih menampilkan versi sebelumnya setelah jangka waktu yang lama, temuan ini menunjukkan bahwa upgrade gagal menerapkan versi baru.

    • Cari error: periksa peristiwa UPGRADE_MASTER yang berulang atau pesan error lainnya. Jika log operasi berhenti tanpa menunjukkan penyelesaian atau kegagalan, temuan ini menunjukkan adanya masalah.

Setelah mengidentifikasi error atau perilaku tertentu dari log, Anda dapat menggunakan informasi tersebut untuk menemukan solusi yang sesuai dalam panduan ini.

Memecahkan masalah upgrade node pool yang memerlukan waktu lebih lama dari biasanya

Jika upgrade node pool memerlukan waktu lebih lama dari yang diperkirakan, coba solusi berikut:

  1. Periksa nilai terminationGracePeriodSeconds dalam manifes Pod Anda. Nilai ini menentukan waktu maksimum yang ditunggu Kubernetes agar Pod dimatikan dengan benar. Nilai yang tinggi (misalnya, beberapa menit) dapat memperpanjang durasi upgrade secara signifikan karena Kubernetes menunggu seluruh periode untuk setiap Pod. Jika penundaan ini menyebabkan masalah, pertimbangkan untuk mengurangi nilai.

  2. Periksa objek PodDisruptionBudget Anda. Saat node sedang dikosongkan, GKE menunggu paling lama satu jam per node untuk mengeluarkan workloadnya dengan benar. Jika objek PodDisruptionBudget Anda terlalu ketat, hal ini dapat mencegah pengusiran yang lancar berhasil. Dalam skenario ini, GKE menggunakan seluruh masa tenggang satu jam untuk mencoba menguras node sebelum akhirnya waktu habis dan upgrade dipaksa untuk dilanjutkan. Penundaan ini, jika terjadi berulang kali di beberapa node, adalah penyebab umum lambatnya upgrade cluster secara keseluruhan. Untuk mengonfirmasi apakah objek PodDisruptionBudget yang membatasi adalah penyebab upgrade lambat, gunakan Logs Explorer:

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

      Buka Logs Explorer

    2. Di panel kueri, masukkan kueri berikut:

      resource.type=("gke_cluster" OR "k8s_cluster")
resource.labels.cluster_name="CLUSTER_NAME"
protoPayload.response.message="Cannot evict pod as it would violate the pod's disruption budget."
log_id("cloudaudit.googleapis.com/activity")

    3. Klik Run query.

    4. Tinjau output log. Jika objek PodDisruptionBudget adalah penyebab masalah Anda, outputnya akan mirip dengan berikut ini:

      resourceName: "core/v1/namespaces/istio-system/pods/POD_NAME/eviction"

response: {
  @type: "core.k8s.io/v1.Status"
  apiVersion: "v1"
  code: 429
  details: {
  causes: [
    0: {
    message: "The disruption budget istio-egressgateway needs 1 healthy pods and has 1 currently"
    reason: "DisruptionBudget"
    }
  ]
  }
  kind: "Status"
  message: "Cannot evict pod as it would violate the pod's disruption budget."
  metadata: {
  }
  reason: "TooManyRequests"
  status: "Failure"
}

    5. Setelah Anda mengonfirmasi bahwa objek PodDisruptionBudget adalah penyebabnya, buat daftar semua objek PodDisruptionBudget dan pastikan setelannya sesuai:

      kubectl get pdb --all-namespaces

      Outputnya mirip dengan hal berikut ini:

      NAMESPACE        NAME          MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
example-app-one  one_pdb       3               0                 1                     12d

      Dalam contoh ini, PodDisruptionBudget bernama one_pdb memerlukan minimal tiga Pod yang tersedia. Karena mengeluarkan Pod selama upgrade hanya akan menyisakan dua Pod, tindakan ini melanggar anggaran dan menyebabkan upgrade terhenti.

      Jika objek PodDisruptionBudget berfungsi seperti yang Anda inginkan, Anda tidak perlu melakukan tindakan apa pun. Jika tidak, pertimbangkan untuk mengurangi setelan PodDisruptionBudget selama periode upgrade.

  3. Periksa afinitas node Anda. Aturan ketat dapat memperlambat upgrade dengan mencegah Pod dijadwalkan ulang ke node yang tersedia jika node tersebut tidak cocok dengan label yang diperlukan. Masalah ini sangat bermasalah selama upgrade lonjakan karena afinitas node dapat membatasi jumlah node yang dapat diupgrade secara bersamaan jika node dengan label yang benar tidak memiliki kapasitas cluster yang cukup untuk menghosting Pod baru.

  4. Periksa apakah Anda menggunakan strategi upgrade singkat. GKE menggunakan strategi upgrade berdurasi singkat untuk node flex-start dan untuk node yang hanya menggunakan penyediaan dalam antrean pada cluster yang menjalankan GKE versi 1.32.2-gke.1652000 atau yang lebih baru. Jika Anda menggunakan strategi upgrade ini, operasi upgrade dapat memerlukan waktu hingga tujuh hari.

  5. Periksa apakah Anda menggunakan Pod durasi yang diperpanjang (tersedia untuk cluster Autopilot). Selama upgrade, GKE harus menguras semua Pod dari node sebelum proses dapat selesai. Namun, selama upgrade yang dimulai oleh GKE, GKE tidak menghapus Pod dengan durasi yang diperpanjang hingga tujuh hari. Perlindungan ini mencegah node dikuras. GKE menghentikan Pod secara paksa hanya setelah periode ini berakhir, dan penundaan multi-hari yang signifikan untuk satu node ini dapat menunda upgrade lebih banyak node di cluster Autopilot.

  6. Persistent Volume yang terpasang dapat menyebabkan proses upgrade memerlukan waktu lebih lama dari biasanya, karena waktu yang diperlukan untuk mengelola siklus proses volume ini.

  7. Periksa status upgrade otomatis cluster. Jika alasannya adalah SYSTEM_CONFIG, upgrade otomatis akan dijeda sementara karena alasan teknis atau bisnis. Jika Anda melihat alasan ini, sebaiknya jangan melakukan upgrade manual kecuali jika diperlukan.

Memecahkan masalah upgrade node pool yang tidak selesai

Terkadang, GKE tidak dapat menyelesaikan upgrade node pool, sehingga node pool hanya diupgrade sebagian. Ada beberapa alasan yang menyebabkan upgrade tidak selesai:

  • Upgrade dibatalkan secara manual.
  • Upgrade gagal karena masalah seperti node baru gagal didaftarkan, kehabisan alamat IP, atau kuota resource tidak mencukupi.
  • GKE menjeda upgrade. Penangguhan ini dapat terjadi, misalnya, untuk mencegah upgrade ke versi dengan masalah yang diketahui atau selama periode pemeliharaan tertentu yang dimulai oleh Google.
  • Jika Anda menggunakan upgrade otomatis, masa pemeliharaan berakhir sebelum upgrade dapat diselesaikan. Atau, periode pengecualian pemeliharaan dimulai sebelum upgrade dapat diselesaikan. Untuk mengetahui informasi selengkapnya, lihat Masa pemeliharaan mencegah penyelesaian update node.

Jika node pool diupgrade sebagian, node akan berjalan di versi yang berbeda. Untuk menyelesaikan masalah ini dan memverifikasi bahwa semua node dalam node pool berjalan di versi yang sama, Anda dapat melanjutkan upgrade atau melakukan roll back upgrade.

Namun, strategi upgrade lonjakan dan strategi upgrade blue-green berinteraksi dengan masa pemeliharaan secara berbeda:

  • Upgrade lonjakan: operasi upgrade dijeda jika berjalan di luar masa pemeliharaan. Upgrade akan dilanjutkan secara otomatis selama masa pemeliharaan terjadwal berikutnya.
  • Upgrade blue-green: operasi upgrade berlanjut hingga selesai, meskipun melampaui periode pemeliharaan. Upgrade biru-hijau menawarkan kontrol terperinci atas kecepatan upgrade dengan fitur seperti waktu tunggu batch dan node pool, dan node pool tambahan membantu memastikan beban kerja tetap beroperasi.

Memecahkan masalah perilaku upgrade otomatis yang tidak terduga

Terkadang, upgrade otomatis cluster tidak terjadi seperti yang Anda harapkan. Bagian berikut membantu Anda menyelesaikan masalah berikut:

Cluster gagal diupgrade saat upgrade otomatis node diaktifkan

Jika Anda belum menonaktifkan upgrade otomatis node, tetapi upgrade tidak terjadi, coba solusi berikut:

  1. Jika Anda menggunakan saluran rilis, pastikan upgrade otomatis node tidak diblokir. Untuk cluster yang terdaftar di saluran rilis, maintenancePolicy Anda adalah cara utama untuk mengontrol upgrade otomatis. Hal ini dapat mencegah upgrade dimulai atau mengganggu upgrade yang sedang berlangsung. Pengecualian pemeliharaan aktif dapat memblokir upgrade sepenuhnya dan pengaturan waktu masa pemeliharaan dapat menyebabkan gangguan. Tinjau maintenancePolicy Anda untuk menentukan apakah salah satu setelan ini menjadi penyebabnya:

    gcloud container clusters describe CLUSTER_NAME \
    --project PROJECT_ID  \
    --location LOCATION

    Ganti kode berikut:

    • CLUSTER_NAME: nama cluster node pool yang akan dideskripsikan.
    • PROJECT_ID: project ID cluster.
    • LOCATION: region atau zona Compute Engine (misalnya, us-central1 atau us-central1-a) untuk cluster.

    Outputnya mirip dengan hal berikut ini:

    …
maintenancePolicy:
  maintenanceExclusions:
  - exclusionName: critical-event-q4-2025
    startTime: '2025-12-20T00:00:00Z'
    endTime: '2026-01-05T00:00:00Z'
    scope:
      noUpgrades: true # This exclusion blocks all upgrades
  window:
    dailyMaintenanceWindow:
      startTime: 03:00 # Daily window at 03:00 UTC
…

    Pada output, tinjau bagian maintenancePolicy untuk dua kondisi berikut:

    • Untuk melihat apakah upgrade diblokir: cari maintenanceExclusion aktif dengan cakupan NO_MINOR_OR_NODE_UPGRADES. Setelan ini umumnya mencegah GKE memulai upgrade baru.
    • Untuk melihat apakah upgrade terganggu: periksa jadwal untuk dailyMaintenanceWindow atau maintenanceExclusions Anda. Jika upgrade berjalan di luar periode yang dijadwalkan, GKE akan menjeda upgrade, sehingga menghasilkan upgrade sebagian. Untuk mengetahui informasi selengkapnya tentang upgrade parsial, lihat bagian Memecahkan masalah upgrade yang tidak selesai.

    Untuk mengatasi masalah ini, Anda dapat menunggu hingga pengecualian berakhir, menghapusnya, atau menyesuaikan periode pemeliharaan untuk memberikan lebih banyak waktu agar upgrade selesai.

  2. Jika Anda tidak menggunakan saluran rilis, pastikan upgrade otomatis masih diaktifkan untuk node pool:

    gcloud container node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location LOCATION

    Ganti NODE_POOL_NAME dengan nama node pool yang akan dideskripsikan.

    Jika upgrade otomatis node pool diaktifkan untuk node pool ini, output di kolom autoUpgrade adalah sebagai berikut:

    management:
  autoUpgrade: true

    Jika autoUpgrade disetel ke false, atau kolom tidak ada, aktifkan upgrade otomatis.

  3. Upgrade mungkin belum diluncurkan ke region atau zona tempat cluster Anda berada, meskipun upgrade tersebut disebutkan dalam catatan rilis. Upgrade GKE diluncurkan secara progresif selama beberapa hari (biasanya empat hari atau lebih). Setelah upgrade mencapai wilayah atau zona Anda, upgrade hanya dimulai selama masa pemeliharaan yang disetujui. Misalnya, peluncuran dapat mencapai zona cluster Anda pada Hari Pertama peluncuran, tetapi masa pemeliharaan berikutnya untuk cluster baru akan dilakukan pada Hari Ketujuh. Dalam skenario ini, GKE tidak akan mengupgrade cluster hingga Hari Ketujuh. Untuk mengetahui informasi selengkapnya, lihat jadwal rilis GKE.

Cluster diupgrade secara otomatis saat upgrade otomatis tidak diaktifkan

Untuk membantu menjaga keandalan, ketersediaan, keamanan, dan performa lingkungan GKE Anda, GKE dapat mengupgrade cluster Anda secara otomatis, meskipun Anda tidak menggunakan upgrade otomatis.

GKE dapat melewati masa pemeliharaan, pengecualian, atau upgrade otomatis node pool yang dinonaktifkan untuk melakukan upgrade yang diperlukan karena beberapa alasan penting, seperti berikut:

  • Cluster yang bidang kontrolnya menjalankan versi GKE yang telah mencapai tanggal akhir dukungan. Untuk mengonfirmasi bahwa cluster Anda mendekati tanggal akhir dukungannya, lihat Perkiraan jadwal untuk saluran rilis.
  • Node dalam cluster yang menjalankan versi GKE yang telah mencapai tanggal akhir dukungan.
  • Cluster yang dalam status berjalan, tetapi tidak menunjukkan aktivitas selama jangka waktu yang lebih lama. Misalnya, GKE mungkin menganggap cluster tanpa panggilan API, tanpa traffic jaringan, dan tanpa penggunaan subnet yang aktif sebagai cluster yang diabaikan.
  • Cluster yang menunjukkan ketidakstabilan persisten yang berulang kali melalui siklus status operasional. Misalnya, status yang berulang dari berjalan hingga terdegradasi, diperbaiki, atau ditangguhkan, lalu kembali berjalan tanpa penyelesaian.

Jika Anda mengamati upgrade otomatis yang tidak terduga dan memiliki kekhawatiran tentang efek yang mungkin ditimbulkan upgrade ini pada cluster Anda, hubungi Layanan Pelanggan Cloud untuk mendapatkan bantuan.

Memecahkan masalah upgrade yang gagal

Jika upgrade Anda gagal, GKE akan menampilkan pesan error. Bagian berikut menjelaskan penyebab dan penyelesaian untuk error berikut:

Error: kube-apiserver tidak responsif

Terkadang, Anda mungkin melihat pesan error berikut saat memulai upgrade bidang kontrol manual versi GKE cluster:

FAILED: All cluster resources were brought up, but: component
"KubeApiserverReady" from endpoint "readyz of kube apiserver is not successful"
is unhealthy.

Pesan ini muncul di gcloud CLI dan di entri log jenis resource gke_cluster dan gke_nodepool.

Masalah ini terjadi saat beberapa webhook penerimaan yang di-deploy oleh pengguna memblokir komponen sistem sehingga tidak dapat membuat peran RBAC permisif yang diperlukan agar berfungsi dengan benar.

Selama upgrade bidang kontrol, GKE akan membuat ulang komponen server Kubernetes API (kube-apiserver). Jika webhook memblokir peran RBAC untuk komponen server API, server API tidak akan dimulai dan upgrade cluster tidak akan selesai. Meskipun webhook berfungsi dengan benar, webhook dapat menyebabkan upgrade cluster gagal karena bidang kontrol yang baru dibuat mungkin tidak dapat menjangkau webhook.

Kubernetes akan otomatis merekonsiliasi peran RBAC sistem default dengan kebijakan default dalam versi minor terbaru. Kebijakan default untuk peran sistem terkadang berubah pada versi Kubernetes baru.

Untuk melakukan rekonsiliasi ini, GKE membuat atau mengupdate ClusterRoles dan ClusterRoleBindings di cluster. Jika Anda memiliki webhook yang menghalangi dan menolak permintaan pembuatan atau update karena cakupan izin yang digunakan kebijakan RBAC default, server API tidak dapat berfungsi pada versi minor yang baru.

Untuk mengidentifikasi webhook yang gagal, periksa log audit GKE Anda untuk panggilan RBAC dengan informasi berikut:

protoPayload.resourceName="RBAC_RULE"
protoPayload.authenticationInfo.principalEmail="system:apiserver"

Dalam output ini, RBAC_RULE adalah nama lengkap peran RBAC, seperti rbac.authorization.k8s.io/v1/clusterroles/system:controller:horizontal-pod-autoscaler.

Nama webhook yang gagal ditampilkan di log dengan format berikut:

admission webhook WEBHOOK_NAME denied the request

Untuk mengatasi masalah ini, coba solusi berikut:

  1. Tinjau ClusterRole Anda untuk memastikan bahwa ClusterRole tersebut tidak terlalu ketat. Kebijakan Anda tidak boleh memblokir permintaan GKE untuk membuat atau memperbarui ClusterRole dengan awalan system: default.
  2. Sesuaikan webhook Anda agar tidak menghalangi permintaan untuk membuat dan memperbarui peran RBAC sistem.
  3. Nonaktifkan webhook.

Error: DeployPatch gagal

Terkadang, operasi upgrade cluster gagal dengan error berikut:

DeployPatch failed

Error ini dapat terjadi jika bidang kontrol Kubernetes tetap tidak berfungsi selama lebih dari 20 menit.

Error ini sering kali bersifat sementara karena bidang kontrol mencoba kembali operasi hingga berhasil. Jika upgrade terus gagal dengan error ini, hubungi Cloud Customer Care.

Memecahkan masalah setelah upgrade selesai

Jika Anda mengalami perilaku yang tidak terduga setelah upgrade selesai, bagian berikut menawarkan panduan pemecahan masalah untuk masalah umum berikut:

Perilaku yang tidak terduga karena perubahan yang merusak

Jika upgrade berhasil diselesaikan, tetapi Anda melihat perilaku yang tidak terduga setelah upgrade, periksa catatan rilis GKE untuk mengetahui informasi tentang bug dan perubahan yang menyebabkan gangguan terkait versi yang diupgrade cluster.

Workload dikeluarkan setelah upgrade cluster Standard

Workload Anda mungkin berisiko dikeluarkan setelah upgrade cluster jika semua kondisi berikut terpenuhi:

  • Workload sistem memerlukan lebih banyak ruang saat bidang kontrol cluster menjalankan versi GKE baru.
  • Node yang ada tidak memiliki resource yang cukup untuk menjalankan workload sistem baru dan workload yang ada.
  • Autoscaler cluster dinonaktifkan untuk cluster.

Untuk mengatasi masalah ini, coba solusi berikut:

  1. Mengaktifkan penskalaan otomatis untuk node pool yang ada.
  2. Aktifkan penyediaan otomatis node.
  3. Buat node pool baru.
  4. Meningkatkan skala node pool yang ada.

Pod yang terjebak dalam status Pending setelah mengonfigurasi Node Allocatable

Jika Anda telah mengonfigurasi Node Allocatable, upgrade versi node terkadang dapat menyebabkan Pod yang memiliki status Running terjebak dalam status Pending. Perubahan ini biasanya terjadi karena node yang diupgrade menggunakan resource sistem yang sedikit berbeda, atau karena Pod yang dijadwalkan ulang kini harus sesuai dengan batas Node yang Dapat Dialokasikan pada node baru atau yang diubah, yang berpotensi dalam kondisi yang lebih ketat.

Jika Pod Anda memiliki status Pending setelah upgrade, coba solusi berikut:

  1. Pastikan permintaan CPU dan memori untuk Pod Anda tidak melebihi penggunaan puncaknya. Dengan GKE yang mencadangkan CPU dan memori untuk overhead, Pod tidak dapat meminta resource ini. Pod yang meminta CPU atau memori yang melebihi penggunaannya akan mencegah Pod lain meminta resource ini, dan mungkin membuat cluster kurang dimanfaatkan. Untuk mengetahui informasi selengkapnya, lihat Cara Pod dengan permintaan resource dijadwalkan dalam dokumentasi Kubernetes.
  2. Pertimbangkan untuk meningkatkan ukuran cluster Anda.
  3. Untuk memverifikasi apakah upgrade adalah penyebab masalah ini, batalkan upgrade dengan melakukan downgrade pada node pool.
  4. Konfigurasikan cluster Anda untuk mengirim metrik scheduler Kubernetes ke Cloud Monitoring dan melihat metrik scheduler. Dengan memantau metrik ini, Anda dapat menentukan apakah ada cukup resource agar Pod dapat berjalan.

Memecahkan masalah versi dan kompatibilitas

Mempertahankan versi yang didukung dan kompatibel untuk semua komponen cluster Anda sangat penting untuk stabilitas dan performa. Bagian berikut memberikan panduan tentang cara mengidentifikasi dan menyelesaikan masalah versi dan kompatibilitas yang dapat memengaruhi proses upgrade.

Memeriksa inkompatibilitas versi bidang kontrol dan node

Perbedaan versi antara bidang kontrol dan node dapat menyebabkan ketidakstabilan cluster. Kebijakan ketidaksesuaian versi GKE menyatakan bahwa bidang kontrol hanya kompatibel dengan node hingga dua versi minor sebelumnya. Misalnya, bidang kontrol 1.19 berfungsi dengan node 1.19, 1.18, dan 1.17.

Jika node Anda berada di luar periode yang didukung ini, Anda berisiko mengalami masalah kompatibilitas kritis. Masalah ini sering kali terkait dengan API; misalnya, beban kerja pada node lama mungkin menggunakan versi API yang telah dihentikan atau dihapus di bidang kontrol yang lebih baru. Ketidakcocokan ini juga dapat menyebabkan kegagalan yang lebih parah, seperti jalur jaringan yang rusak yang mencegah node mendaftar ke cluster jika workload yang tidak kompatibel mengganggu komunikasi.

Secara berkala, tim GKE melakukan upgrade pada bidang kontrol cluster untuk Anda. Bidang kontrol diupgrade ke versi Kubernetes stabil yang lebih baru. Untuk memastikan node Anda tetap kompatibel dengan bidang kontrol yang diupgrade, node tersebut juga harus selalu diupdate. Secara default, GKE menangani upgrade ini karena node cluster telah mengaktifkan upgrade otomatis, dan sebaiknya Anda tidak menonaktifkannya. Jika upgrade otomatis dinonaktifkan untuk node cluster, dan Anda tidak mengupgradenya secara manual, panel kontrol Anda pada akhirnya akan tidak kompatibel dengan node Anda.

Untuk mengonfirmasi apakah versi bidang kontrol dan node Anda tidak kompatibel, periksa versi Kubernetes yang dijalankan oleh bidang kontrol dan node pool cluster Anda:

gcloud container clusters describe CLUSTER_NAME \
    --project PROJECT_ID  \
    --location LOCATION

Ganti kode berikut:

  • CLUSTER_NAME: nama cluster node pool yang akan dideskripsikan.
  • PROJECT_ID: project ID cluster.
  • LOCATION: region atau zona Compute Engine (misalnya, us-central1 atau us-central1-a) untuk cluster.

Outputnya mirip dengan hal berikut ini:

…
currentMasterVersion: 1.32.3-gke.1785003
…
currentNodeVersion: 1.26.15-gke.1090000
…

Dalam contoh ini, versi bidang kontrol dan versi node pool tidak kompatibel.

Untuk mengatasi masalah ini, upgrade versi node pool secara manual ke versi yang kompatibel dengan bidang kontrol.

Jika Anda mengkhawatirkan bahwa proses upgrade dapat menyebabkan gangguan pada workload yang berjalan di node yang terpengaruh, selesaikan langkah-langkah berikut untuk memigrasikan workload Anda ke node pool baru:

  1. Buat node pool baru dengan versi yang kompatibel.
  2. Pisahkan node dari node pool yang ada.
  3. Opsional: perbarui workload yang berjalan di node pool yang ada untuk menambahkan nodeSelector untuk label cloud.google.com/gke-nodepool:NEW_NODE_POOL_NAME. Ganti NEW_NODE_POOL_NAME dengan nama node pool baru. Tindakan ini memastikan GKE menempatkan workload tersebut di node dalam node pool baru.
  4. Hapus node pool yang ada.
  5. Periksa apakah workload berhasil berjalan di node pool baru. Jika sudah, Anda dapat menghapus node pool lama. Jika Anda melihat gangguan workload, jadwalkan ulang workload pada node yang ada dengan membatalkan penutupan node di node pool yang ada dan mengosongkan node baru.

Penggunaan CPU node lebih tinggi dari yang diperkirakan

Anda mungkin mengalami masalah ketika beberapa node menggunakan CPU lebih banyak dari yang diperkirakan untuk Pod yang berjalan.

Masalah ini dapat terjadi jika Anda menggunakan upgrade manual dan cluster atau node Anda belum diupgrade untuk menjalankan versi yang didukung. Tinjau catatan rilis untuk memastikan versi yang Anda gunakan tersedia dan didukung.

Langkah berikutnya