Praktik terbaik untuk upgrade cluster GKE

Dokumen ini memberikan praktik terbaik bagi administrator platform untuk mengelola upgrade cluster Google Kubernetes Engine (GKE). Secara default, GKE mengupgrade versi bidang kontrol dan node cluster Anda secara otomatis untuk menyediakan fitur baru, perbaikan bug, dan patch keamanan agar lingkungan Anda tetap berperforma dan aman.

Untuk membantu memastikan bahwa upgrade otomatis ini selaras dengan kebutuhan operasional Anda dan meminimalkan gangguan workload, GKE menawarkan alat sehingga Anda dapat menegaskan kontrol maksimal. Panduan ini menjelaskan cara menggunakan alat ini secara efektif untuk mempertahankan performa dan ketersediaan yang tinggi. Untuk pemahaman dasar, lihat Tentang upgrade cluster GKE.

Selain upgrade cluster, yang hanya merupakan update pada versi GKE dari bidang kontrol dan node, GKE secara berkala melakukan update tambahan pada cluster. Menerapkan praktik terbaik dalam dokumen ini dapat membantu Anda bersiap menghadapi beberapa jenis perubahan ini. Untuk mengetahui informasi selengkapnya, lihat Mengelola perubahan siklus proses cluster untuk meminimalkan gangguan.

Untuk ringkasan gabungan semua praktik terbaik GKE, lihat Praktik terbaik untuk GKE.

Checklist

Tabel berikut meringkas tugas yang dijelaskan secara mendetail di bagian berikut. Sebaiknya lakukan tugas ini saat Anda menyiapkan lingkungan untuk upgrade cluster.

Praktik Terbaik Tasks
Pilih keseimbangan antara kecepatan fitur dan stabilitas upgrade dengan saluran rilis
Memilih waktu upgrade dengan kebijakan pemeliharaan
Mengontrol peluncuran upgrade di seluruh cluster
Mengontrol cara upgrade dipicu
Memantau upgrade cluster
Meminimalkan gangguan pada workload yang ada selama upgrade node

Pilih keseimbangan antara kecepatan fitur dan stabilitas upgrade dengan saluran rilis

Dengan saluran rilis, Anda memilih keseimbangan antara kecepatan fitur dan stabilitas upgrade. Cluster GKE didaftarkan di saluran rilis Reguler secara default. Saat GKE mengupgrade bidang kontrol dan node cluster Anda untuk memberikan patch keamanan, memperbaiki masalah umum, dan memperkenalkan fitur baru, saluran rilis menentukan versi GKE yang dijalankan cluster Anda. Misalnya, jika Anda ingin mendapatkan fitur baru lebih cepat, Anda dapat memilih saluran Cepat, dan jika Anda menginginkan versi dengan stabilitas yang lebih terbukti, pilih saluran Stabil. Untuk mengetahui informasi selengkapnya tentang cara memilih antara saluran tertentu, lihat Saluran yang tersedia.

Jika ingin mengupgrade cluster secara manual, Anda tetap dapat memanfaatkan pemilihan saluran rilis dengan meninjau versi yang tersedia dan target upgrade otomatis untuk saluran tersebut sebelum memilih versi baru.

Selain itu, jika Anda ingin mendapatkan versi patch di saluran rilis sesegera mungkin—misalnya, untuk menerima patch keamanan penting—lihat Tentang cara mendapatkan versi patch lebih awal.

Pilih tingkat dukungan yang Anda butuhkan untuk versi minor

GKE memberikan total dukungan hingga 24 bulan untuk versi minor setelah versi tersebut tersedia di saluran Reguler. Dukungan ini mencakup 14 bulan dukungan standar, dan sekitar 10 bulan dukungan tambahan yang tersedia dengan channel Extended. Untuk mengetahui informasi selengkapnya tentang cara GKE mendukung versi minor, lihat Dukungan versi minor.

Jika Anda perlu mempertahankan cluster pada versi minor lebih lama sambil tetap menerima patch keamanan setelah tanggal akhir dukungan standar, atau Anda ingin mencegah pemberlakuan akhir dukungan standar, Anda juga dapat menggunakan saluran Extended. Untuk mengetahui informasi selengkapnya, lihat bagian selanjutnya, Menggunakan saluran Extended saat Anda memerlukan dukungan jangka panjang.

Saat versi minor mencapai akhir dukungan, bergantung pada saluran rilis tempat cluster didaftarkan, GKE akan otomatis mengupgrade cluster Anda untuk membantu memastikan cluster tetap berperforma dan aman. Untuk mengetahui informasi selengkapnya, lihat Upgrade cluster otomatis untuk keamanan dan kompatibilitas. Jika Anda menggunakan alat yang dijelaskan dalam dokumen ini untuk mencegah atau menunda upgrade cluster otomatis, sebaiknya upgrade cluster Anda secara manual sebelum versi minor yang dijalankannya mencapai akhir dukungan. Jika tidak, GKE akan otomatis mengupgrade cluster Anda.

Memilih waktu upgrade dengan kebijakan pemeliharaan

Untuk mengontrol kapan upgrade dapat dan tidak dapat terjadi, gunakan hal berikut:

  • Masa pemeliharaan: pilih jangka waktu berulang saat GKE dapat mengupgrade cluster Anda, seperti di luar jam kerja. Jika proses upgrade berjalan di luar masa pemeliharaan, GKE akan mencoba menjeda operasi dan melanjutkannya selama masa pemeliharaan berikutnya.
  • Pengecualian pemeliharaan: pilih jangka waktu tertentu saat GKE tidak dapat mengupgrade cluster Anda, seperti selama acara penjualan besar untuk bisnis retail. Anda juga dapat menggunakan pengecualian pemeliharaan untuk menunda sementara upgrade otomatis cluster, misalnya, saat Anda melihat masalah pada cluster lain yang diupgrade ke versi baru.
    • Untuk kasus penggunaan lanjutan, Anda mungkin perlu melakukan jenis upgrade tertentu secara manual, bukan GKE yang melakukannya. Anda dapat menggunakan pengecualian pemeliharaan untuk menonaktifkan jenis upgrade otomatis ini. Misalnya, Anda dapat menggunakan cakupan "Tidak ada upgrade minor atau node" untuk menonaktifkan semua upgrade minor dan semua upgrade node. Anda harus melakukan upgrade tersebut secara manual, atau GKE akan mengupgrade cluster Anda di akhir dukungan untuk versi minor.
  • Frekuensi pemeliharaan: untuk kasus penggunaan lanjutan, kontrol interval minimum antara dua upgrade otomatis berturut-turut dengan anggaran gangguan cluster.

Dengan mengonfigurasi kebijakan pemeliharaan, Anda dapat meningkatkan prediktabilitas upgrade dan membantu memastikan bahwa upgrade terjadi pada waktu yang paling sesuai untuk beban kerja Anda.

Mengontrol peluncuran upgrade di seluruh cluster

Sebaiknya gunakan beberapa lingkungan untuk meminimalkan risiko dan waktu nonaktif yang tidak diinginkan dengan menguji perubahan software dan infrastruktur secara terpisah dari lingkungan produksi Anda. Setidaknya, sebaiknya Anda memiliki lingkungan produksi dan lingkungan praproduksi atau pengujian.

Pertimbangkan lingkungan yang direkomendasikan berikut:

Lingkungan Deskripsi
Produksi Menyalurkan traffic live ke pengguna akhir untuk aplikasi bisnis yang sangat penting.
Canary Uji sebagian kecil lingkungan produksi sebelum semua cluster diupgrade.
Staging Periksa apakah semua perubahan baru yang di-deploy dari lingkungan sebelumnya berfungsi sebagaimana mestinya sebelum perubahan di-deploy ke produksi.
Pengujian Lakukan benchmarking, pengujian, dan uji mutu (QA) untuk workload dengan versi GKE yang akan Anda gunakan dalam produksi.
Pengembangan Gunakan versi yang sama yang berjalan dalam produksi untuk pengembangan aktif. Dalam lingkungan ini, Anda membuat perbaikan dan perubahan inkremental untuk di-deploy dalam produksi.

GKE menyediakan fitur seperti urutan peluncuran untuk membantu Anda mengontrol cara upgrade di-deploy di berbagai lingkungan ini, seperti yang dijelaskan di bagian berikut.

Menggunakan urutan peluncuran untuk meluncurkan di seluruh lingkungan

Untuk meluncurkan versi GKE baru secara bertahap dalam dan di seluruh lingkungan ini, sebaiknya gunakan pengurutan peluncuran. Dengan urutan peluncuran, semua cluster menggunakan saluran rilis dan versi minor yang sama di seluruh tahap deployment. GKE meluncurkan versi baru secara progresif di seluruh urutan yang Anda konfigurasi. Saat GKE men-deploy versi baru di seluruh lingkungan Anda, Anda dapat memverifikasi bahwa lingkungan cluster dan beban kerja Anda berjalan seperti yang diharapkan dengan versi baru.

Jika Anda mengonfigurasi lingkungan baru, gunakan urutan peluncuran dengan tahap kustom (Pratinjau). Versi baru pengurutan peluncuran ini memungkinkan Anda membagi peluncuran versi baru ke fleet dalam beberapa tahap. Dengan pendekatan ini, GKE dapat, misalnya, mengupgrade lingkungan canary dalam produksi sebelum mengupgrade produksi lainnya. Atau, untuk versi fitur yang tersedia secara umum yang menggunakan model yang lebih linear tanpa tahap kustom, lihat Tentang upgrade cluster dengan pengurutan peluncuran.

Menguji upgrade patch dan minor GKE

GKE secara otomatis mengupgrade cluster ke patch baru sesering setiap minggu. Namun, upgrade versi minor hanya terjadi sekitar tiga kali setahun. Versi minor Kubernetes baru memperkenalkan volume perubahan yang lebih besar dibandingkan dengan patch dari versi minor yang sama. Sebaiknya Anda menerapkan pemeriksaan tambahan selama peluncuran upgrade versi minor di seluruh lingkungan Anda, untuk membantu memastikan bahwa versi minor baru berfungsi seperti yang diharapkan dengan cluster dan workload Anda.

Melakukan pemeriksaan sebelum mengupgrade cluster

Sebelum melakukan upgrade cluster otomatis, GKE akan menguji versi baru—selama jangka waktu yang bergantung pada saluran rilis—dan meninjau kesiapan cluster.

Sebelum mengupgrade cluster, sebaiknya Anda melakukan hal berikut:

  • Untuk semua upgrade, termasuk upgrade patch dan minor:
    • Periksa catatan rilis GKE untuk mengetahui masalah, dan untuk menemukan log perubahan untuk versi patch dan minor baru.
    • Periksa masalah umum GKE untuk mengetahui masalah yang relevan dengan lingkungan cluster dan versi baru Anda.
  • Untuk upgrade kecil, tinjau juga hal berikut:
    • Periksa penghentian penggunaan API. Untuk mengetahui informasi selengkapnya, lihat catatan rilis GKE untuk versi baru, log perubahan Kubernetes, dan Penghentian penggunaan fitur dan API.
    • Pastikan bahwa perbedaan versi antara bidang kontrol dan node didukung. GKE mendukung node yang menjalankan hingga dua versi minor lebih awal dari bidang kontrol. Untuk mengetahui informasi selengkapnya, lihat kebijakan perbedaan versi GKE.
  • Untuk upgrade node:

Mengontrol cara upgrade dipicu

Secara default, GKE otomatis mengupgrade cluster ke versi baru secara rutin. Namun, Anda juga dapat menggunakan upgrade manual untuk mengupgrade cluster tepat saat Anda inginkan, dan mengontrol versi yang dijalankan cluster Anda.

Anda dapat melakukan hal berikut:

  • Mengupgrade cluster secara manual.

  • Lakukan tindakan untuk upgrade node otomatis atau manual yang sedang berlangsung, termasuk tindakan berikut:

    • Membatalkan upgrade.
    • Lanjutkan upgrade.
    • Me-roll back upgrade.
    • Selesaikan upgrade yang sedang berlangsung.

Jika Anda ingin lebih mengontrol proses upgrade, sebaiknya konfigurasi pengecualian pemeliharaan, lalu lakukan upgrade manual sesuai kebutuhan. Untuk mengetahui informasi selengkapnya tentang upgrade manual dan tindakan lain yang dapat Anda lakukan untuk upgrade yang sedang berlangsung, lihat Mengupgrade cluster atau node pool secara manual.

Memantau upgrade cluster

Untuk membantu memastikan upgrade GKE berjalan sesuai yang diharapkan dan lingkungan cluster Anda tetap memiliki performa tinggi dan tersedia, gunakan alat berikut untuk memantau upgrade cluster. Untuk terus mengetahui status cluster Anda, gunakan alat seperti notifikasi, insight dan rekomendasi, serta log. Sebaiknya perhatikan notifikasi akhir dukungan, notifikasi mulai upgrade, dan notifikasi upgrade terjadwal yang diaktifkan untuk upgrade versi minor. Siapkan kebijakan pemberitahuan untuk membantu memastikan Anda melihat notifikasi ini.

Gunakan referensi berikut untuk mengetahui detail tentang upgrade saat ini:

Meminimalkan gangguan pada workload yang ada selama upgrade node

Selain praktik terbaik umum yang dijelaskan di bagian sebelumnya, sebaiknya pertimbangkan konfigurasi lanjutan tambahan untuk menyesuaikan lebih lanjut proses upgrade agar sesuai dengan lingkungan cluster dan kebutuhan beban kerja Anda.

Pertimbangan tambahan untuk profil workload tertentu

Jenis workload dan lingkungan cluster tertentu memerlukan persiapan tambahan untuk upgrade cluster. Jika beban kerja Anda sesuai dengan satu atau beberapa kategori berikut, pertimbangkan hal-hal tambahan ini:

  • Workload yang berjalan di mesin yang tidak melakukan live migrasi: Node GKE, yang merupakan instance Compute Engine yang dibuat GKE untuk Anda, memerlukan pemeliharaan secara berkala pada infrastruktur yang mendasarinya. Sebagian besar instance Compute Engine dapat melakukan migrasi langsung, yang berarti bahwa workload yang sedang berjalan tidak mengalami gangguan saat pemeliharaan ini terjadi. Namun, jenis mesin tertentu tidak dapat melakukan migrasi langsung, yang berarti workload yang berjalan di node GKE dapat terganggu. Yang penting, akselerator, seperti GPU dan TPU untuk workload AI/ML, tidak dapat dimigrasikan langsung. Untuk mengetahui informasi selengkapnya, lihat Mengelola gangguan pada node GKE yang tidak melakukan migrasi langsung.
  • Beban kerja yang dibatasi kapasitasnya: jika beban kerja Anda menggunakan jenis mesin yang dibatasi kapasitasnya, pertimbangan tambahan diperlukan saat melakukan upgrade cluster. Untuk mengetahui informasi selengkapnya, lihat Memastikan resource untuk upgrade node.
  • Workload stateful: jika workload Anda stateful dan memiliki persyaratan khusus untuk mematikan dan memulai ulang dengan baik, pertimbangan tambahan diperlukan saat melakukan upgrade cluster. Untuk mengetahui informasi selengkapnya, lihat Memastikan workload siap menghadapi gangguan.

Tinjau bagian berikut untuk memahami cara menggunakan alat yang tersedia untuk mengupgrade jenis workload ini.

Memilih strategi upgrade node

Dalam mode GKE Standard, GKE menawarkan strategi upgrade node yang berbeda yang menentukan cara setiap node di node pool Anda diupgrade. Dengan memilih strategi upgrade untuk node pool Standar, Anda dapat memilih proses dengan keseimbangan yang tepat antara kecepatan, gangguan workload, mitigasi risiko, dan pengoptimalan biaya. Anda juga dapat mengonfigurasi parameter strategi agar paling sesuai dengan kebutuhan Anda. Dalam mode GKE Autopilot, GKE mengelola upgrade node dan Anda tidak perlu memilih strategi spesifik yang digunakan. Untuk mengetahui informasi selengkapnya, lihat Tentang strategi upgrade node.

Menetapkan toleransi terhadap gangguan

Gunakan Anggaran Gangguan Pod (PDB) untuk membantu memastikan bahwa saat GKE membuat ulang node selama upgrade, yang dapat mengurangi jumlah replika untuk workload sementara, workload Anda mempertahankan redundansi yang memadai.

Jika PDB ditetapkan, GKE tidak akan menonaktifkan Pod di aplikasi Anda jika jumlah Pod sama dengan atau kurang dari batas yang dikonfigurasi. Upgrade GKE mematuhi PDB hingga 60 menit. Selain itu, GKE akan memberi tahu Anda jika pengurasan node diblokir oleh PDB, atau waktu tunggu PDB tercapai dan Pod akan dihapus secara paksa meskipun ada pelanggaran PDB. Untuk mengetahui informasi selengkapnya, lihat Peristiwa yang mengganggu selama upgrade node pool.

Menggunakan penghentian tuntas untuk mematikan aplikasi

Anda dapat mengonfigurasi penghentian yang benar untuk membantu memastikan bahwa workload memiliki waktu yang cukup untuk bersiap-siap dimatikan. Selama upgrade node, GKE mematuhi setelan penghentian yang benar hingga 60 menit dengan upgrade lonjakan default, dan hingga 24 jam dengan upgrade blue-green dan upgrade blue-green yang diskalakan otomatis (Pratinjau).

Untuk mengetahui informasi selengkapnya tentang cara mengonfigurasi setelan penghentian yang benar, lihat Mengonfigurasi GKE untuk menghentikan workload Anda dengan benar.

Gunakan saluran Extended jika Anda memerlukan dukungan jangka panjang

Jika Anda ingin mempertahankan cluster Anda pada versi minor untuk jangka waktu yang lebih lama, ikuti praktik terbaik dengan mendaftarkan cluster Anda ke saluran Extended. Dengan saluran ini, GKE mendukung versi minor selama sekitar 24 bulan. Dengan saluran Extended, Anda mengontrol upgrade versi minor, dengan GKE hanya melakukan upgrade otomatis di akhir dukungan, jika Anda tidak memulai upgrade sendiri. Untuk mengetahui informasi selengkapnya, lihat Mendapatkan dukungan jangka panjang dengan saluran Extended.

Jika Anda tidak perlu tetap menggunakan versi minor lebih lama dari periode dukungan standar, tetapi masih ingin mengontrol upgrade versi minor, gunakan pengecualian pemeliharaan dengan cakupan "Tidak ada upgrade minor".

Untuk mendapatkan manfaat maksimal dari saluran ini, sebaiknya Anda mematuhi praktik terbaik berikut. Beberapa praktik terbaik ini memerlukan tindakan manual, termasuk mengupgrade cluster secara manual dan mengubah saluran rilis cluster. Tinjau skenario yang didukung berikut, serta Kapan tidak boleh menggunakan channel yang Diperluas.

Tetap menggunakan versi minor untuk sementara waktu

Jika Anda perlu mempertahankan cluster pada versi minor untuk sementara selama lebih dari periode dukungan standar 14 bulan, misalnya, untuk memitigasi penggunaan API yang tidak digunakan lagi dan dihapus dalam versi minor berikutnya, gunakan proses berikut. Anda dapat memindahkan cluster untuk sementara dari saluran rilis lain ke saluran Extended untuk terus menerima patch keamanan saat bersiap mengupgrade ke versi minor berikutnya. Jika Anda sudah siap melakukan upgrade ke versi minor berikutnya, Anda mengupgrade cluster secara manual, lalu memindahkan cluster kembali ke saluran rilis aslinya.

Upgrade versi minor satu atau dua kali per tahun

Jika Anda menginginkan gangguan minimal pada cluster Anda sekaligus tetap menerima beberapa fitur baru saat cluster Anda siap diupgrade ke versi minor baru, lakukan hal berikut:

  • Daftarkan cluster di saluran Extended.
  • Lakukan dua upgrade versi minor berturut-turut satu atau dua kali per tahun. Misalnya, upgrade dari 1.33 ke 1.34 ke 1.35.

Proses ini membantu memastikan bahwa cluster tetap menggunakan versi minor yang tersedia, menerima fitur dari versi minor baru, tetapi hanya menerima upgrade versi minor saat Anda memutuskan bahwa cluster sudah siap.

Kapan sebaiknya tidak menggunakan Channel yang diperluas

Untuk menggunakan Channel yang diperluas sesuai tujuannya memerlukan tindakan manual. Skenario berikut menggambarkan konsekuensi penggunaan saluran Diperluas tanpa pengelolaan aktif versi minor cluster Anda.

Tidak melakukan apa pun dan menerima upgrade kecil dengan frekuensi yang sama

Jika ingin mempertahankan cluster Anda pada versi minor selamanya, daftarkan cluster Anda ke saluran Extended dan tidak perlu melakukan tindakan lebih lanjut. Semua versi minor pada akhirnya tidak didukung dan GKE secara otomatis mengupgrade cluster dari versi minor yang tidak didukung. Jadi, GKE mengupgrade cluster ini dari satu versi minor yang tidak didukung ke versi minor yang segera tidak didukung, yang rata-rata terjadi kira-kira setiap empat bulan. Pendekatan ini berarti cluster menerima upgrade versi minor sesering di saluran rilis lainnya, tetapi menerima fitur baru lebih lambat.

Langkah berikutnya