Masa dan pengecualian pemeliharaan

Halaman ini menjelaskan masa pemeliharaan dan pengecualian pemeliharaan, yang merupakan kebijakan yang memberikan kontrol atas kapan beberapa pemeliharaan cluster, seperti upgrade otomatis, dapat dan tidak dapat terjadi di cluster Google Kubernetes Engine (GKE) Anda. Misalnya, bisnis retail dapat membatasi pemeliharaan agar hanya terjadi pada malam hari kerja, dan dapat mencegah pemeliharaan otomatis selama peristiwa penjualan penting dalam industri.

Tentang kebijakan pemeliharaan GKE

Kebijakan pemeliharaan GKE, yang mencakup masa pemeliharaan dan pengecualian, memberi Anda kontrol atas kapan pemeliharaan otomatis tertentu dapat terjadi di cluster, termasuk upgrade cluster dan perubahan lain pada konfigurasi node, atau topologi jaringan cluster.

Masa pemeliharaan adalah periode waktu berulang saat pemeliharaan otomatis GKE diizinkan.

Pengecualian pemeliharaan adalah periode waktu yang tidak berulang saat pemeliharaan otomatis GKE dilarang.

GKE membuat perubahan otomatis yang mematuhi kebijakan pemeliharaan cluster Anda saat ada masa pemeliharaan yang terbuka dan tidak ada pengecualian pemeliharaan yang aktif. Untuk setiap cluster, Anda dapat mengonfigurasi satu periode pemeliharaan berulang, dan beberapa pengecualian pemeliharaan.

Jenis pemeliharaan lainnya tidak bergantung pada kebijakan pemeliharaan GKE, termasuk operasi perbaikan bidang kontrol, dan pemeliharaan layanan yang menjadi dependensi GKE, seperti Compute Engine. Untuk mempelajari lebih lanjut, lihat Pemeliharaan otomatis yang tidak mematuhi kebijakan pemeliharaan.

Perubahan yang mematuhi dan tidak mematuhi kebijakan pemeliharaan GKE

Sebelum mengonfigurasi kebijakan pemeliharaan GKE—masa pemeliharaan dan pengecualian—tinjau bagian berikut untuk memahami cara GKE dan layanan terkait mematuhi dan tidak mematuhinya.

Pemeliharaan otomatis yang mengikuti kebijakan pemeliharaan GKE

Dengan kebijakan pemeliharaan GKE, Anda dapat mengontrol waktu jenis peristiwa berikut, yang menyebabkan gangguan sementara pada cluster Anda:

Jenis pemeliharaan otomatis lainnya tidak bergantung pada kebijakan pemeliharaan. Untuk mempelajari lebih lanjut, lihat Pemeliharaan otomatis yang tidak mematuhi kebijakan pemeliharaan.

Pemeliharaan otomatis yang tidak mematuhi kebijakan pemeliharaan GKE

Masa dan pengecualian pemeliharaan GKE tidak memblokir semua jenis pemeliharaan otomatis. Sebelum mengonfigurasi kebijakan pemeliharaan cluster GKE, pastikan Anda memahami jenis perubahan yang tidak mengikuti masa dan pengecualian pemeliharaan.

Pemeliharaan Google Cloud lainnya

Masa dan pengecualian pemeliharaan GKE tidak mencegah pemeliharaan otomatis layanan Google Cloud yang mendasarinya, terutama Compute Engine, atau layanan yang menginstal aplikasi ke cluster, seperti Cloud Deploy.

Misalnya, node GKE adalah VM Compute Engine yang dikelola GKE untuk cluster Anda. VM Compute Engine terkadang mengalami peristiwa host, yang dapat mencakup peristiwa pemeliharaan atau error host. Perilaku VM selama peristiwa ini ditentukan oleh kebijakan pemeliharaan host VM, yang secara default untuk sebagian besar VM berarti migrasi langsung. Hal ini biasanya berarti periode nonaktif yang sedikit atau tidak ada untuk node, dan, untuk sebagian besar beban kerja, kebijakan default sudah memadai. Untuk beberapa keluarga mesin VM, Anda dapat memantau dan merencanakan peristiwa pemeliharaan host dan memicu peristiwa pemeliharaan host untuk menyesuaikan waktunya dengan kebijakan pemeliharaan GKE Anda.

Beberapa VM, termasuk yang memiliki GPU dan TPU, tidak dapat melakukan migrasi langsung. Jika Anda menggunakan akselerator ini, pelajari cara menangani gangguan karena pemeliharaan node untuk GPU atau TPU.

Sebaiknya tinjau informasi tentang peristiwa host, kebijakan pemeliharaan host, dan konfirmasi bahwa workload Anda siap menghadapi gangguan, terutama jika workload tersebut berjalan di node yang tidak dapat melakukan migrasi langsung.

Perbaikan dan pengubahan ukuran otomatis

GKE melakukan perbaikan otomatis pada panel kontrol. Hal ini mencakup proses seperti meningkatkan skala panel kontrol ke ukuran yang sesuai atau memulai ulang panel kontrol untuk menyelesaikan masalah. Sebagian besar perbaikan mengabaikan masa pemeliharaan dan pengecualian karena kegagalan dalam melakukan perbaikan dapat mengakibatkan cluster yang tidak berfungsi.

Anda tidak dapat menonaktifkan perbaikan panel kontrol. Namun, sebagian besar jenis cluster, termasuk cluster Autopilot dan cluster regional Standar memiliki beberapa replika bidang kontrol, yang memungkinkan ketersediaan server Kubernetes API yang tinggi, bahkan selama peristiwa pemeliharaan. Cluster zona standar, yang hanya memiliki satu bidang kontrol, tidak dapat diubah selama perubahan konfigurasi bidang kontrol dan pemeliharaan cluster. Hal ini mencakup deployment beban kerja.

Node juga memiliki fungsi perbaikan otomatis, yang dapat Anda nonaktifkan untuk cluster Standar.

Patching kerentanan keamanan yang penting

Masa dan pengecualian pemeliharaan dapat menyebabkan patch keamanan tertunda. Namun, GKE berhak untuk mengabaikan kebijakan pemeliharaan untuk kerentanan keamanan kritis.

Perubahan manual yang mengikuti kebijakan pemeliharaan GKE

Beberapa perubahan pada node atau konfigurasi jaringan mengharuskan node dibuat ulang untuk menerapkan konfigurasi baru, termasuk beberapa perubahan berikut:

Perubahan ini mengikuti kebijakan pemeliharaan GKE, yang berarti bahwa GKE menunggu masa pemeliharaan yang terbuka dan menunggu tidak ada pengecualian pemeliharaan aktif yang mencegah pemeliharaan node. Untuk menerapkan perubahan pada node secara manual, gunakan Google Cloud CLI untuk memanggil perintah gcloud container clusters upgrade dan meneruskan flag --cluster-version dengan versi GKE yang sama dengan yang sudah dijalankan node pool.

Perubahan manual yang tidak mematuhi kebijakan pemeliharaan GKE

Beberapa perubahan manual akan langsung membuat ulang node menggunakan strategi upgrade node tanpa mengikuti kebijakan pemeliharaan. Untuk mengetahui detail selengkapnya, lihat Perubahan manual yang membuat ulang node menggunakan strategi upgrade node tanpa mematuhi kebijakan pemeliharaan.

Masa pemeliharaan

Masa pemeliharaan memungkinkan Anda mengontrol kapan upgrade otomatis panel kontrol dan node dapat terjadi, untuk memitigasi potensi gangguan sementara pada workload. Periode pemeliharaan berguna untuk jenis skenario berikut, di antaranya:

  • Di luar jam sibuk: Anda ingin meminimalkan peluang periode nonaktif dengan menjadwalkan upgrade otomatis di luar jam sibuk saat traffic sedang turun.
  • Jam kerja: Anda ingin memastikan bahwa upgrade terjadi selama jam kerja agar ada orang yang dapat memantau upgrade dan mengelola masalah yang tidak terduga.
  • Upgrade multi-cluster: Anda ingin meluncurkan upgrade di beberapa cluster di region yang berbeda satu per satu pada interval yang ditentukan.

Selain upgrade otomatis, terkadang Google mungkin perlu melakukan tugas pemeliharaan lainnya, dan mematuhi masa pemeliharaan cluster jika memungkinkan.

Jika tugas berjalan melebihi masa pemeliharaan, GKE akan mencoba menjeda tugas, dan berupaya melanjutkan tugas tersebut pada masa pemeliharaan berikutnya.

GKE berhak meluncurkan upgrade darurat yang tidak terencana di luar periode pemeliharaan. Selain itu, upgrade wajib dari software yang tidak digunakan lagi atau yang sudah usang dapat otomatis terjadi di luar masa pemeliharaan.

Guna mempelajari cara menyiapkan masa pemeliharaan untuk cluster baru atau yang sudah ada, silakan melihat Mengonfigurasi masa pemeliharaan.

Zona waktu untuk masa pemeliharaan

Saat mengonfigurasi dan melihat masa pemeliharaan, waktu ditampilkan secara berbeda, bergantung pada alat yang Anda gunakan:

Saat mengonfigurasi masa pemeliharaan

Waktu selalu disimpan dalam UTC. Namun, saat mengonfigurasi periode pemeliharaan, Anda dapat menggunakan UTC atau zona waktu lokal.

Saat mengonfigurasi periode pemeliharaan menggunakan flag --maintenance-window yang lebih umum, Anda tidak dapat menentukan zona waktu. UTC digunakan saat menggunakan gcloud CLI atau API, dan Konsol Google Cloud menampilkan waktu menggunakan zona waktu lokal.

Saat menggunakan flag yang lebih terperinci, seperti --maintenance-window-start, Anda dapat menentukan zona waktu sebagai bagian dari nilai. Jika Anda menghilangkan zona waktu, zona waktu lokal Anda akan digunakan.

Saat melihat masa pemeliharaan

Saat melihat informasi tentang cluster, stempel waktu untuk periode pemeliharaan dapat ditampilkan dalam UTC atau zona waktu lokal Anda, bergantung pada cara Anda melihat informasi:

  • Saat menggunakan Konsol Google Cloud untuk melihat informasi tentang cluster Anda, waktu selalu ditampilkan dalam zona waktu lokal Anda.
  • Saat menggunakan gcloud CLI untuk melihat informasi tentang cluster Anda, waktu selalu ditampilkan dalam UTC.

Dalam kedua kasus tersebut, RRULE selalu ditampilkan dalam UTC. Artinya, jika Anda menentukan, misalnya, hari, maka hari tersebut akan ditampilkan dalam UTC.

Pengecualian pemeliharaan

Dengan pengecualian pemeliharaan, Anda dapat mencegah agar pemeliharaan otomatis tidak terjadi selama jangka waktu tertentu. Misalnya, banyak bisnis retail yang memiliki pedoman bisnis yang melarang perubahan infrastruktur selama liburan akhir tahun. Contoh lainnya, jika perusahaan menggunakan API yang dijadwalkan untuk tidak digunakan lagi, perusahaan tersebut dapat menggunakan pengecualian pemeliharaan untuk menjeda upgrade kecil guna memberi perusahaan waktu untuk memigrasikan aplikasi.

Untuk peristiwa berdampak tinggi yang diketahui, sebaiknya cocokkan batasan perubahan internal dengan pengecualian pemeliharaan yang dimulai satu minggu sebelum peristiwa tersebut, dan berlangsung selama durasi peristiwa.

Pengecualian tidak berulang. Sebagai gantinya, buat setiap instance pengecualian berkala secara terpisah.

Jika pengecualian dan masa pemeliharaan tumpang tindih, pengecualian akan diprioritaskan.

Guna mempelajari cara menyiapkan pengecualian pemeliharaan untuk cluster baru atau yang sudah ada, silakan melihat Mengonfigurasi pengecualian pemeliharaan.

Cakupan pemeliharaan yang akan dikecualikan

Anda tidak hanya dapat menentukan waktu untuk mencegah pemeliharaan otomatis pada cluster, tetapi Anda juga dapat membatasi cakupan update otomatis yang mungkin terjadi. Cakupan pengecualian pemeliharaan berguna untuk jenis skenario berikut, di antaranya:

  • Tidak ada upgrade - hindari pemeliharaan apa pun: Anda ingin menghindari perubahan apa pun pada cluster untuk sementara selama jangka waktu tertentu. Ini adalah cakupan default.
  • Tidak ada upgrade minor - pertahankan versi minor Kubernetes saat ini: Anda ingin mempertahankan versi minor cluster untuk sementara guna menghindari perubahan API atau memvalidasi versi minor berikutnya.
  • Tidak ada upgrade minor atau node - cegah gangguan node: Anda ingin menghindari penghentian dan penjadwalan ulang apa pun pada workload karena upgrade node untuk sementara.

Tabel berikut mencantumkan cara setiap cakupan ini membatasi upgrade minor atau patch untuk node atau bidang kontrol cluster.

Saat GKE mengupgrade cluster, VM untuk control plane dan node akan dimulai ulang. Untuk bidang kontrol, cluster Autopilot dan Standar regional mempertahankan ketersediaan server Kubernetes API. Di cluster zona, yang memiliki satu node bidang kontrol, mulai ulang VM akan membuat bidang kontrol tidak tersedia untuk sementara. Untuk node, peristiwa mulai ulang VM akan memicu penjadwalan ulang Pod yang dapat mengganggu workload yang ada untuk sementara. Anda dapat menetapkan toleransi untuk gangguan workload menggunakan Anggaran Gangguan Pod (PDB).

Cakupan Bidang kontrol Node
Upgrade minor otomatis Upgrade patch otomatis Upgrade minor otomatis Upgrade patch otomatis
Tidak ada upgrade (default) Tidak diizinkan Tidak diizinkan Tidak diizinkan Tidak diizinkan
Tidak ada upgrade minor Tidak diizinkan Diizinkan Tidak diizinkan Diizinkan
Tidak ada upgrade minor atau node Tidak diizinkan Diizinkan Tidak diizinkan Tidak diizinkan

Untuk definisi tentang versi minor dan patch, silakan melihat Skema pembuatan versi.

Beberapa pengecualian

Anda dapat menetapkan beberapa pengecualian di cluster. Pengecualian ini mungkin memiliki cakupan yang berbeda dan mungkin memiliki rentang waktu yang tumpang tindih. Kasus penggunaan musim liburan akhir tahun adalah contoh pengecualian yang tumpang tindih. Pada saat ini, cakupan "Tidak ada upgrade" dan "Tidak ada upgrade kecil" digunakan.

Saat pengecualian tumpang tindih, jika ada pengecualian aktif (yaitu, waktu saat ini berada dalam jangka waktu pengecualian) yang memblokir upgrade, upgrade akan ditunda.

Dengan menggunakan kasus penggunaan musim liburan akhir tahun, cluster memiliki pengecualian berikut yang ditentukan:

  • Tidak ada upgrade minor: 30 September - 15 Januari
  • Tidak ada upgrade: 19 November - 4 Desember
  • Tidak ada upgrade: 15 Desember - 5 Januari

Akibat pengecualian yang tumpang tindih ini, upgrade berikut akan diblokir di cluster:

  • Upgrade patch ke node pool pada 25 November (ditolak oleh pengecualian "Tidak ada upgrade")
  • Upgrade minor ke panel kontrol pada 20 Desember (ditolak oleh pengecualian "Tidak ada upgrade minor" dan "Tidak ada upgrade")
  • Upgrade patch ke panel kontrol pada 25 Desember (ditolak oleh pengecualian "Tidak ada upgrade")
  • Upgrade minor ke node pool pada 1 Januari (ditolak oleh pengecualian "Tidak ada upgrade minor" dan "Tidak ada upgrade")

Pemeliharaan berikut akan diizinkan di cluster:

  • Upgrade patch ke panel kontrol pada 10 November (diizinkan oleh pengecualian "Tidak ada upgrade minor")
  • Gangguan VM karena pemeliharaan GKE pada 10 Desember (diizinkan oleh pengecualian "Tidak ada upgrade minor")

Akhir masa berlaku pengecualian

Saat masa berlaku pengecualian berakhir (artinya, waktu saat ini telah melampaui waktu berakhir yang ditentukan untuk pengecualian), pengecualian tersebut tidak akan lagi mencegah update GKE. Pengecualian lain yang masih valid (belum berakhir masa berlakunya) akan terus mencegah update GKE.

Jika tidak ada pengecualian atau faktor lain yang mencegah upgrade cluster, GKE akan mengupgrade cluster Anda secara bertahap ke target upgrade otomatis yang memenuhi syarat.

Jika cluster Anda melewatkan beberapa upgrade versi minor karena pengecualian, GKE akan menjadwalkan sekitar satu upgrade versi minor per bulan, mengupgrade node dan panel kontrol cluster, untuk memastikan cluster Anda menjalankan versi yang didukung. Anda dapat menjalankan upgrade manual kapan saja untuk mengupgrade cluster ke versi minor tertentu dengan lebih cepat.

Batasan saat mengonfigurasi pengecualian pemeliharaan

Pengecualian pemeliharaan memiliki batasan berikut:

  • Anda hanya dapat membatasi cakupan upgrade otomatis dalam pengecualian pemeliharaan untuk cluster yang terdaftar di saluran rilis. Untuk cluster yang tidak terdaftar di saluran rilis, Anda hanya dapat membuat pengecualian pemeliharaan dengan cakupan "Tidak ada upgrade" default.
  • Anda dapat menambahkan maksimum tiga pengecualian pemeliharaan yang mengecualikan semua upgrade (yaitu, cakupan "tidak ada upgrade"). Pengecualian ini harus dikonfigurasi untuk memungkinkan ketersediaan pemeliharaan setidaknya selama 48 jam dalam jangka waktu yang berkelanjutan selama 32 hari.
  • Anda dapat memiliki maksimum 20 pengecualian pemeliharaan untuk setiap cluster.
  • Jika Anda tidak menentukan cakupan dalam pengecualian, cakupan tersebut akan ditetapkan secara default ke "tidak ada upgrade".
  • Anda dapat menetapkan pengecualian pemeliharaan ke durasi yang berbeda, bergantung pada cakupannya. Tinjau baris Durasi pengecualian pemeliharaan di bagian Mengonfigurasi pengecualian pemeliharaan untuk mengetahui detail selengkapnya.
  • Anda tidak dapat mengonfigurasi pengecualian pemeliharaan untuk menyertakan atau melebihi tanggal akhir dukungan versi minor yang sesuai dengan pendaftaran saluran rilis cluster. Lihat contoh berikut:
    • Cluster menjalankan versi minor di saluran Stabil dengan jadwal rilis GKE yang menyatakan bahwa tanggal akhir dukungan standar adalah 5 Juni 2025. Anda harus menetapkan waktu berakhir pengecualian pemeliharaan ke 2025-06-05T00:00:00Z atau lebih awal.
    • Cluster menjalankan versi minor di saluran Extended dengan jadwal rilis GKE yang menyatakan bahwa akhir tanggal dukungan yang diperpanjang adalah 5 April 2026. Anda harus menetapkan waktu berakhir pengecualian pemeliharaan ke 2026-04-0500:00:00Z atau sebelumnya. Jika ingin mengubah saluran rilis cluster ke saluran lain, Anda harus mengubah waktu akhir pengecualian pemeliharaan jika melebihi akhir dukungan standar. Untuk mempelajari lebih lanjut, lihat Mengubah cluster dari saluran Extended.

Contoh penggunaan

Berikut beberapa contoh kasus penggunaan untuk pembatasan cakupan update yang dapat terjadi.

Contoh: Retailer yang bersiap untuk musim liburan akhir tahun

Dalam contoh ini, bisnis retail tidak menginginkan adanya gangguan selama periode penjualan dengan volume tertinggi, yaitu selama empat hari dari Black Friday sampai Cyber Monday, dan bulan Desember hingga awal tahun baru. Untuk mempersiapkan musim belanja ini, administrator cluster menyiapkan pengecualian berikut:

  • Tidak ada upgrade minor: Hanya mengizinkan update patch pada panel kontrol dan node antara 30 September - 15 Januari.
  • Tidak ada upgrade: Menghentikan sementara semua upgrade antara 19 November - 4 Desember.
  • Tidak ada upgrade: Menghentikan sementara semua upgrade antara 15 Desember - 5 Januari.

Jika tidak ada masa pengecualian lain yang diterapkan saat pengecualian pemeliharaan berakhir, cluster akan diupgrade ke versi GKE minor baru jika ada versi yang tersedia antara 30 September dan 6 Januari.

Contoh: Perusahaan menggunakan API beta di Kubernetes yang sedang dihapus

Dalam contoh ini, perusahaan menggunakan CustomResourceDefinition apiextensions.k8s.io/v1beta1 API, yang akan dihapus dalam versi 1.22. Saat perusahaan menjalankan versi sebelum 1.22, administrator cluster menyiapkan pengecualian berikut:

  • Tidak ada upgrade minor: Menghentikan sementara upgrade minor selama tiga bulan saat memigrasikan aplikasi pelanggan dari apiextensions.k8s.io/v1beta1 ke apiextensions.k8s.io/v1.

Contoh: Database lama perusahaan tidak berfungsi dengan baik setelah upgrade node pool

Dalam contoh ini, perusahaan menjalankan database yang tidak merespons dengan baik penghentian dan penjadwalan ulang Pod yang terjadi selama upgrade node pool. Administrator cluster menyiapkan pengecualian berikut:

  • Tidak ada upgrade minor atau node: Menghentikan sementara upgrade node selama tiga bulan. Saat perusahaan siap menerima periode nonaktif untuk database, perusahaan memicu upgrade node manual.

Langkah berikutnya