Memahami cara melakukan pemeliharaan host di GKE

Selama siklus proses cluster GKE yang berjalan lama, gangguan berkala pada workload terjadi karena gangguan infrastruktur yangGoogle Cloud masalah. Peristiwa otomatis ini dapat terjadi untuk merespons keputusan penjadwalan (peristiwa penghentian sementara), atau update node, yang mencakup upgrade otomatis node GKE (peristiwa pemeliharaan), atau perbaikan masalah yang terdeteksi (peristiwa penghentian).

Dokumen ini membantu Anda memahami arti gangguan node di GKE, memantau notifikasi pemeliharaan Compute Engine, dan meminimalkan dampak gangguan di node GKE Anda.

Dokumen ini berlaku untuk jenis mesin berikut:

Dokumen ini ditujukan untuk admin dan operator Platform yang mengelola siklus proses infrastruktur teknis yang mendasarinya. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten, lihat Peran dan tugas pengguna GKE umum. Google Cloud

Apa yang dimaksud dengan gangguan infrastruktur di GKE?

Cluster GKE Anda mengelola siklus proses node GKE. Node ini disediakan di VM Compute Engine, yang secara berkala mengalami gangguan berikut:

  • Perbaikan masalah yang terdeteksi (TerminationEvent): peristiwa ini terjadi karena Google Cloud mendeteksi masalah dan mengganggu infrastruktur cluster Anda. Peristiwa TerminationEvent tidak mendukung penonaktifan yang benar. Peristiwa TerminationEvent dipicu oleh masalah berikut:

    • Perbaikan otomatis terjadi saat GKE memperbaiki node setelah health check gagal berulang kali.
    • HostError terjadi saat error hardware atau software pada mesin fisik menyebabkan VM berhenti.

  • Peristiwa pemeliharaan atau upgrade (MaintenanceEvent): peristiwa ini terjadi saat Google Cloud harus menghentikan VM untuk melakukan pemeliharaan. Peristiwa ini dipicu oleh tugas pemeliharaan berikut:

    Untuk mengetahui informasi selengkapnya tentang cara Anda dan GKE mengelola perubahan selama siklus proses cluster, lihat Jenis perubahan.

  • Respons terhadap keputusan penjadwalan (PreemptionEvent): peristiwa ini terjadi saat Google Cloud harus menghentikan VM untuk menyediakan kapasitas bagi resource dengan prioritas lebih tinggi. Peristiwa PreemptionEvent dapat berupa salah satu dari berikut ini:

    • Penghentian paksa: terjadi saat infrastruktur preemptible atau Spot dihentikan paksa untuk mengakomodasi VM dengan prioritas lebih tinggi.
    • Defragmentasi: terjadi saat GKE menghentikan sementara slice TPU yang lebih kecil untuk mengakomodasi slice TPU yang lebih besar. Defragmentasi hanya terjadi pada slice TPU.

Selama siklus proses cluster GKE yang berjalan lama, node mungkin mengalami gangguan berkala pada workload. Jika gangguan ini memengaruhi node GKE yang menjalankan workload Anda, GKE harus memulai ulang workload yang sedang berjalan dan node yang mendasarinya.

Alasan node yang tidak mendukung migrasi langsung memerlukan pengelolaan gangguan

Sebagian besar VM Compute Engine, dengan beberapa pengecualian, memiliki kebijakan pemeliharaan host yang ditetapkan ke migrasi langsung, yang berarti bahwa workload yang sedang berjalan biasanya mengalami sedikit atau tidak ada gangguan. Namun, kelas VM tertentu tidak mendukung migrasi langsung, termasuk VM dengan GPU dan TPU yang terpasang, jenis mesin Z3 dengan SSD lebih dari 18 TiB, jenis mesin H4D, dan jenis mesin c4a-highmem-96-metal. Misalnya, saat peristiwa host terjadi pada VM dalam slice TPU, seluruh slice akan terganggu dan dijadwalkan ulang karena semua peristiwa pemeliharaan dikoordinasikan di tingkat slice. Jadi, jika Anda membuat slice TPU yang memiliki ratusan VM, semua VM tersebut akan menerima jadwal acara pemeliharaan yang sama.

Saat peristiwa host terjadi, GKE akan menghentikan node dan Pod-nya. Jika Pod di-deploy sebagai bagian dari workload yang lebih besar, seperti Job atau Deployment, GKE akan memulai ulang Pod di node yang terpengaruh.

Mengelola peristiwa pemeliharaan

Bagian lain dalam dokumen ini menjelaskan cara mengelola gangguan MaintenanceEvent.

Pengelolaan gangguan node selama peristiwa pemeliharaan host mengikuti alur kerja tiga tahap:

  1. Mendeteksi pemeliharaan host terjadwal: gunakan label node GKE, endpoint metadata, atau log.
  2. Tindakan atas pemeliharaan yang terdeteksi: jika pemeliharaan dijadwalkan, evaluasi infrastruktur dan workload Anda, lalu tentukan tindakan terbaik untuk kasus penggunaan Anda. Lakukan tindakan yang sesuai, seperti membiarkan sistem menangani peristiwa pemeliharaan secara otomatis, memulai pemeliharaan host secara manual, atau mengatur strategi pemeliharaan.
  3. Verifikasi hasil peristiwa pemeliharaan: verifikasi bahwa peristiwa pemeliharaan dimulai dengan benar, baik saat Compute Engine memulai peristiwa pemeliharaan sesuai jadwal atau saat Anda memulainya secara manual.

Mendeteksi pemeliharaan host terjadwal

Sebelum VM mengalami peristiwa pemeliharaan terjadwal, Compute Engine akan mengirimkan notifikasi ke semua VM-nya. Notifikasi ini melaporkan dimulainya periode pemeliharaan Compute Engine. Jika pemeliharaan mendatang dijadwalkan oleh VM, tetapi tidak aktif, GKE akan menambahkan scheduled-maintenance-time ke label node.

Untuk memantau dan mendeteksi peristiwa pemeliharaan mendatang, Anda harus melihat notifikasi dari GKE dan Compute Engine:

  • Melihat pemeliharaan mendatang di Compute Engine: Compute Engine mengeluarkan notifikasi saat node dan VM dasarnya dijadwalkan untuk peristiwa host yang mengganggu, dan saat peristiwa ini menjadi aktif. Notifikasi mencakup informasi tentang waktu mulai yang direncanakan, jenis acara, dan detail lainnya.

  • Melihat pemeliharaan mendatang di GKE: di GKE versi 1.31.1-gke.2008000 dan yang lebih baru, Anda dapat memantau peristiwa pemeliharaan mendatang. Anda dapat memantau acara mendatang untuk jenis mesin dan versi GKE berikut:

    • Untuk jenis mesin dengan GPU atau TPU terpasang, 1.31.1-gke.2008000 atau yang lebih baru
    • Untuk jenis mesin Z3 dengan SSD lebih dari 18 TiB, 1.32.4-gke.1376000 atau yang lebih baru
    • Untuk jenis mesin H4D, 1.32.6-gke.1060000 atau yang lebih baru
    • Untuk c4a-highmem-96-metal, 1.35.0-gke.2232000 atau yang lebih baru

    Untuk membuat kueri notifikasi ini di tingkat node, jalankan perintah berikut:

    kubectl get nodes -l cloud.google.com/scheduled-maintenance-time \
    -L cloud.google.com/scheduled-maintenance-time

    Outputnya mirip dengan hal berikut ini:

    NAME                         STATUS    SCHEDULED-MAINTENANCE-TIME
<gke-accelerator-node-name>  Ready     1733083200
<gke-accelerator-node-name>  Ready     1733083200
[...]

    Kolom SCHEDULED-MAINTENANCE-TIME mewakili detik, yang ditampilkan dalam format waktu epoch Unix.

    Untuk membuat kueri notifikasi ini di tingkat metadata node, periksa notifikasi peristiwa pemeliharaan untuk instance.

    Untuk kelompok mesin yang dioptimalkan untuk akselerator yang mendukung pemeliharaan lanjutan, Anda dapat mengakses endpoint upcoming-maintenance yang memberikan informasi tentang peristiwa pemeliharaan terjadwal dan yang dimulai.

Menindaklanjuti pemeliharaan yang terdeteksi

Jika Anda melihat pemberitahuan pemeliharaan terjadwal yang akan datang untuk satu atau beberapa node di cluster Anda, gunakan pohon keputusan berikut untuk menentukan cara terbaik menangani gangguan:

  1. Pemeliharaan otomatis: memungkinkan Compute Engine memulai peristiwa pemeliharaan sesuai jadwal. VM Anda akan otomatis dimigrasikan langsung di latar belakang dengan gangguan minimal atau tanpa gangguan.

    1. Jika VM host mendukung migrasi langsung, sebaiknya Anda membiarkan peristiwa pemeliharaan terjadi secara otomatis.
    2. Jika workload Anda berjalan di node fleksibel saat tidak ada aktivitas, Anda dapat mengoptimalkan waktu pemeliharaan secara otomatis dengan mengonfigurasi pemeliharaan oportunistik. Hal ini memicu update yang diperlukan hanya selama periode waktu tunggu alami.

  2. Mulai peristiwa pemeliharaan host secara manual: evaluasi pertanyaan berikut untuk menentukan cara terbaik menangani gangguan secara manual:

    1. Apakah node yang terpengaruh adalah VM tunggal atau terisolasi?

      • Ya (Saya menjalankan VM tunggal atau terisolasi):
        • Jika Anda tidak memerlukan kontrol pengaturan waktu yang presisi, izinkan Compute Engine memulai peristiwa pemeliharaan sesuai jadwal (otomatis default).
        • Jika Anda perlu menghindari penghentian sementara yang tidak terduga, mulai peristiwa pemeliharaan host secara manual di setiap node pada waktu yang tepat, misalnya, selama periode lalu lintas ringan.
      • Tidak (Saya menjalankan node pool akselerator): pilih salah satu opsi di langkah berikutnya.

    2. Pilih salah satu opsi berikut berdasarkan kasus penggunaan Anda:

      • Jika pool akselerator Anda menjalankan tugas pelatihan AI/ML yang digabungkan: terapkan strategi paralel. Simpan status pelatihan Anda ke checkpoint, matikan pool dengan benar, dan lakukan update host serta upgrade cluster GKE secara bersamaan sebelum memulai ulang.

      • Jika pool akselerator Anda menjalankan penayangan/inferensi AI/ML dengan ketersediaan tinggi atau endpoint inferensi: terapkan strategi rolling. Koordinasikan pemeliharaan host terjadwal dan upgrade versi dalam batch rolling dalam batas zona atau pool Anda, menggunakan replika aktif untuk melindungi SLA.

Memulai peristiwa pemeliharaan host secara manual pada VM tunggal atau terisolasi

Anda dapat memulai pemeliharaan yang dapat dijadwalkan ulang secara manual saat sesuai dengan jadwal Anda, seperti selama waktu aktivitas rendah. Untuk melakukannya, terapkan label cloud.google.com/perform-maintenance=true jika kondisi berikut terpenuhi:

  • Compute Engine mengeluarkan notifikasi tentang peristiwa pemeliharaan terjadwal.
  • Peristiwa pemeliharaan Compute Engine yang mendasarinya dapat dijadwalkan ulang. Untuk memeriksa apakah acara dapat dijadwalkan ulang, cari notifikasi can_reschedule=TRUE di metadata acara. Jika acara tidak dapat dijadwalkan ulang, setelan label cloud.google.com/perform-maintenance=true tidak akan berpengaruh, dan pemeliharaan akan dilakukan pada waktu yang dijadwalkan semula.

Jika kondisi sebelumnya terpenuhi, pada node di node pool, tetapkan label node cloud.google.com/perform-maintenance ke true. Contoh:

kubectl label nodes <node-name> cloud.google.com/perform-maintenance=true

Jika Anda memulai peristiwa pemeliharaan, GKE akan menjalankan operasi berikut:

  1. Mencemari node.
  2. Menghapus Pod secara terkendali.
  3. Meminta Compute Engine untuk segera memulai peristiwa pemeliharaan, bukan menunggu waktu yang dijadwalkan.

Memverifikasi hasil peristiwa pemeliharaan

Setelah mendeteksi peristiwa pemeliharaan mendatang dan memutuskan tindakan terbaik yang harus dilakukan, Anda dapat memverifikasi hasil peristiwa pemeliharaan.

Compute Engine memulai peristiwa pemeliharaan sesuai jadwal

Saat peristiwa pemeliharaan dimulai, node dapat dimatikan satu atau beberapa kali dengan waktu notifikasi singkat sebelum penghentiannya yang akan segera terjadi. Dalam kasus ini, GKE akan berupaya sebaik mungkin untuk menghentikan workload dan mengeluarkan Pod dengan benar.

Pemeliharaan terjadwal dimulai

Saat pemeliharaan terjadwal dimulai, Compute Engine akan memperbarui metadata di direktori http://metadata.google.internal/computeMetadata/v1/instance/attributes/. Compute Engine memperbarui label metadata sebagai berikut:

  • Menetapkan maintenance-event ke TERMINATE_ON_HOST_MAINTENANCE.
  • Di upcoming-maintenance, menetapkan maintenance_status ke ONGOING.

GKE mendeteksi dan menangani peristiwa pemeliharaan host terjadwal baik Anda memicunya secara manual atau membiarkan GKE melanjutkannya secara otomatis.

Metrik sistem GKE berikut melaporkan jumlah gangguan untuk node GKE sejak sampel terakhir (metrik diambil sampelnya setiap 60 detik):

  • kubernetes.io/node/interruption_count

Kolom interruption_type (seperti TerminationEvent, MaintenanceEvent, atau PreemptionEvent) dan interruption_reason (seperti HostError, Eviction, atau AutoRepair) dapat membantu memberikan alasan mengapa node terganggu.

Untuk mendapatkan perincian gangguan dan penyebabnya di node TPU dalam cluster di project Anda, gunakan kueri PromQL berikut:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node"}[${__interval}]))

Untuk hanya melihat peristiwa pemeliharaan host, perbarui kueri untuk memfilter nilai HW/SW Maintenance untuk interruption_reason. Gunakan kueri PromQL berikut:

  sum by (interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_interruption_count{monitored_resource="k8s_node", interruption_reason="HW/SW Maintenance"}[${__interval}]))

Untuk melihat jumlah gangguan yang dikelompokkan menurut node pool, gunakan kueri PromQL berikut:

  sum by (node_pool_name,interruption_type,interruption_reason)(
    sum_over_time(
      kubernetes_io:node_pool_interruption_count{monitored_resource="k8s_node_pool", interruption_reason="HW/SW Maintenance", node_pool_name=NODE_POOL_NAME }[${__interval}]))

Konfigurasi lanjutan untuk meminimalkan gangguan

Bagian ini menjelaskan alat tambahan untuk mengonfigurasi cluster dan workload Anda guna meminimalkan gangguan.

Mengaktifkan penanganan gangguan

apiVersion: v1
kind: ConfigMap
metadata:
  name: gke-disruption-handling
  namespace: kube-system
data:
  maintenance-experience.yaml: |
    gracefulTermination: true

Untuk mengaktifkan penanganan gangguan, buat file bernama maintenance-config.yaml dengan ConfigMap ini. Terapkan ConfigMap ke cluster dengan perintah berikut:

kubectl apply -f my-configmap.yaml

Mengonfigurasi GKE untuk menghentikan workload Anda dengan benar

Di bagian ini, Anda akan mengonfigurasi GKE untuk mengelola siklus proses aplikasi dan meminimalkan gangguan pada workload. Jika Anda tidak mengonfigurasi periode tenggang, periode tenggang akan ditetapkan secara default ke 30 detik.

GKE berupaya sebaik mungkin untuk menghentikan Pod ini secara terkendali dan untuk mengeksekusi tindakan penghentian yang Anda tentukan, misalnya, menyimpan status pelatihan. GKE mengirimkan sinyal SIGTERM ke Pod di awal masa tenggang. Jika Pod tidak keluar pada akhir periode tenggang, GKE akan mengirimkan sinyal SIGKILL lanjutan ke semua proses yang masih berjalan di semua container dalam Pod.

Untuk mengonfigurasi periode penghentian yang benar, tetapkan periode tenggang penghentian (detik) di kolom spec.terminationGracePeriodSeconds pada manifes Pod Anda. Misalnya, untuk mendapatkan waktu notifikasi 10 menit, tetapkan kolom spec.terminationGracePeriodSeconds di manifes Pod Anda ke 600 detik, seperti berikut:

    spec:
      terminationGracePeriodSeconds: 600

Sebaiknya tetapkan periode tenggang penghentian yang cukup lama agar semua tugas yang sedang berlangsung dapat diselesaikan dalam jangka waktu pemberitahuan. Jika workload Anda menggunakan framework ML seperti MaxText, Pax, atau JAX dengan Orbax, workload dapat merekam sinyal SIGTERM penonaktifan dan memulai proses pembuatan titik pemeriksaan. Untuk mempelajari lebih lanjut, lihat Pengecekan Otomatis TPU.

Proses penghentian tuntas

Saat peristiwa pemeliharaan yang dimulai secara manual dimulai, Compute Engine akan memberi sinyal penonaktifan mesin yang akan terjadi dengan memperbarui kunci metadata maintenance-event. GKE memulai penghentian secara tuntas.

Alur kerja berikut menunjukkan cara GKE mengeksekusi penghentian node yang benar saat ada penonaktifan node yang akan terjadi:

  1. Dalam waktu 60 detik, hal berikut akan terjadi:
    1. Komponen sistem menerapkan set label node cloud.google.com/active-node-maintenance yang ditetapkan ke ONGOING untuk menunjukkan bahwa workload sedang dihentikan.
    2. GKE menerapkan taint node untuk mencegah Pod baru dijadwalkan di node. Taint memiliki kunci cloud.google.com/impending-node-termination:NoSchedule. Sebaiknya Anda tidak memodifikasi workload untuk mentoleransi taint ini karena penghentian yang diketahui terjadi.
  2. Komponen maintenance-handler mulai mengeluarkan Pod dengan terlebih dahulu mengeluarkan Pod workload, lalu mengeluarkan Pod sistem (misalnya, kube-system).
  3. GKE mengirimkan sinyal penonaktifan SIGTERM ke Pod workload yang berjalan di node untuk memberi tahu mereka tentang penonaktifan yang akan segera terjadi. Pod dapat menggunakan pemberitahuan ini untuk menyelesaikan tugas yang sedang berlangsung. GKE berupaya semaksimal mungkin untuk menghentikan Pod ini secara terkendali.
  4. Setelah penghapusan selesai, GKE akan mengupdate nilai label cloud.google.com/active-node-maintenance menjadi terminating untuk menunjukkan bahwa node siap dihentikan.

Setelah itu, penghentian node terjadi dan node pengganti dialokasikan. GKE akan menghapus label dan taint setelah proses selesai. Untuk memperpanjang periode penghentian untuk workload Anda yang menggunakan GPU atau TPU, selesaikan langkah-langkah di bagian Mulai peristiwa pemeliharaan host secara manual.

Memverifikasi progres penghentian sementara yang aktif

Anda dapat memfilter log GKE berdasarkan peristiwa penghentian yang benar (graceful termination) berikut:

  • Saat VM mendeteksi gangguan karena penghentian node yang akan terjadi seperti peristiwa pemeliharaan host Compute Engine, GKE akan menyetel cloud.google.com/active-node-maintenance ke ONGOING saat beban kerja dihentikan, dan ke terminating saat beban kerja selesai dan node siap dihentikan.
  • Saat membatasi penjadwalan workload baru, GKE menerapkan taint cloud.google.com/impending-node-termination:NoSchedule.

Meminimalkan gangguan pada workload yang sedang berjalan dengan pemeliharaan oportunistik

Anda dapat meminimalkan gangguan pada workload yang sedang berjalan dengan memicu pemeliharaan secara otomatis saat GKE mendeteksi bahwa node dengan GPU atau TPU sedang tidak digunakan. Untuk mengaktifkan fitur ini, buat node pool baru. Anda tidak dapat mengaktifkan pemeliharaan oportunistik pada node pool yang sudah ada.

Membuat node pool baru dengan pemeliharaan oportunistik

Perintah berikut menunjukkan cara membuat node pool dengan pemeliharaan oportunistik yang diaktifkan:

gcloud beta container node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --accelerator ACCELERATOR_ARG \
    --machine-type MACHINE_TYPE \
    --num-nodes NODE_COUNT \
    --zone ZONE \
    --project=PROJECT_ID \
    --opportunistic-maintenance=node-idle-time=NODE_IDLE_TIME,min-nodes=MIN_NODES,window=WINDOW

Ganti nilai berikut:

  • NODE_POOL_NAME: nama node pool GKE Anda.
  • CLUSTER_NAME : nama cluster GKE Anda.
  • NODE_IDLE_TIME : jangka waktu node dapat tetap tidak aktif (yaitu, tidak ada workload yang menggunakan akselerator yang berjalan) sebelum pemeliharaan dipicu. Nilai ini merepresentasikan durasi dalam detik, dengan maksimal sembilan digit pecahan, dan diakhiri dengan karakter s, misalnya: 80000s.
  • MIN_NODES : jumlah minimum node yang harus tersedia di node pool. Opsi ini memblokir pemeliharaan jika menyebabkan jumlah node yang berjalan berada di bawah nilai ini, misalnya: 10.
  • WINDOW : jangka waktu, dalam detik, saat pemeliharaan oportunistik dapat berjalan. Nilai diakhiri dengan karakter s. Misalnya, nilai 14 hari, atau 1209600s, menyiratkan bahwa pemeliharaan oportunistik hanya dapat dijalankan dalam dua minggu sebelum tanggal pemeliharaan terjadwal. Nilai 28 hari, atau 2419200s, memungkinkan pemeliharaan oportunistik dijalankan kapan saja selama masa pemeliharaan terjadwal. Jangka waktu untuk pemeliharaan host Compute Engine ini berbeda dengan jangka waktu pemeliharaan GKE, yang menentukan kapan pemeliharaan cluster GKE dapat terjadi dan dikonfigurasi secara terpisah.

Contoh konfigurasi untuk pemeliharaan oportunistik

Perhatikan contoh berikut. Anda memiliki node pool dengan empat node dan konfigurasi pemeliharaan oportunistik disetel ke --opportunistic-maintenance=node-idle-time=600s,window=2419200s,min-nodes=3. Dalam skenario ini, hal berikut terjadi:

  • node1 menjalankan workload GPU. Node ini tidak dalam kondisi tidak ada aktivitas, jadi dilewati.
  • node2 tidak aktif selama 60 detik. Node ini belum tidak ada aktivitas selama waktu yang cukup, jadi dilewati.
  • node3 tidak ada aktivitas selama 600 detik. Node ini memenuhi persyaratan tidak ada aktivitas.
  • node4 tidak ada aktivitas selama 600 detik. Node ini memenuhi persyaratan tidak ada aktivitas.

node3 dan node4 memenuhi persyaratan tidak ada aktivitas. Namun, hanya satu dari node ini yang akan memicu pemeliharaan oportunistik karena nilai opsi min-nodes ditetapkan ke 3.

Memeriksa konfigurasi dan status node dengan pemeliharaan oportunistik

Periksa apakah pemeliharaan oportunistik dikonfigurasi untuk node dengan menjalankan perintah berikut:

kubectl describe node NODE_NAME | grep node.gke.io/opportunistic-config

Ganti NODE_NAME dengan nama node yang ingin Anda periksa.

Periksa apakah node yang dikonfigurasi dengan pemeliharaan oportunistik sedang menjalani pemeliharaan:

kubectl describe node NODE_NAME | grep node.gke.io/maintenance-state

Jika node dipicu oleh pemeliharaan oportunistik, anotasi maintenance-state menampilkan opportunistic-triggered sebagai true.

Batasan

Perhatikan batasan pemeliharaan oportunistik berikut:

  • Fitur ini hanya dapat digunakan dengan node pool GPU dan TPU.
  • Pemeliharaan oportunistik tidak kompatibel dengan penskalaan otomatis cluster karena penskalaan otomatis cluster sudah menurunkan skala node yang tidak ada aktivitas.
  • Untuk node pool TPU multi-host, nilai setelan min-nodes-per-pool harus 0 karena node pool ini bersifat atomik.
  • Versi GKE minimum yang didukung adalah 1.33.3-gke.1118000.
  • Hanya pemeliharaan terencana yang mencakup can_reschedule=TRUE notifikasi yang didukung.
  • Untuk menonaktifkan fitur ini, Anda harus membuat ulang node pool tanpa tanda yang sesuai. Atau, Anda dapat menonaktifkan fitur ini secara manual di node tertentu dengan cloud.google.com/opportunistic-disable=true.
  • Dalam kasus yang jarang terjadi, pemeliharaan mungkin memerlukan waktu lebih lama untuk diselesaikan di sebuah node. Pelanggan yang menggunakan fitur ini mungkin mengalami lebih sedikit node yang tersedia, hingga nilai setelan min-nodes-per-pool, selama jangka waktu tertentu.

Langkah berikutnya