Praktik terbaik untuk mengupgrade cluster

Halaman ini memberikan panduan untuk menjaga agar cluster Google Kubernetes Engine (GKE) tetap terbaru dengan lancar, dan rekomendasi untuk membuat strategi upgrade yang sesuai dengan kebutuhan Anda serta meningkatkan ketersediaan dan keandalan lingkungan. Anda dapat menggunakan informasi ini untuk terus mengupdate cluster Anda demi stabilitas dan keamanan dengan gangguan minimal pada workload Anda.

Atau, untuk mengelola upgrade cluster otomatis di seluruh lingkungan produksi yang diatur dengan fleet, lihat Tentang upgrade cluster dengan urutan peluncuran.

Menyiapkan beberapa lingkungan

Sebagai bagian dari alur kerja Anda untuk mengirimkan update software, sebaiknya gunakan beberapa lingkungan. Beberapa lingkungan membantu Anda meminimalkan risiko dan periode nonaktif yang tidak diinginkan dengan menguji update software dan infrastruktur secara terpisah dari lingkungan produksi Anda. Anda setidaknya harus memiliki lingkungan produksi dan lingkungan praproduksi atau pengujian.

Pertimbangkan lingkungan yang direkomendasikan berikut:

Lingkungan Deskripsi
Produksi Digunakan untuk menyalurkan traffic live ke pengguna akhir untuk aplikasi bisnis yang sangat penting.
Staging Digunakan untuk memastikan bahwa semua perubahan baru yang di-deploy dari lingkungan sebelumnya berfungsi sebagaimana mestinya sebelum perubahan di-deploy ke produksi.
Pengujian Digunakan untuk melakukan benchmark performa, pengujian, dan QA workload terhadap rilis GKE yang akan Anda gunakan dalam produksi. Dalam lingkungan ini, Anda dapat menguji upgrade bidang kontrol dan node sebelum melakukannya dalam produksi.
Pengembangan Digunakan untuk pengembangan aktif yang mengandalkan versi yang sama yang berjalan di produksi. Dalam lingkungan ini, Anda membuat perbaikan dan perubahan inkremental untuk di-deploy dalam produksi.
Canary Digunakan sebagai lingkungan pengembangan sekunder untuk menguji rilis Kubernetes yang lebih baru, fitur GKE, dan API untuk mendapatkan waktu penyiapan produk yang lebih baik setelah rilis ini dipromosikan dan menjadi target upgrade otomatis.

Mendaftarkan cluster di saluran rilis

Kubernetes sering merilis update, menyediakan update keamanan, memperbaiki masalah umum, dan memperkenalkan fitur baru. Saluran rilis GKE menawarkan kemampuan untuk menyeimbangkan antara stabilitas dan set fitur versi yang diterapkan di cluster. Saat Anda mendaftarkan cluster baru di saluran rilis, Google akan otomatis mengelola versi dan mengupgrade cadence untuk cluster maupun node pool.

Agar cluster selalu terbaru dengan update GKE dan Kubernetes terbaru, berikut adalah beberapa lingkungan yang direkomendasikan dan saluran rilis masing-masing tempat cluster harus didaftarkan:

Lingkungan Saluran rilis Deskripsi
Produksi Stabil atau Reguler Untuk stabilitas dan kematangan versi, gunakan saluran Stabil atau Reguler untuk workload produksi.
Staging Sama dengan produksi Untuk memastikan pengujian Anda menunjukkan versi yang akan menjadi tujuan upgrade produksi Anda, gunakan saluran rilis yang sama dengan produksi.
Pengujian
Pengembangan
Canary Cepat Untuk menguji rilis Kubernetes terbaru dan menjadi yang terdepan dengan menguji fitur atau API GKE baru, gunakan saluran Cepat. Anda dapat mempersingkat waktu penyiapan produk saat versi di saluran Cepat dipromosikan ke saluran yang sedang Anda gunakan untuk produksi.
T/A Diperpanjang Agar cluster Anda tetap menggunakan versi minor lebih lama sekaligus tetap menerima patch keamanan setelah akhir tanggal dukungan standar, gunakan saluran yang Diperluas. Untuk mempelajari lebih lanjut, lihat Menggunakan saluran yang Diperluas jika Anda memerlukan dukungan jangka panjang.

Bidang kontrol cluster selalu diupgrade secara berkala, terlepas dari cluster tersebut telah terdaftar di saluran rilis atau belum.

Membuat strategi upgrade berkelanjutan

Setelah mendaftarkan cluster di saluran rilis, cluster tersebut akan diupgrade secara rutin ke versi yang memenuhi standar kualitas dan stabilitas untuk saluran tersebut. Update ini mencakup perbaikan keamanan dan bug, yang diterapkan dengan peningkatan pemeriksaan di setiap saluran:

  • Patch dikirim ke bidang kontrol dan node di semua saluran secara bertahap, sehingga mengumpulkan waktu berdiam di saluran Cepat dan Reguler sebelum berakhir di saluran Stabil.
  • Bidang kontrol diupgrade terlebih dahulu, diikuti oleh node untuk mematuhi kebijakan OSS Kubernetes bahwa kubelet tidak boleh lebih baru dari kube-apiserver.
  • GKE akan otomatis meluncurkan patch ke saluran berdasarkan kekritisan dan kepentingannya.
  • Saluran Stabil hanya menerima patch penting.

Terima info terbaru tentang versi GKE baru

Informasi tentang versi baru dipublikasikan di halaman catatan rilis GKE utama, serta ke feed RSS. Setiap saluran rilis memiliki halaman catatan rilis yang disederhanakan dan khusus (contoh: Catatan rilis untuk saluran Stabil) dengan informasi tentang versi GKE yang direkomendasikan untuk saluran tersebut.

Untuk menerima info terbaru tentang upgrade GKE secara proaktif sebelum upgrade terjadi, gunakan Pub/Sub dan berlangganan notifikasi upgrade.

Setelah versi baru tersedia, Anda harus merencanakan upgrade sebelum versi tersebut menjadi target upgrade otomatis untuk cluster. Pendekatan ini memberikan lebih banyak kontrol dan prediktabilitas jika diperlukan, karena GKE tidak mengupgrade cluster secara otomatis jika target upgrade otomatis yang tersedia lebih lama dari atau sama dengan versi yang telah Anda upgrade cluster secara manual. Untuk mendapatkan target upgrade otomatis untuk cluster tertentu, lihat Mendapatkan informasi tentang upgrade cluster (Pratinjau).

Menguji dan memverifikasi patch dan versi minor baru

Semua rilis lulus pengujian internal terlepas dari saluran tempat rilis tersebut. Namun, dengan update dan patch yang sering dari Kubernetes upstream dan GKE, sebaiknya uji rilis baru pada lingkungan pengujian dan/atau staging sebelum rilis diluncurkan ke lingkungan produksi Anda, terutama Kubernetes upgrade versi minor.

Setiap saluran rilis menawarkan beberapa versi yang tersedia, termasuk versi default untuk pembuatan cluster, dan target upgrade otomatis:

  • Rilis patch baru tersedia seminggu sebelum menjadi target upgrade otomatis.
  • Rilis minor Kubernetes baru tersedia empat minggu sebelum menjadi target upgrade otomatis.

GKE secara otomatis mengupgrade cluster ke versi yang lebih baru. Jika kontrol yang lebih besar terhadap proses upgrade diperlukan, sebaiknya upgrade terlebih dahulu ke versi yang tersedia. GKE tidak mengupgrade secara otomatis cluster yang diupgrade secara manual ke target upgrade otomatis yang sama.

Pendekatan yang direkomendasikan untuk mengotomatiskan dan menyederhanakan upgrade akan mencakup:

  • Lingkungan praproduksi menggunakan versi yang tersedia.
  • Notifikasi upgrade yang disiapkan di cluster untuk memberi tahu tim Anda tentang versi baru yang tersedia untuk diuji dan disertifikasi.
  • Lingkungan produksi yang berlangganan ke saluran rilis menggunakan versi yang telah Anda uji di lingkungan praproduksi.
  • Peluncuran bertahap versi baru yang tersedia ke cluster produksi. Misalnya, jika ada beberapa cluster produksi, paket upgrade bertahap akan dimulai dengan mengupgrade sebagian cluster ini ke versi yang tersedia sambil mempertahankan cluster lainnya di versi yang ada, diikuti dengan peningkatan porsi kecil hingga 100% ditingkatkan.

Tabel berikut meringkas peristiwa rilis dan tindakan yang disarankan:

Acara Tindakan yang disarankan
Versi baru X tersedia di saluran. Upgrade cluster pengujian Anda secara manual, tentukan syarat, dan uji versi barunya.
Versi X menjadi target upgrade otomatis untuk versi minor cluster. GKE memulai upgrade otomatis ke target upgrade otomatis. Pertimbangkan untuk mengupgrade produksi terlebih dahulu.
GKE memulai upgrade cluster secara otomatis. Izinkan cluster diupgrade secara otomatis, atau tunda upgrade menggunakan periode pengecualian pemeliharaan.

Strategi upgrade untuk rilis patch

Berikut strategi upgrade yang direkomendasikan untuk rilis patch, dengan skenario ketika:

  • Semua cluster berlangganan ke saluran Stabil.
  • Versi baru yang tersedia akan diluncurkan ke cluster staging terlebih dahulu.
  • Cluster produksi diupgrade secara otomatis ke target upgrade otomatis baru.
  • Memantau versi baru GKE yang tersedia secara rutin.
Time Acara Apa yang sebaiknya saya lakukan?
T - 1 minggu Versi patch baru tersedia. Mengupgrade lingkungan staging.
S Versi patch menjadi target upgrade otomatis. Pertimbangkan untuk mengupgrade bidang kontrol produksi terlebih dahulu untuk kemampuan prediksi yang lebih baik.
S GKE akan mulai mengupgrade control plane ke target upgrade otomatis. Pertimbangkan untuk mengupgrade node pool produksi terlebih dahulu untuk kemampuan prediksi yang lebih baik.
T + 1 minggu GKE akan mulai mengupgrade node pool cluster ke target upgrade otomatis. GKE akan otomatis mengupgrade cluster, sehingga tidak perlu melakukan upgrade secara manual.

Strategi upgrade untuk rilis minor baru

Berikut strategi upgrade yang direkomendasikan untuk rilis minor baru:

Time Acara Apa yang sebaiknya saya lakukan?
T - 3 minggu Versi minor baru tersedia Mengupgrade bidang kontrol pengujian
T - 2 minggu
  1. Mengingat upgrade bidang kontrol berhasil, pertimbangkan untuk mengupgrade bidang kontrol produksi terlebih dahulu.
  2. Mengupgrade node pool pengujian.
T - 1 minggu Mengingat upgrade berhasil, pertimbangkan untuk mengupgrade node pool produksi terlebih dahulu.
S Versi minor menjadi target upgrade otomatis.
S GKE akan mulai mengupgrade control plane cluster ke target upgrade otomatis. Buat periode pengecualian jika diperlukan pengujian atau mitigasi lainnya sebelum peluncuran produksi.
T + 1 minggu GKE akan mulai mengupgrade node pool cluster ke target upgrade otomatis. GKE akan otomatis mengupgrade cluster, sehingga melewati cluster yang diupgrade secara manual.

Mengurangi gangguan pada workload yang ada selama upgrade

Menjaga cluster Anda selalu diupdate dengan patch keamanan dan perbaikan bug sangat penting untuk memastikan daya tahan cluster Anda dan untuk kelangsungan bisnis. Update rutin melindungi workload Anda dari kerentanan dan kegagalan.

Menjadwalkan masa pemeliharaan dan pengecualian

Untuk meningkatkan prediktabilitas upgrade dan menyesuaikan upgrade dengan waktu di luar jam kerja, Anda dapat mengontrol upgrade otomatis bidang kontrol dan node dengan membuat jendela pemeliharaan. GKE mengikuti masa pemeliharaan. Yaitu, jika proses upgrade berjalan di luar periode pemeliharaan yang ditentukan, GKE akan mencoba menjeda operasi, dan melanjutkan operasi selama periode pemeliharaan berikutnya.

GKE mengikuti jadwal peluncuran selama beberapa hari untuk menyediakan versi baru, serta melakukan upgrade otomatis pada bidang kontrol cluster dan node di berbagai region. Peluncuran umumnya berlangsung selama empat hari atau lebih, dan menyertakan buffer waktu untuk mengamati dan memantau masalah. Dalam lingkungan multi-cluster, Anda dapat menggunakan masa pemeliharaan terpisah untuk setiap cluster guna mengurutkan peluncuran di seluruh cluster Anda. Misalnya, Anda mungkin ingin mengontrol kapan cluster di region yang berbeda menerima pemeliharaan dengan menetapkan masa pemeliharaan yang berbeda untuk setiap cluster.

Alat lain untuk mengurangi gangguan, terutama selama periode bisnis yang sangat diminati, adalah pengecualian pemeliharaan. Menggunakan pengecualian pemeliharaan untuk mencegah pemeliharaan otomatis terjadi selama periode ini; pengecualian pemeliharaan dapat ditetapkan pada cluster baru atau yang sudah ada. Anda juga dapat menggunakan pengecualian bersama dengan strategi upgrade Anda. Misalnya, Anda mungkin ingin menunda upgrade ke cluster produksi jika lingkungan pengujian atau staging gagal karena upgrade.

Menetapkan toleransi terhadap gangguan

Anda mungkin sudah memahami konsep replika di Kubernetes. Replika memastikan redundansi workload Anda untuk performa dan responsivitas yang lebih baik. Jika ditetapkan, replika akan mengatur jumlah replika Pod yang berjalan pada waktu tertentu. Namun, selama pemeliharaan, Kubernetes akan menghapus VM node yang mendasarinya, sehingga dapat mengurangi jumlah replika. Untuk memastikan workload Anda memiliki jumlah replika yang memadai untuk aplikasi Anda, bahkan selama pemeliharaan, gunakan Anggaran Gangguan Pod (PDB).

Dalam Anggaran Gangguan Pod, Anda dapat menentukan jumlah (atau persentase) Pod yang dapat dihentikan, meskipun penghentian Pod menyebabkan jumlah replika saat ini di bawah nilai yang diinginkan. Proses ini dapat mempercepat pengosongan node dengan meniadakan kebutuhan menunggu pod yang dimigrasikan hingga beroperasi penuh. Sebagai gantinya, hapus pod dari node setelah konfigurasi PDB, sehingga deployment dapat men-deploy Pod yang hilang pada node lain yang tersedia. Setelah PDB ditetapkan, GKE tidak akan menonaktifkan Pod di aplikasi jika jumlah Pod sama dengan atau kurang dari batas yang dikonfigurasi. GKE mengikuti PDB selama 60 menit.

Mengontrol upgrade node pool

Dengan GKE, Anda dapat memilih strategi upgrade node untuk menentukan cara node di node pool Anda diupgrade. Secara default, node pool menggunakan upgrade lonjakan. Dengan upgrade lonjakan, proses upgrade untuk node pool GKE melibatkan pembuatan ulang setiap VM di node pool. VM baru dibuat dengan versi baru (gambar yang diupgrade) melalui update berkelanjutan. Oleh karena itu, semua Pod yang berjalan di node lama harus dimatikan dan dialihkan ke node baru. Workload Anda dapat berjalan dengan redundansi (replika) yang memadai, dan Anda dapat mengandalkan Kubernetes untuk memindahkan dan memulai ulang Pod sesuai kebutuhan. Namun, pengurangan jumlah replika untuk sementara masih dapat mengganggu bisnis Anda, dan mungkin memperlambat performa workload hingga Kubernetes dapat kembali memenuhi status yang diinginkan (yaitu, memenuhi jumlah minimum replika yang diperlukan). Anda dapat menghindari gangguan tersebut dengan menggunakan upgrade lonjakan.

Selama upgrade dengan upgrade lonjakan diaktifkan, GKE mengamankan resource (mesin) yang diperlukan untuk upgrade terlebih dahulu, lalu membuat node baru yang diupgrade, dan baru menghabiskan node lama, dan akhirnya mematikannya. Dengan demikian, kapasitas yang diharapkan tetap utuh selama proses upgrade.

Untuk cluster besar dengan proses upgrade yang mungkin memerlukan waktu lebih lama, Anda dapat mempercepat waktu penyelesaian upgrade dengan mengupgrade beberapa node secara bersamaan. Gunakan upgrade lonjakan dengan maxSurge=20, maxUnavailable=0 untuk menginstruksikan GKE untuk mengupgrade 20 node sekaligus, tanpa menggunakan kapasitas yang ada.

Gunakan saluran yang Diperpanjang jika Anda memerlukan dukungan jangka panjang

Jika Anda ingin mempertahankan cluster pada versi minor lebih lama, ikuti praktik terbaik untuk mendaftarkan cluster di saluran Extended. Dengan saluran ini, GKE mendukung versi minor selama sekitar 24 bulan. Untuk mempelajari lebih lanjut, lihat Mendapatkan dukungan jangka panjang dengan saluran yang Diperluas.

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

Tetap menggunakan versi minor untuk sementara

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

Upgrade versi minor 1-2 kali per tahun

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

  • Daftarkan cluster di saluran Extended.
  • Melakukan dua upgrade versi minor berturut-turut 1-2 kali per tahun. Misalnya, upgrade dari 1.30 ke 1.31 ke 1.32.

Proses ini 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 Anda tidak menggunakan Saluran yang diperluas

Untuk menggunakan saluran yang Diperluas sesuai tujuannya, Anda harus melakukan tindakan manual. Skenario berikut menggambarkan konsekuensi penggunaan saluran Extended tanpa pengelolaan aktif versi minor cluster Anda.

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

Jika ingin mempertahankan cluster pada versi minor selamanya, daftarkan cluster Anda di saluran Extended dan jangan lakukan tindakan lebih lanjut. Semua versi minor akhirnya tidak didukung dan GKE 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 akan segera tidak didukung, yang rata-rata sekitar setiap 4 bulan. Hal ini berarti bahwa cluster menerima upgrade versi minor sama seringnya di saluran rilis lainnya, tetapi menerima fitur baru nanti.

Ringkasan checklist

Tabel berikut merangkum tugas-tugas yang direkomendasikan untuk strategi upgrade agar cluster GKE Anda selalu terupdate dengan lancar:

Praktik Terbaik Tasks
Menyiapkan beberapa lingkungan
Mendaftarkan cluster di saluran rilis
Membuat strategi upgrade berkelanjutan
Mengurangi gangguan pada workload yang ada

Langkah berikutnya