Memahami cara melakukan pemeliharaan host di GKE

Selama siklus proses cluster GKE yang berjalan lama, gangguan berkala pada workload terjadi karena gangguan infrastruktur yang Google Cloud menyebabkan masalah. Peristiwa otomatis ini dapat terjadi untuk merespons keputusan penjadwalan (peristiwa preemption), 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 dan meminimalkan dampak gangguan di node GKE Anda.

Untuk mengetahui detail tentang cara memantau notifikasi dan peristiwa pemeliharaan, lihat Memantau peristiwa pemeliharaan.

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 Google Cloud konten, lihat Peran dan tugas pengguna GKE umum.

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 penghentian terkendali. Peristiwa TerminationEvent dipicu oleh masalah berikut:

    • Perbaikan otomatis terjadi saat GKE memperbaiki node setelah health check berulang kali gagal.
    • 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 mengganggu 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 melakukan preemption VM untuk menyediakan kapasitas bagi resource berprioritas lebih tinggi. Peristiwa PreemptionEvent dapat berupa salah satu hal berikut:

    • Penghapusan: terjadi saat preemptible atau Spot infrastruktur di-preempt untuk mengakomodasi VM berprioritas lebih tinggi.
    • Defragmentasi: terjadi saat GKE melakukan preemption pada 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. Saat gangguan ini memengaruhi node GKE yang menjalankan workload Anda, GKE harus memulai ulang workload yang berjalan dan node yang mendasarinya.

Mengapa node yang tidak mendukung migrasi langsung memerlukan pengelolaan gangguan

Sebagian besar VM Compute Engine, dengan beberapa pengecualian, memiliki kebijakan pemeliharaan host yang ditetapkan untuk migrasi langsung, yang berarti bahwa workload yang berjalan biasanya mengalami sedikit atau tidak ada gangguan. Namun, kelas VM tertentu tidak mendukung migrasi langsung, termasuk VM dengan GPU dan TPU terpasang, jenis mesin Z3 dengan lebih dari 18 TiB SSD, jenis mesin H4D, dan jenisc4a-highmem-96-metal mesin. Misalnya, saat peristiwa host terjadi pada VM dalam slice TPU, seluruh slice akan terganggu dan kemudian 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 peristiwa pemeliharaan yang sama.

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

Mengelola peristiwa pemeliharaan

Bagian selanjutnya dari 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. Menindaklanjuti 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. Memverifikasi 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

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

Untuk mengetahui detail tentang cara memantau notifikasi dan peristiwa pemeliharaan, lihat Memantau peristiwa pemeliharaan.

Menindaklanjuti pemeliharaan yang terdeteksi

Jika Anda melihat notifikasi pemeliharaan terjadwal mendatang untuk satu atau beberapa node di cluster Anda, gunakan pohon keputusan berikut untuk menentukan cara terbaik menangani gangguan:

  1. Pemeliharaan otomatis: izinkan 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 izinkan peristiwa pemeliharaan terjadi secara otomatis.
    2. Jika workload Anda berjalan di node fleksibel yang tidak digunakan, Anda dapat mengoptimalkan waktu pemeliharaan secara otomatis dengan mengonfigurasi pemeliharaan oportunistik. Hal ini hanya memicu update yang diperlukan selama periode waktu tidak aktif alami.

  2. Memulai 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 waktu yang presisi, izinkan Compute Engine memulai peristiwa pemeliharaan sesuai jadwal (otomatis default).
        • Jika Anda perlu menghindari preemption yang tidak terduga, mulai peristiwa pemeliharaan host secara manual di node individual pada waktu yang tepat, misalnya, selama periode traffic rendah.
      • 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, hentikan pool secara terkendali, dan lakukan update host serta upgrade cluster GKE secara bersamaan sebelum memulai ulang.

      • Jika pool akselerator Anda menjalankan penayangan 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 di 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 mengirimkan notifikasi tentang peristiwa pemeliharaan terjadwal.
  • Peristiwa pemeliharaan Compute Engine yang mendasarinya dapat dijadwalkan ulang. Untuk memeriksa apakah peristiwa dapat dijadwalkan ulang, cari notifikasi can_reschedule=TRUEdi metadata peristiwa. Jika peristiwa tidak dapat dijadwalkan ulang, menetapkan label cloud.google.com/perform-maintenance=true tidak akan berpengaruh, dan pemeliharaan akan terjadi pada waktu yang dijadwalkan semula.

Jika kondisi sebelumnya terpenuhi, di node dalam 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. Melakukan taint pada node.
  2. Mengeluarkan 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, Anda dapat memverifikasi hasil peristiwa pemeliharaan.

Compute Engine memulai peristiwa pemeliharaan sesuai jadwal

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

Pemeliharaan terjadwal dimulai

Saat pemeliharaan terjadwal dimulai, Compute Engine akan mengupdate metadata di direktori http://metadata.google.internal/computeMetadata/v1/instance/attributes/. Compute Engine mengupdate 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 melanjutkan 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 , update 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 diagregasi 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 secara terkendali

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

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

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

    spec:
      terminationGracePeriodSeconds: 600

Sebaiknya tetapkan masa tenggang penghentian yang cukup lama agar tugas yang sedang berlangsung dapat selesai dalam jangka waktu notifikasi. Jika workload Anda menggunakan framework ML seperti MaxText, Pax, atau JAX dengan Orbax, workload dapat menangkap sinyal SIGTERM penghentian dan memulai proses checkpoint. Untuk mempelajari lebih lanjut, lihat Checkpoint Otomatis TPU.

Proses penghentian terkendali

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

Alur kerja berikut menunjukkan cara GKE menjalankan penghentian node terkendali saat ada penghentian node yang akan segera terjadi:

  1. Dalam waktu 60 detik, hal berikut akan terjadi:
    1. Komponen sistem menerapkan 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 jangan ubah workload Anda untuk mentoleransi taint ini karena penghentian yang diketahui terjadi.
  2. Komponen maintenance-handler mulai mengeluarkan Pod dengan mengeluarkan Pod workload terlebih dahulu, lalu mengeluarkan Pod sistem (misalnya, kube-system).
  3. GKE mengirimkan sinyal penghentian SIGTERM ke Pod workload yang berjalan di node untuk memberi tahu mereka tentang penghentian yang akan segera terjadi. Pod dapat menggunakan pemberitahuan ini untuk menyelesaikan tugas yang sedang berlangsung. GKE berupaya sebaik mungkin untuk menghentikan Pod ini secara terkendali.
  4. Setelah penghapusan selesai, GKE akan mengupdate nilai label cloud.google.com/active-node-maintenance ke terminating untuk menunjukkan bahwa node siap dihentikan.

Setelah itu, penghentian node akan terjadi dan node pengganti akan dialokasikan. GKE menghapus label dan taint saat proses selesai. Untuk meningkatkan jangka waktu penghentian workload Anda menggunakan GPU atau TPU, selesaikan langkah-langkah di bagian Memulai peristiwa pemeliharaan host secara manual.

Memverifikasi progres penghentian terkendali yang aktif

Anda dapat memfilter log GKE berdasarkan peristiwa penghentian terkendali berikut:

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

Meminimalkan gangguan pada workload yang berjalan dengan pemeliharaan oportunistik

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

Membuat node pool baru dengan pemeliharaan oportunistik

Perintah berikut menunjukkan cara membuat node pool dengan pemeliharaan oportunistik 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 : jumlah waktu node dapat tetap tidak digunakan (yaitu, tidak ada workload yang menggunakan akselerator berjalan) sebelum pemeliharaan dipicu. Nilai ini mewakili 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, pemeliharaan oportunistik dapat berjalan. Nilai ini diakhiri dengan karakter s. Misalnya, nilai 14 hari, atau 1209600s, menunjukkan bahwa pemeliharaan oportunistik hanya dapat dijalankan dalam dua minggu sebelum tanggal pemeliharaan terjadwal. Nilai 28 hari, atau 2419200s, memungkinkan pemeliharaan oportunistik berjalan kapan saja selama masa pemeliharaan terjadwal. Jangka waktu untuk pemeliharaan host Compute Engine ini berbeda dengan masa 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 ditetapkan ke --opportunistic-maintenance=node-idle-time=600s,window=2419200s,min-nodes=3. Dalam skenario ini, hal berikut akan terjadi:

  • node1 memiliki workload GPU yang berjalan di dalamnya. Node ini tidak tidak digunakan, sehingga dilewati.
  • node2 tidak ada aktivitas selama 60 detik. Node ini belum tidak digunakan dalam waktu yang cukup lama, sehingga dilewati.
  • node3 tidak ada aktivitas selama 600 detik. Node ini memenuhi persyaratan tidak digunakan.
  • node4 tidak ada aktivitas selama 600 detik. Node ini memenuhi persyaratan tidak digunakan.

node3 dan node4 memenuhi persyaratan tidak ada aktivitas. Namun, hanya salah satu 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 akan 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 autoscaler cluster sudah mengecilkan skala node yang tidak digunakan.
  • 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 menyertakan can_reschedule=TRUE notifikasi yang didukung.
  • Untuk menonaktifkan fitur ini, Anda harus membuat ulang node pool tanpa flag 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 node. Pelanggan yang menggunakan fitur ini mungkin mengalami lebih sedikit node yang tersedia, hingga nilai setelan min-nodes-per-pool, untuk jangka waktu tertentu.

Langkah berikutnya