Mengelola gangguan pada node GKE yang tidak melakukan migrasi langsung

Selama siklus proses cluster GKE yang berjalan lama, gangguan berkala pada workload terjadi karena gangguan infrastruktur yang Cloud de Confiance by S3NS 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, 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 teknologi yang mendasarinya. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam Cloud de Confiance by S3NS 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 Cloud de Confiance by S3NS mendeteksi masalah dan mengganggu infrastruktur cluster Anda. Peristiwa TerminationEvent tidak mendukung penghentian tuntas. 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 Cloud de Confiance by S3NS perlu mengganggu VM untuk melakukan pemeliharaan. Peristiwa MaintenanceEvent dipicu oleh tugas pemeliharaan berikut:

    • Peristiwa pemeliharaan terjadi saat Cloud de Confiance by S3NS mengupgrade host yang mendasarinya.
    • Update node, yang mencakup node upgrade otomatis, terjadi saat GKE mengupdate konfigurasi node, seperti versi GKE.

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

  • Respons terhadap keputusan penjadwalan (PreemptionEvent): terjadi saat Cloud de Confiance by S3NS perlu melakukan preemption pada 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 mengakodasi 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. Jika gangguan ini memengaruhi node GKE yang menjalankan workload Anda, GKE perlu memulai ulang workload yang berjalan dan node yang mendasarinya.

Alasan node tanpa migrasi langsung memerlukan pengelolaan gangguan

Sebagian besar VM Compute Engine, dengan beberapa pengecualian, memiliki kebijakan pemeliharaan host yang ditetapkan untuk migrasi langsung, yang berarti 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 SSD lebih dari 18 TiB, jenis mesin H4D, dan jenis mesin c4a-highmem-96-metal (Pratinjau). 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.

Anda, atau framework yang Anda gunakan, harus menangani konfigurasi workload untuk bereaksi dengan tepat terhadap peristiwa pemeliharaan. Misalnya, Anda dapat menyimpan status tugas pelatihan AI untuk mengurangi kehilangan data.

Untuk mengelola gangguan pada workload, Anda dapat melakukan hal berikut:

Memantau gangguan node

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 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}]))

Memantau notifikasi pemeliharaan

Compute Engine issues notifikasi saat node dan VM yang mendasarinya dijadwalkan untuk peristiwa host yang mengganggu, dan saat peristiwa ini menjadi aktif. Notifikasi ini mencakup informasi tentang waktu mulai yang direncanakan, jenis peristiwa, dan detail lainnya.

Di GKE versi 1.31.1-gke.2008000 dan yang lebih baru, Anda dapat memantau peristiwa pemeliharaan mendatang, termasuk peristiwa yang dijelaskan di bagian ini.

Anda dapat memantau peristiwa mendatang dengan 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 (Pratinjau), 1.35.0-gke.2232000 atau yang lebih baru

Pemeliharaan mendatang dijadwalkan tetapi tidak aktif

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

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 instance untuk notifikasi peristiwa pemeliharaan.

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

Meminimalkan dampak gangguan

Compute Engine mengeluarkan notifikasi tentang peristiwa pemeliharaan mendatang dan menjadwalkan masa pemeliharaan. Antara waktu notifikasi dan waktu mulai masa pemeliharaan, Anda dapat memutuskan untuk:

  • Memulai peristiwa pemeliharaan host secara manual.
  • Mengizinkan Compute Engine memulai peristiwa pemeliharaan sesuai jadwal.

GKE mendukung penghentian tuntas Pod selama peristiwa pemeliharaan host. Di versi GKE terbaru, fitur ini dinonaktifkan secara default. Untuk menggunakan fitur ini, Anda harus mengaktifkan penanganan gangguan secara manual. Untuk mengetahui informasi selengkapnya, lihat Mengaktifkan penanganan gangguan.

Memulai peristiwa pemeliharaan host secara manual

Anda dapat memulai pemeliharaan yang dapat dijadwalkan ulang secara manual jika sesuai dengan jadwal Anda, seperti saat 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 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 awalnya dijadwalkan.

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. Melakukan taint pada node.
  2. Mengeluarkan Pod secara tuntas.
  3. Meminta Compute Engine untuk segera memulai peristiwa pemeliharaan, bukan menunggu waktu yang dijadwalkan.

Compute Engine memulai peristiwa pemeliharaan sesuai jadwal

Jika Anda tidak memulai peristiwa pemeliharaan host, Compute Engine akan memulai peristiwa pemeliharaan terjadwal dengan sendirinya. Mulai GKE versi 1.33, node tidak di-taint dan Pod tidak dikeluarkan saat masa pemeliharaan dimulai.

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 akan berupaya sebaik mungkin untuk menghentikan workload dan mengeluarkan Pod secara tuntas .

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 maupun membiarkan GKE melanjutkan secara otomatis.

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 tuntas

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 akan berupaya sebaik mungkin untuk menghentikan Pod ini secara tuntas 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 tuntas, 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 diselesaikan 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 pembuatan checkpoint. Untuk mempelajari lebih lanjut, lihat Checkpoint Otomatis TPU.

Proses penghentian tuntas

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 tuntas.

Alur kerja berikut menunjukkan cara GKE menjalankan penghentian node tuntas saat penghentian node 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 akan berupaya sebaik mungkin untuk menghentikan Pod ini secara tuntas.
  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.

Memantau progres penghentian tuntas yang aktif

Anda dapat memfilter log GKE berdasarkan peristiwa penghentian tuntas 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 workload yang berjalan dengan pemeliharaan oportunistik

Anda dapat meminimalkan gangguan workload yang berjalan dengan memicu pemeliharaan secara otomatis saat GKE mendeteksi bahwa node dengan GPU atau TPU tidak ada aktivitas. 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 ada aktivitas (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 ada aktivitas, sehingga dilewati.
  • node2 tidak ada aktivitas selama 60 detik. Node ini tidak ada aktivitas dalam waktu yang cukup lama, sehingga 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 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 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 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