Upgrade cluster standard

Halaman ini membahas cara kerja upgrade otomatis dan manual pada cluster Google Kubernetes Engine (GKE) Standard, termasuk link ke informasi lebih lanjut tentang tugas dan setelan terkait. Anda dapat menggunakan informasi ini untuk terus mengupdate cluster Anda demi stabilitas dan keamanan dengan gangguan minimal pada workload.

Untuk mengetahui informasi tentang cara kerja upgrade cluster untuk Autopilot, silakan melihat Upgrade cluster Autopilot.

Cara kerja upgrade cluster dan node pool

Bagian ini membahas apa yang akan terjadi di cluster Anda selama proses upgrade otomatis atau manual. Untuk upgrade otomatis, GKE akan memulai upgrade otomatis. GKE mengamati upgrade otomatis dan manual di semua cluster GKE, serta melakukan intervensi jika ada masalah.

Untuk mengupgrade cluster, GKE mengupdate versi yang dijalankan panel kontrol dan node. Cluster diupgrade ke versi minor yang lebih baru (misalnya 1.24 ke 1.25) atau versi patch yang lebih baru (misalnya 1.24.2-gke.100 ke 1.24.5-gke.200). Untuk informasi selengkapnya, silakan melihat Pembuatan versi dan dukungan GKE.

Jika Anda mendaftarkan cluster di saluran rilis, node akan menjalankan versi GKE yang sama dengan cluster tersebut, kecuali selama periode yang singkat (biasanya selama beberapa hari, bergantung pada rilis saat ini) antara penyelesaian upgrade panel kontrol cluster dan dimulainya upgrade node pool, atau jika panel kontrol diupgrade secara manual. Periksa catatan rilis untuk mengetahui informasi selengkapnya.

Upgrade cluster

Bagian ini membahas hal yang akan terjadi saat GKE melakukan upgrade otomatis cluster atau Anda memulai upgrade manual.

  • Cluster Zona hanya memiliki satu panel kontrol. Selama upgrade, workload Anda akan terus berjalan, tetapi Anda tidak dapat men-deploy workload baru, mengubah workload yang ada, atau membuat perubahan lain pada konfigurasi cluster sampai upgrade selesai.

  • Cluster Regional memiliki beberapa replika panel kontrol, dan hanya satu replika yang akan diupgrade pada satu waktu, dalam urutan yang tidak ditentukan. Selama upgrade, cluster akan tetap memiliki ketersediaan tinggi, dan setiap replika panel kontrol akan menjadi tidak tersedia hanya saat sedang diupgrade.

Jika Anda mengonfigurasi masa atau pengecualian pemeliharaan, konfigurasi ini akan dipatuhi jika memungkinkan.

Upgrade node pool

Bagian ini membahas hal yang akan terjadi jika GKE melakukan upgrade otomatis kumpulan node atau Anda memulai upgrade kumpulan node manual.

GKE secara otomatis mengupgrade satu kumpulan node dalam satu waktu dalam cluster. Atau, Anda dapat mengupgrade satu atau beberapa node pool secara manual dan paralel. Secara default, node dalam kumpulan node diupgrade satu per satu dalam urutan arbitrer. Di kumpulan node yang tersebar di beberapa zona, upgrade dilakukan berdasarkan zona demi zona. Dalam satu zona, node akan diupgrade dalam urutan yang tidak ditentukan.

Dengan upgrade node pool GKE, Anda dapat memilih antara dua strategi upgrade bawaan yang dapat dikonfigurasi tempat Anda dapat menyesuaikan proses upgrade berdasarkan kebutuhan lingkungan cluster. Untuk mempelajari strategi upgrade lonjakan dan blue-green lebih lanjut, lihat Strategi upgrade.

Selama upgrade kumpulan node, Anda tidak dapat membuat perubahan pada konfigurasi cluster kecuali jika Anda membatalkan upgrade.

GKE mematuhi masa pemeliharaan dan pengecualian selama upgrade otomatis jika memungkinkan. Upgrade manual mengabaikan masa dan pengecualian pemeliharaan yang dikonfigurasi.

Cara node diupgrade

Selama upgrade kumpulan node, cara node diupgrade bergantung pada strategi upgrade kumpulan node dan cara Anda mengonfigurasinya. Namun, langkah-langkah dasarnya tetap konsisten. Untuk mengupgrade node, GKE menghapus Pod dari node agar node dapat diupgrade.

Saat node diupgrade, hal berikut akan terjadi pada Pod:

  1. Node akan ditandai sebagai tidak dapat dijadwalkan sehingga Kubernetes tidak menjadwalkan Pod baru di dalamnya.
  2. Node kemudian dihabiskan, yang berarti Pod akan dihapus. Untuk upgrade lonjakan, GKE mematuhi setelan PodDisruptionBudget dan GracefulTerminationPeriod Pod hingga satu jam. Dengan upgrade blue-green, periode ini dapat diperpanjang jika Anda mengonfigurasi waktu perendaman yang lebih lama.
  3. Panel kontrol menjadwalkan ulang Pod yang dikelola oleh pengontrol ke node lain. Pod yang tidak dapat dijadwalkan ulang akan tetap berada dalam fase Tertunda hingga dapat dijadwalkan ulang.

Proses upgrade node pool dapat memerlukan waktu hingga beberapa jam, bergantung pada strategi upgrade, jumlah node, dan konfigurasi workload.

Faktor-faktor yang dapat memengaruhi durasi upgrade node

Konfigurasi yang dapat menyebabkan upgrade node membutuhkan waktu lebih lama untuk diselesaikan meliputi:

Strategi upgrade node

GKE menawarkan strategi bawaan yang dapat dikonfigurasi yang menentukan cara node pool diupgrade. Untuk mempelajari lebih lanjut jenis perubahan yang menggunakan strategi upgrade node, lihat Saat GKE menggunakan upgrade lonjakan dan Saat GKE menggunakan upgrade blue-green.

Upgrade lonjakan

Secara default, strategi upgrade lonjakan digunakan untuk upgrade node pool. Upgrade Surge menggunakan metode berkelanjutan untuk mengupgrade node. Strategi ini paling cocok untuk aplikasi yang dapat menangani perubahan inkremental yang tidak mengganggu. Dengan strategi ini, node diupgrade dalam periode berkelanjutan. Dengan setelan ini, Anda dapat mengubah jumlah node yang dapat diupgrade dalam satu waktu, dan seberapa mengganggu upgrade tersebut, dengan menemukan keseimbangan optimal antara kecepatan dan gangguan untuk kebutuhan lingkungan Anda.

Upgrade blue-green

Pendekatan alternatifnya adalah upgrade blue-green, dengan dua set lingkungan (lingkungan asli dan baru) yang dipertahankan di saat yang bersamaan, sehingga menjadikan proses roll back semudah mungkin. Strategi blue-green memerlukan resource lebih banyak dan lebih cocok untuk aplikasi yang lebih sensitif terhadap perubahan. Dengan strategi ini, workload dimigrasikan secara bertahap dari lingkungan "blue" asli ke lingkungan "green" yang baru, dan diberi waktu perendaman untuk memvalidasinya dengan konfigurasi baru. Jika diperlukan, workload dapat di-roll back ke lingkungan "blue" yang sudah ada dengan cepat.

Untuk mempelajari lebih lanjut cara kerja strategi upgrade node, baca Strategi upgrade node.

Persyaratan resource untuk strategi upgrade node

Upgrade lonjakan membuat node tambahan jika maxSurge ditetapkan ke lebih dari 0, dan upgrade blue-green untuk sementara menggandakan jumlah node dalam kumpulan node. Hal ini memerlukan resource tambahan, yang tunduk pada kuota Compute Engine, ketersediaan resource, dan kapasitas reservasi. Jika kumpulan node Anda tidak memiliki resource yang memadai, upgrade dapat memerlukan waktu lebih lama atau gagal.

Untuk mempelajari lebih lanjut cara memastikan project Anda memiliki resource yang cukup untuk upgrade node, dan tindakan yang harus dilakukan jika lingkungan Anda terbatas resource, lihat Memastikan resource untuk upgrade node.

Mengupgrade otomatis

Saat Anda membuat cluster Standard, secara default, upgrade otomatis diaktifkan pada cluster dan node pool-nya.

GKE bertanggung jawab untuk mengamankan bidang kontrol cluster Anda, dan mengupgrade cluster saat versi GKE baru dipilih untuk upgrade otomatis. Keamanan infrastruktur merupakan prioritas tinggi untuk GKE. Oleh karena itu, bidang kontrol tersebut diupgrade secara berkala dan tidak dapat dinonaktifkan. Namun, Anda dapat menerapkan jendela dan pengecualian pemeliharaan guna menangguhkan upgrade sementara untuk bidang dan node kontrol.

Sebagai bagian dari model tanggung jawab bersama GKE, Anda bertanggung jawab untuk mengamankan node, container, dan Pod. Upgrade otomatis node diaktifkan secara default. Meskipun tidak direkomendasikan, Anda dapat menonaktifkan upgrade otomatis node. Menonaktifkan upgrade otomatis node tidak akan memblokir upgrade panel kontrol cluster Anda. Jika menonaktifkan upgrade otomatis node, Anda bertanggung jawab untuk memastikan bahwa node cluster menjalankan versi yang kompatibel dengan versi cluster, dan bahwa versi tersebut mematuhi kebijakan dukungan ketidaksesuaian versi Kubernetes.

Untuk kontrol yang lebih besar terhadap kapan upgrade otomatis dapat terjadi (atau tidak boleh terjadi), Anda dapat mengonfigurasi masa dan pengecualian pemeliharaan.

Node pool cluster tidak boleh lebih dari dua versi minor lebih lama dari versi panel kontrol, untuk mempertahankan kompatibilitas dengan API cluster. Versi node pool juga menentukan versi paket software yang diinstal di setiap node. Sebaiknya terus update node pool ke versi cluster.

Jika Anda mendaftarkan cluster di saluran rilis, node selalu menjalankan versi GKE yang sama dengan cluster itu sendiri, kecuali dalam periode singkat (biasanya selama beberapa hari, bergantung pada rilis saat ini) antara penyelesaian upgrade panel kontrol cluster dan dimulainya upgrade node pool tertentu. Periksa catatan rilis untuk mengetahui informasi selengkapnya.

Pemilihan versi yang akan diupgrade otomatis

Versi GKE baru dirilis secara berkala, tetapi suatu versi tidak akan langsung dipilih untuk upgrade otomatis. Jika versi GKE telah mengakumulasi penggunaan cluster yang cukup untuk membuktikan stabilitas dari waktu ke waktu, GKE akan memilihnya sebagai target upgrade otomatis untuk cluster yang menjalankan sebagian dari versi yang lebih lama.

Target upgrade otomatis yang baru akan diumumkan dalam catatan rilis. Anda dapat mengupgrade ke versi yang tersedia secara manual hingga versi tersebut dipilih untuk upgrade otomatis. Terkadang, suatu versi dipilih untuk upgrade otomatis cluster dan upgrade otomatis node dalam minggu yang berbeda.

Segera setelah versi minor baru tersedia secara umum, versi minor terlama yang tersedia biasanya tidak akan didukung. Cluster yang menjalankan versi minor yang tidak didukung akan otomatis diupgrade ke versi minor berikutnya.

Dalam versi minor (seperti v1.14.x), cluster dapat otomatis diupgrade ke rilis patch baru.

Saluran rilis memungkinkan Anda mengontrol versi cluster dan node pool berdasarkan stabilitas versi, bukannya mengelola versi secara langsung.

Faktor yang memengaruhi waktu peluncuran versi

Untuk memastikan stabilitas dan keandalan cluster pada versi baru, GKE mengikuti praktik tertentu selama peluncuran versi.

Praktik ini mencakup, tetapi tidak terbatas pada:

  • GKE secara bertahap meluncurkan perubahan di seluruh region dan zona Google Cloud.
  • GKE secara bertahap meluncurkan versi patch di seluruh saluran rilis. Patch diberi waktu berdiam di saluran rilis Cepat, lalu saluran rilis Reguler, sebelum dipromosikan ke saluran rilis Stabil setelah patch tersebut mengakumulasi penggunaan dan terus menunjukkan stabilitas. Jika ditemukan masalah pada versi patch selama waktu berdiam di sebuah saluran rilis, versi tersebut tidak akan dipromosikan ke saluran berikutnya dan masalah akan diperbaiki pada versi patch yang lebih baru.
  • GKE meluncurkan versi minor secara bertahap, dengan mengikuti proses berdiam yang mirip dengan versi patch. Versi minor memiliki periode berdiam lebih lama karena versi ini menyebabkan perubahan yang lebih signifikan.
  • GKE dapat menunda upgrade otomatis jika versi baru memengaruhi sekelompok cluster. Misalnya, GKE akan menjeda upgrade otomatis untuk cluster yang terekspos ke API yang tidak digunakan lagi dan fitur yang akan dihapus dalam versi minor berikutnya.
  • GKE mungkin menunda peluncuran versi baru selama waktu puncak (misalnya hari libur besar) untuk memastikan kelangsungan bisnis.

Mengonfigurasi kapan upgrade otomatis dapat terjadi

Secara default, upgrade otomatis dapat dilakukan kapan saja untuk mempertahankan keamanan infrastruktur. Upgrade otomatis tidak terlalu mengganggu, terutama untuk cluster regional. Namun, beberapa workload mungkin memerlukan kontrol yang lebih terperinci. Anda dapat mengonfigurasi masa dan pengecualian pemeliharaan untuk mengelola kapan upgrade otomatis dapat dan tidak dapat dilakukan.

Mengupgrade secara manual

Anda dapat meminta untuk mengupgrade cluster atau node pool-nya secara manual ke versi yang tersedia dan kompatibel kapan saja. Upgrade manual mengabaikan semua masa pemeliharaan dan pengecualian pemeliharaan yang dikonfigurasi.

Jika Anda mengupgrade cluster secara manual, ketersediaannya akan bergantung pada apakah cluster tersebut merupakan cluster regional atau tidak:

  • Untuk cluster zona, panel kontrol tidak tersedia saat sedang diupgrade. Untuk sebagian besar, workload berjalan secara normal, tetapi tidak dapat dimodifikasi selama upgrade.

  • Untuk cluster regional, satu replika panel kontrol tidak tersedia saat sedang diupgrade, tetapi cluster tetap memiliki ketersediaan tinggi selama proses upgrade.

Anda dapat melakukan inisialisasi upgrade node secara manual ke versi yang kompatibel dengan panel kontrol.

Cara GKE merespons kegagalan upgrade otomatis

Upgrade otomatis node pool dapat gagal karena ada masalah pada instance Compute Engine yang mendasarinya, atau karena ada masalah pada Kubernetes. Misalnya, upgrade otomatis gagal dalam situasi berikut:

  • Setelan maxSurge yang dikonfigurasi melebihi kuota resource Compute Engine Anda.
  • Node lonjakan baru tidak didaftarkan dengan panel kontrol cluster.
  • Node memerlukan waktu terlalu lama untuk dihabiskan, atau terlalu lama untuk dihapus.

Saat terjadi masalah pada setiap upgrade node, GKE akan mencoba kembali upgrade beberapa kali, dengan interval antar-percobaan ulang yang meningkat. Jika node dalam node pool gagal diupgrade, GKE tidak akan melakukan roll back pada node yang diupgrade. Sebagai gantinya, GKE akan kembali mencoba melakukan upgrade otomatis pada node pool hingga semua node berhasil diupgrade.

Jika upgrade node Anda gagal karena permintaan node lonjakan melebihi kuota Compute Engine, GKE akan mengurangi jumlah node lonjakan yang berjalan bersamaan untuk memenuhi kuota dan melanjutkan upgrade.

Menerima notifikasi upgrade

GKE memublikasikan notifikasi tentang peristiwa yang relevan dengan cluster Anda, seperti upgrade versi dan buletin keamanan, ke Pub/Sub, yang menyediakan saluran untuk menerima informasi dari GKE tentang cluster Anda.

Untuk mengetahui informasi selengkapnya, silakan melihat Menerima notifikasi cluster.

Memeriksa log upgrade

GKE mencatat peristiwa upgrade panel kontrol dan node pool ke Cloud Logging secara default. Log aktivitas upgrade memberikan visibilitas ke proses upgrade, dan menyertakan informasi berharga untuk pemecahan masalah, jika diperlukan.

Log upgrade panel kontrol

Peristiwa upgrade cluster dapat dikueri menggunakan filter berikut:

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

Log ini dicatat sebagai format logging terstruktur. Anda dapat menggunakan kolom berikut untuk mengetahui detail peristiwa upgrade:



Kolom Deskripsi
protoPayload.metadata.operationType Ada dua jenis peristiwa upgrade cluster: UPGRADE_MASTER dan UPDATE_CLUSTER.
UPGRADE_MASTER mengubah versi panel kontrol Kubernetes.
UPDATE_CLUSTER berarti update yang tidak mengubah versi panel kontrol Kubernetes.
Kedua jenis upgrade cluster dapat menyebabkan hilangnya ketersediaan panel kontrol untuk cluster zona. Untuk mempelajari lebih lanjut, silakan melihat Cara kerja upgrade cluster dan node pool.
protoPayload.methodName Kolom ini menunjukkan API yang memicu upgrade cluster.
google.container.v1.ClusterManager.UpdateCluster: upgrade panel kontrol manual
google.container.internal.ClusterManagerInternal.UpdateClusterInternal: upgrade panel kontrol otomatis
google.container.v1.ClusterManager.PatchCluster: perubahan konfigurasi cluster.
protoPayload.metadata.previousMasterVersion Kolom ini hanya digunakan untuk jenis operasi MASTER_UPGRADE, dan berisi versi panel kontrol sebelumnya yang digunakan sebelum upgrade.
protoPayload.metadata.currentMasterVersion Kolom ini hanya digunakan untuk jenis operasi MASTER_UPGRADE, dan berisi nomor versi panel kontrol baru yang digunakan setelah upgrade.

Log upgrade node pool

Gunakan kueri berikut untuk melihat peristiwa upgrade node pool: 

resource.type="gke_nodepool"
protoPayload.metadata.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"

Gunakan kolom berikut untuk mengetahui detail tentang peristiwa upgrade:

Kolom protoPayload.methodName menunjukkan apakah upgrade dipicu secara manual atau otomatis, seperti berikut ini.

Upgrade komponen

GKE menjalankan beban kerja sistem pada node pekerja untuk mendukung kemampuan tertentu bagi cluster. Misalnya, workload sistem gke-metadata-server mendukung Workload Identity Federation for GKE. GKE bertanggung jawab atas kondisi workload ini. Untuk mempelajari komponen ini lebih lanjut, lihat dokumentasi untuk kemampuan terkait.

Saat fitur atau perbaikan baru tersedia untuk suatu komponen, GKE menunjukkan versi patch yang menyertakan komponen tersebut. Untuk mendapatkan versi terbaru komponen, lihat dokumentasi terkait atau catatan rilis untuk petunjuk tentang cara mengupgrade bidang kontrol atau node ke versi yang sesuai.

Langkah selanjutnya