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

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 yang cepat dipromosikan ke saluran yang sedang Anda gunakan untuk produksi.
T/A Diperpanjang Untuk mempertahankan cluster Anda pada versi minor lebih lama selagi diam yang menerima {i>patch<i} keamanan melewati akhir tanggal dukungan standar, gunakan Channel yang diperluas. Untuk mempelajari lebih lanjut, lihat Menggunakan Saluran yang diperluas saat Anda membutuhkan 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 yang cepat dan teratur sebelum berakhir di saluran stabil.
  • Bidang kontrol diupgrade terlebih dahulu, diikuti oleh node untuk mematuhi Kebijakan Kubernetes OSS 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 default di fleet. Pendekatan ini memberikan lebih banyak kontrol dan prediktabilitas jika diperlukan, karena GKE akan melewati upgrade otomatis untuk cluster yang telah diupgrade lebih awal.

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 dua versi: default dan available.

  • Rilis patch baru tersedia seminggu sebelum menjadi default.
  • Rilis minor Kubernetes baru akan tersedia empat minggu sebelum menjadi default.

GKE secara otomatis mengupgrade cluster ke versi default secara bertahap. Jika kontrol yang lebih besar terhadap proses upgrade diperlukan, sebaiknya upgrade terlebih dahulu ke versi yang tersedia. Upgrade otomatis GKE melewati cluster yang diupgrade secara manual.

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 default di saluran tersebut.
  • 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 default, 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 versi default. GKE memulai upgrade otomatis ke versi default. 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 dengan versi default 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.
T Versi patch menjadi default. Pertimbangkan untuk mengupgrade bidang kontrol produksi terlebih dahulu untuk kemampuan prediksi yang lebih baik.
T GKE akan mulai mengupgrade control plane ke versi default. 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 versi default. 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.
T Versi minor menjadi default.
T GKE akan mulai mengupgrade control plane cluster ke versi default. Buat periode pengecualian jika diperlukan pengujian atau mitigasi lainnya sebelum peluncuran produksi.
T + 1 minggu GKE akan mulai mengupgrade node pool cluster ke versi default. 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 tidak asing dengan konsep replicas 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 dalam kumpulan node Anda diupgrade. Secara default, node pool menggunakan upgrade lonjakan. Dengan upgrade lonjakan, upgrade untuk node pool GKE, melibatkan pembuatan ulang setiap VM dalam kumpulan node. 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 diperluas saat Anda membutuhkan dukungan jangka panjang

Jika Anda ingin mempertahankan cluster sebagai anak di bawah umur versi lebih lama, ikuti praktik terbaik dengan mendaftarkan cluster Anda di Extended channel. Dengan ini Google Cloud, GKE mendukung versi minor untuk sekitar 24 bulan berikutnya. Untuk mempelajari lebih lanjut, lihat Mendapatkan dukungan jangka panjang dengan ekstensi channel.

Untuk mendapatkan manfaat maksimal dari channel ini, sebaiknya Anda mematuhi dengan mengikuti praktik terbaik. Beberapa praktik terbaik ini memerlukan pengambilan beberapa tindakan manual, termasuk meningkatkan versi secara manual kelompok dan mengubah rilis channel Anda dari sebuah cluster. Tinjau skenario yang didukung berikut, serta Jika tidak menggunakan Saluran yang diperluas.

Tetap gunakan versi minor untuk sementara lebih lama

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

Upgrade versi minor 1-2 kali per tahun

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

  • Daftarkan cluster di Saluran yang diperluas.
  • Lakukan dua upgrade versi minor berturut-turut 1-2 kali per tahun. Sebagai misalnya, tingkatkan dari 1,30 ke 1,31 ke 1,32.

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

Kapan tidak menggunakan Saluran yang diperluas

Perlu tindakan manual untuk menggunakan Saluran yang diperluas untuk tujuan yang dimaksudkan. Tujuan skenario berikut mengilustrasikan konsekuensi penggunaan Saluran yang diperluas tanpa pengelolaan aktif untuk versi minor cluster Anda.

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

Jika ingin mempertahankan cluster Anda pada versi minor selamanya, Anda harus mendaftarkan dikelompokkan di Extended channel dan tidak melakukan tindakan lebih lanjut. Semua versi minor akhirnya menjadi tidak didukung dan GKE otomatis mengupgrade cluster dari versi minor yang tidak didukung versi. Jadi, GKE mengupgrade cluster ini dari satu versi minor yang tidak didukung ke versi minor yang akan segera tidak didukung, yang rata-ratanya menjadi kira-kira setiap 4 bulan. Ini berarti cluster tersebut akan menerima upgrade versi minor sama seringnya di saluran rilis lain tetapi menerima fitur baru di kemudian hari.

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