Anda dapat mengelola urutan upgrade cluster otomatis di seluruh cluster Google Kubernetes Engine (GKE) di beberapa lingkungan menggunakan urutan peluncuran. Misalnya, Anda dapat menentukan versi baru untuk cluster praproduksi sebelum mengupgrade cluster produksi. Untuk menggunakan fitur ini, Anda harus memahami upgrade cluster, saluran rilis, dan pengelolaan fleet.
Untuk memulai, lihat Mengurutkan peluncuran upgrade cluster.
Terminologi
Dokumen ini menggunakan istilah grup untuk merujuk ke armada atau tim karena Anda dapat membuat urutan peluncuran yang diatur dengan pengelompokan .
Memenuhi syarat upgrade di seluruh lingkungan
Untuk mengupgrade cluster secara otomatis dengan pengurutan peluncuran, gunakan fleet atau tim cakupan tempat Anda mengelompokkan cluster dengan rilis yang sama channel dan anak di bawah umur menjadi tahapan deployment. Pilih urutan armada atau urutan cakupan tim dan atur caranya banyak waktu rendam pengujian yang Anda inginkan di antara setiap kelompok klaster. Kemudian, saat GKE memilih layanan untuk otomatis upgrade di saluran rilis, kelompok cluster Anda diupgrade sesuai urutan yang ditentukan, dan dapat memvalidasi bahwa beban kerja berjalan sebelum upgrade dimulai dengan cluster produksi.
Urutan peluncuran berbasis fleet
Diagram berikut mengilustrasikan cara GKE mengupgrade cluster secara otomatis dalam urutan peluncuran yang diatur dengan fleet:
Dengan urutan berbasis fleet, saat GKE menyediakan target upgrade baru di saluran rilis tempat semua cluster dalam urutan ini didaftarkan, GKE mengupgrade fleet cluster tersebut dalam urutan ini, dengan upstream cluster yang memenuhi syarat versi baru untuk cluster di fleet downstream, untuk paling banyak tiga fleet. Upstream, dalam urutan peluncuran, mengacu pada grup sebelumnya, dan downstream mengacu pada grup berikutnya.
Selama waktu rendam yang dikonfigurasi antar-armada—setelah upgrade selesai pada fleet upstream dan sebelum dimulai di fleet downstream—Anda dapat mengonfirmasi workload Anda berjalan seperti yang diharapkan pada cluster yang diupgrade.
Urutan peluncuran berbasis tim
Jika Anda telah membagi lagi cluster tersebut dalam suatu fleet berdasarkan tim atau aplikasi, Anda dapat membuat urutan peluncuran di antara cakupan tim. Cakupan tim adalah konstruksi tingkat fleet perusahaan untuk mengaitkan subset cluster fleet dengan tim aplikasi tertentu, dan dapat digunakan untuk mengaktifkan berbagai fitur berbasis tim, termasuk kontrol akses dan kemampuan observasi cakupan tim, serta urutan peluncuran.
Dengan cakupan tim, Anda dapat membuat beberapa urutan peluncuran dalam satu fleet, masing-masing dengan saluran rilis, upgrade target, dan waktu tunggu independen. J urutan peluncuran berbasis tim berfungsi identik dengan peluncuran berbasis fleet kecuali upgrade memenuhi syarat di antara cluster tim tertentu di setiap fleet, bukan fleet-ke-fleet. Hal ini sangat berguna bagi operator aplikasi yang ingin mengelola upgrade dalam cluster tim mereka sendiri.
Pengurutan peluncuran berbasis tim ada dalam Pratinjau, sedangkan peluncuran berbasis fleet pengurutan yang tersedia secara umum (GA).
Cara GKE mengupgrade cluster dalam urutan peluncuran
Saat GKE mengupgrade cluster, control plane diupgrade terlebih dahulu, lalu node diupgrade. Dalam urutan peluncuran, cluster masih diupgrade menggunakan proses ini, tetapi Anda juga mengontrol urutan kelompok (armada atau ) cluster diupgrade, dan Anda menentukan waktu tunggu untuk memilih bagaimana GKE yang lama akan dijeda sebelum upgrade dilanjutkan dari satu grup ke grup berikutnya.
Upgrade cluster dalam urutan peluncuran dilanjutkan dengan langkah-langkah berikut:
- GKE menetapkan target upgrade otomatis yang baru untuk cluster pada versi minor di saluran rilis tertentu, dengan catatan rilis yang menyebutkan sesuatu yang mirip dengan pesan berikut: "Control planes dan node dengan upgrade otomatis yang diaktifkan di saluran Reguler akan diupgrade dari versi 1.21 ke versi 1.22.15-gke.1000 dengan rilis ini".
- GKE mulai mengupgrade control plane cluster ke versi baru di grup cluster pertama. Setelah GKE mengupgrade control plane cluster, GKE akan mulai mengupgrade node cluster. GKE mematuhi ketersediaan pemeliharaan saat mengupgrade cluster dalam urutan peluncuran.
- GKE melakukan langkah-langkah berikut untuk upgrade plane control:
- GKE memulai periode perendaman untuk upgrade bidang kontrol setelah semua upgrade bidang kontrol cluster di grup pertama selesai, atau 30 hari telah berlalu sejak peningkatan versi bidang kontrol dimulai.
- Setelah periode perendaman untuk upgrade bidang kontrol cluster pada grup pertama selesai, GKE akan memulai upgrade control plane pada grup kedua.
- Selain mengontrol upgrade control plane, GKE melakukan
langkah-langkah berikut untuk upgrade node:
- GKE memulai periode berendam untuk upgrade node setelah semua upgrade node cluster dalam grup pertama selesai atau 30 hari telah berlalu sejak upgrade node dimulai.
- GKE memulai upgrade node dalam grup kedua untuk cluster dengan control plane yang telah diupgrade setelah periode perendaman upgrade node pada grup pertama selesai.
- GKE mengulangi langkah-langkah ini dari grup kedua ke grup ketiga, hingga cluster di semua grup dalam urutan peluncuran telah diupgrade ke target upgrade baru.
Saat cluster diupgrade di setiap grup, pastikan selama waktu rendam bahwa workload Anda berjalan seperti yang diharapkan dengan cluster yang menjalankan versi GKE baru.
Upgrade cluster juga mungkin tidak dapat dilakukan karena masa pemeliharaan atau pengecualian, penggunaan API yang tidak digunakan lagi, atau alasan lainnya. Untuk mempelajari lebih lanjut, baca Cara kerja pengurutan peluncuran dengan fitur upgrade lainnya.
Cara mengontrol upgrade dalam urutan peluncuran
Dengan upgrade cluster dalam urutan peluncuran, grup cluster diupgrade sesuai urutan yang telah Anda tentukan, dan tercakup dalam setiap grup selama waktu yang Anda pilih. Saat upgrade sedang berlangsung, Anda dapatperiksa status urutan peluncuran , danmengelola urutan peluncuran sesuai kebutuhan. Anda juga dapat mengontrol proses dengan cara berikut:
- Untuk grup dalam urutan peluncuran, Anda dapat mengganti waktu rendam default jika Anda memerlukan lebih banyak atau lebih sedikit perendaman untuk versi tertentu.
- Untuk upgrade masing-masing cluster, Anda dapat terus menggunakan alat berikut:
- mengontrol upgrade secara manual dengan melakukan tindakan seperti membatalkan, melanjutkan, melakukan roll back, atau menyelesaikan upgrade kumpulan node.
- Gunakan periode dan pengecualian pemeliharaan untuk menentukan kapan cluster dapat dan tidak dapat diupgrade.
- Mengonfigurasi strategi upgrade node untuk menyeimbangkan antara kecepatan dan toleransi risiko yang bergantung pada beban kerja yang berjalan pada {i>node<i} tersebut.
Untuk mempelajari lebih lanjut, lihat cara kerja pengurutan peluncuran dengan fitur upgrade lainnya.
Contoh: Bank komunitas secara bertahap meluncurkan perubahan dari Pengujian hingga Produksi
Sebagai contoh, administrator platform di bank komunitas mengelola tiga lingkungan deployment utama, yang masing-masing merupakan sekelompok cluster yang diatur dalam satu fleet: Pengujian, Tahapan, dan Produksi. Sebagaimana diperlukan untuk pengurutan peluncuran, administrator telah mendaftarkan setiap cluster di ketiga fleet dalam saluran rilis yang sama—di fleet tersebut, Saluran reguler —dengan semua cluster menjalankan versi minor yang sama.
Administrator menggunakan urutan peluncuran untuk menentukan urutan di mana GKE mengupgrade cluster di lingkungan tersebut. Mengurutkan peluncuran memberi administrator kesempatan untuk memverifikasi bahwa beban kerja mereka berjalan seperti yang diharapkan dengan cluster pada GKE versi baru sebelum lingkungan Produksi diupgrade ke versi baru. Urutan ini diilustrasikan oleh diagram urutan peluncuran berbasis fleet.
Administrator menggunakan waktu rendam antara fleet ini yang diupgrade untuk memverifikasi bahwa beban kerjanya mereka berjalan seperti yang diharapkan dengan cluster pada GKE versi baru. Untuk fleet Pengujian, administrator menetapkan waktu rendam menjadi 14 hari sehingga mereka memiliki waktu dua minggu penuh untuk menguji bagaimana beban kerja berjalan. Untuk Staging, mereka menetapkan waktu rendam ke 7 hari karena tidak memerlukan banyak waktu tambahan setelah beban kerja berjalan dalam Pengujian.
Administrator juga dapat mengganti waktu rendam default untuk upgrade ke versi tertentu, yang mungkin ingin mereka lakukan dalam salah satu situasi berikut:
- Administrator telah menyelesaikan kualifikasi versi sebelum waktu rendam selesai dan ingin upgrade dilanjutkan ke fleet berikutnya, jadi mereka menetapkan waktu rendam ke nol.
- Administrator memerlukan lebih banyak waktu untuk memenuhi syarat versi baru sebelum upgrade melanjutkan ke perangkat berikutnya karena terdapat masalah pada beberapa beban kerjanya, sehingga mereka menetapkan waktu rendam menjadi maksimum 30 hari.
Administrator menggunakan masa pemeliharaan dan pengecualian untuk memastikan bahwa GKE mengupgrade cluster saat tidak mengganggu bank. GKE mempertimbangkan ketersediaan pemeliharaan untuk cluster yang diupgrade dalam urutan peluncuran.
- Administrator telah mengonfigurasi masa pemeliharaan untuk cluster mereka guna memastikan bahwa GKE hanya mengupgrade cluster setelah jam kerja.
- Administrator juga menggunakan pengecualian pemeliharaan agar cluster tidak diupgrade untuk sementara jika menemukan masalah dengan beban kerja cluster.
Administrator menggunakan kombinasi upgrade surgedan blue-green untuk node, yang menyeimbangkan antara kecepatan dan toleransi risiko, tergantung pada beban kerja yang berjalan pada node tersebut.
Administrator beralih ke urutan peluncuran berbasis tim
Jika administrator memutuskan bahwa mereka perlu mengelompokkan cluster lebih lanjut di dalam perangkat demi aplikasi, dan memberi admin tim aplikasi kontrol lebih besar atas upgrade cluster mereka, mereka dapat menggunakan cakupan tim. Dengan cakupan tim, admin tim aplikasi dapat membuat peluncuran independen dengan kelompok klaster yang ditugaskan ke tim mereka, yang berpotensi berjalan di saluran rilis yang berbeda, atau dengan waktu rendam yang berbeda.
Misalnya, jika tim {i>database<i} ingin cluster mereka menggunakan Saluran stabil dan waktu rendam yang lebih lama saat cluster tim situs frontend menggunakan saluran Cepat dan waktu rendam yang lebih pendek, mereka dapat menggunakan cakupan tim untuk membuat urutan peluncuran yang terpisah. Jenis urutan ini diilustrasikan oleh urutan peluncuran berbasis tim diagram. Untuk melakukannya bagi lingkungan Anda, ikuti petunjuk untuk beralih antara peluncuran berbasis fleet dan berbasis tim urutan.
Perhatikan bahwa penggunaan fitur ini memerlukan cluster tenancy tunggal: dengan kata lain, setiap cluster individual hanya terkait dengan satu tim. Cluster bersama (yang didukung dalam pengelolaan tim fleet umum) tidak didukung untuk pengurutan peluncuran. Anda dapat mempelajari lebih lanjut cara mengelola cluster untuk tim di Pengelolaan tim staf.
Kelayakan peluncuran
Agar cluster dapat diupgrade secara otomatis dengan urutan peluncuran, semua cluster di semua grup (fleet atau cakupan) dalam urutan peluncuran harus menerima target upgrade yang sama. Cluster harus didaftarkan di saluran rilis yang sama, dan sebaiknya cluster menjalankan versi minor yang sama dengan target upgrade ditetapkan per versi minor. Namun, untuk beberapa rilis, seperti rilis dalam contoh berikut, cluster dari beberapa versi minor menerima target yang sama, yang berarti bahwa cluster dapat berhasil diupgrade dalam urutan peluncuran yang menjalankan beberapa versi minor.
Anda dapat memeriksa status peluncuran versi secara urutan untuk mendapatkan informasi selengkapnya tentang status dan apakah masalah kelayakan versi mencegah upgrade dilanjutkan. Perbedaan versi akan menentukan apakah Anda mungkin perlu mengambil tindakan seperti mengupgrade cluster secara manual atau menghapusnya dari grup agar upgrade cluster dapat dilanjutkan. Jika cluster berada dalam urutan peluncuran tidak memiliki target upgrade yang valid, GKE tidak akan melakukan upgrade secara otomatis cluster tersebut hingga versi minor yang ada mencapai akhir masa pakai.
Untuk memecahkan masalah kelayakan peluncuran, lihat Memecahkan masalah peluncuran yang memenuhi syarat.
Contoh rilis GKE
Misalnya, rilis 2022-R25 menetapkan target upgrade untuk beberapa versi minor dalam cluster yang terdaftar di saluran Reguler. Target upgrade dapat berupa versi minor baru (1.20 hingga 1.21), atau hanya versi patch baru (1.21.x-gke.x hingga 1.21.14-gke.4300). Dalam rilis ini, di saluran Reguler, versi baru berikut tersedia untuk cluster pada versi minor tertentu:
- Klaster pada 1.20 dan 1.21 ditingkatkan ke 1.21.14-gke.4300.
- Klaster pada 1.22 ditingkatkan menjadi 1.23.8-gke.1900.
- Klaster pada 1.24 ditingkatkan menjadi 1.24.5-gke.600.
Grup paling mendekati hulu (asal) menerima semua target upgrade
Untuk cluster dalam grup pertama dalam urutan, yang tidak memiliki grup upstream untuk memenuhi syarat versi baru, GKE mengupgrade semua cluster dengan target upgrade yang memenuhi syarat, terlepas dari apakah target upgrade tersebut berbeda dari masing-masing cluster lainnya. Misalnya, pada grup pertama dalam urutan, jika beberapa cluster menjalankan versi 1.20, cluster tersebut dapat diupgrade ke 1.21.14-gke.4300, dan cluster yang menjalankan 1.24 dapat diupgrade ke 1.24.5- gke.600. Ini karena, untuk grup pertama dalam urutan, GKE menganggap semua target upgrade memenuhi syarat untuk cluster ini karena tidak ada grup upstream yang memenuhi syarat untuk versi baru.
Grup upstream hanya boleh memenuhi syarat untuk satu versi
Pada grup downstream, GKE dapat mengupgrade cluster apabila grup upstream memenuhi satu target upgrade di mana semua cluster dalam grup ini memenuhi syarat. Biasanya, ini berarti semua cluster dimulai pada versi minor yang sama. Namun, dari contoh rilis, cluster pada versi 1.20 dan 1.21 memiliki target upgrade yang sama, sehingga cluster yang menjalankan kedua versi tersebut dapat memenuhi syarat upgrade untuk 1.21.14-gke.4300 dalam grup yang sama.
Jika semua cluster dalam satu grup tidak memiliki target upgrade yang sama, grup ini tidak dapat memenuhi syarat satu target upgrade untuk grup berikutnya. Dalam kondisi ini, GKE tidak dapat secara otomatis mengupgrade cluster dalam grup downstream. Misalnya, jika dalam grup pertama beberapa cluster diupgrade ke 1.21.14-gke.4300, dan yang lainnya ke 1.23.8-gke.1900, cluster grup kedua tidak dapat diupgrade secara otomatis karena tidak menerima satu versi yang memenuhi syarat. Untuk melanjutkan upgrade dalam situasi ini, lihat Memperbaiki kelayakan dalam grup.
Grup upstream harus memenuhi syarat versi yang cocok dengan cluster grup berikutnya
Jika cluster dalam grup upstream memenuhi syarat untuk versi yang berbeda dari versi yang dipenuhi syaratnya oleh cluster di grup berikutnya, GKE juga tidak dapat secara otomatis mengupgrade cluster dalam grup downstream mana pun.
Misalnya, jika semua cluster dalam grup pertama diupgrade ke 1.21.14-gke.4300, tetapi cluster pada grup kedua menjalankan versi 1.22 (dengan target upgrade adalah 1.23.8-gke.1900 ), cluster grup kedua tidak akan diupgrade secara otomatis. Grup pertama memenuhi syarat 1.21.14-gke.4300, tetapi cluster dalam grup kedua (saat ini 1.22) hanya memenuhi syarat untuk target upgrade 1.23.8-gke.1900, sehingga GKE tidak bisa secara otomatis upgrade cluster ini. Untuk melanjutkan upgrade dalam situasi ini, lihat Memperbaiki kelayakan antar grup.
Cara kerja pengurutan peluncuran dengan fitur upgrade lainnya
Pengurutan peluncuran adalah salah satu fitur dalam kumpulan fitur yang memberi Anda kontrol atas aspek upgrade dari siklus proses cluster. Bagian ini menjelaskan cara kerja fitur ini dengan beberapa fitur lain yang tersedia terkait upgrade cluster.
Cara kerja urutan peluncuran dengan masa pemeliharaan dan pengecualian
GKE mempertimbangkan masa pemeliharaan dan pengecualian pemeliharaan saat mengupgrade cluster dengan urutan peluncuran. GKE hanya memulai upgrade cluster dalam masa pemeliharaan cluster. Anda dapat menggunakan pengecualian pemeliharaan agar cluster tidak diupgrade untuk sementara. Jika GKE tidak dapat mengupgrade cluster karena masa pemeliharaan atau pengecualian, hal ini dapat menghambat penyelesaian upgrade cluster dalam sebuah grup. Jika upgrade cluster tidak dapat diselesaikan dalam waktu 30 hari karena masa pemeliharaan atau pengecualian, grup akan memasuki fase rendam meskipun tidak semua cluster telah selesai diupgrade.
Anda dapat menggunakan pengecualian pemeliharaan sebagai tindakan sementara untuk mencegah urutan menyelesaikan peluncuran ke grup dan berpindah ke grup berikutnya. Untuk mempelajari lebih lanjut, lihat Menunda penyelesaian peluncuran versi grup.
Cara kerja pengurutan peluncuran dengan deteksi penggunaan penghentian
GKE menjeda upgrade cluster saat mendeteksi penggunaan API dan fitur tertentu yang tidak digunakan lagi. Upgrade otomatis juga dijeda untuk cluster dalam grup dalam urutan peluncuran. Untuk mempelajari lebih lanjut, baca Cara kerja penghentian penggunaan Kubernetes dengan GKE.
Cara kerja pengurutan peluncuran dengan strategi upgrade node
Upgrade node akan menggunakan strategi upgrade node yang dikonfigurasi saat diupgrade dalam urutan peluncuran. Seperti halnya upgrade cluster tanpa peluncuran urutan peluncuran, GKE menggunakan surge upgrade untuk node Autopilot. Untuk informasi selengkapnya, lihat Upgrade node otomatis.
Jika upgrade node tidak dapat diselesaikan dalam waktu 30 hari, grup akan memasuki fase rendamnya terlepas dari apakah semua cluster telah selesai diupgrade. Hal ini dapat terjadi jika strategi upgrade node menyebabkan upgrade node cluster Standar memerlukan waktu lebih lama untuk diselesaikan, terutama jika berupa kumpulan node yang besar. Hal ini juga dapat diperburuk oleh masa pemeliharaan yang tidak cukup besar untuk menyelesaikan upgrade node. Untuk mempelajari lebih lanjut, lihat Pertimbangan saat mengonfigurasi masa pemeliharaan.
Cara kerja urutan peluncuran dengan saluran rilis
Saluran rilis diperlukan untuk menggunakan urutan peluncuran. Semua cluster di semua grup dalam urutan peluncuran harus berada di saluran rilis yang sama.
Menerima beberapa upgrade dalam satu urutan
Jika versi baru menjadi target upgrade pada saluran rilis disaat upgrade cluster ke target upgrade sebelumnya masih dilanjutkan dalam urutan peluncuran, maka grup upstream dapat memulai peluncuran versi baru saat grup downstream masih menerima upgrade versi sebelumnya. Misalnya, jika grup ketiga dalam suatu urutan meluncurkan 1.24.2-gke.100, grup pertama dalam urutan dapat secara serentak meluncurkan 1.24.3-gke.500.
Pertimbangan saat memilih urutan peluncuran
Pertimbangkan untuk menggunakan urutan peluncuran jika Anda ingin mengelola upgrade cluster dengan memenuhi syarat untuk versi baru di satu lingkungan sebelum meluncurkannya ke lingkungan lain.
Namun, ini mungkin bukan pilihan yang tepat untuk lingkungan Anda jika salah satu pernyataan berikut benar:
- Anda memiliki cluster yang tidak berada di saluran rilis atau versi minor yang sama di lingkungan produksi yang sama.
- Anda perlu mengotomatiskan upgrade yang tidak dapat dipetakan ke tiga tahap deployment saja, karena Anda hanya dapat membuat urutan peluncuran dengan maksimal tiga grup cluster. Anda tidak dapat menautkan grup dalam beberapa urutan peluncuran untuk membuat urutan peluncuran dengan lebih dari tiga grup.
- Anda tidak dapat menggunakan pengelolaan fleet.
- Anda sering melakukan upgrade manual yang menyebabkan cluster dalam satu grup memiliki versi target upgrade otomatis yang berbeda.
Untuk membuat urutan peluncuran berbasis tim, Anda juga harus dapat mengaktifkan GKE Enterprise di fleet Anda project host.
Batasan
Agar berhasil mengupgrade cluster dengan urutan peluncuran, Anda harus mematuhi batasan berikut:
- Jika Anda menggunakan pengurutan peluncuran berbasis tim, daftarkan cluster hanya dalam satu cakupan tim. Jika sebuah cluster terdaftar di beberapa cakupan tim, GKE tidak dapat otomatis mengupgrade cluster dalam urutan peluncuran.
- Membuat urutan peluncuran berbasis tim dengan beberapa cakupan tim dalam satu cakupan perangkat Anda tidak didukung.
- Buat urutan peluncuran linear tanpa siklus (grup memiliki grup downstream sebagai grup upstreamnya) atau cabang (grup memiliki lebih dari satu grup downstream).
- Buat urutan peluncuran di antara cakupan tim, atau urutan peluncuran antar- fleet. Anda tidak dapat membuat urutan campuran dengan cakupan fleet dan tim di urutan yang sama.
- Pastikan bahwa semua cluster dalam urutan peluncuran terdaftar di saluran rilis yang sama, dan menjalankan versi minor yang sama.
Masalah umum
- Jika grup berisi cluster dari lokasi yang berbeda, upgrade cluster mungkin hanya tersedia untuk sementara beberapa cluster karena peluncuran versi baru secara bertahap. Hal ini lebih mungkin terjadi pada kelompok klaster pertama dan akan selesai dalam waktu seminggu.
- Jika ada grup kosong dalam urutan peluncuran, pengaruhnya terhadap kualifikasi
versi ditentukan oleh kondisi berikut.
- Jika grup kosong tidak memiliki grup upstream, upgrade cluster tidak akan dilanjutkan ke grup downstream karena grup kosong tidak dapat memenuhi syarat versi.
- Jika grup kosong memiliki grup upstream, semua upgrade cluster yang tertunda akan memasuki
status
COMPLETE
dan menyebarkannya ke grup downstream.
- Karena cara GKE melacak patch dan upgrade minor, Anda mungkin melihat dua upgrade dari jenis dan versi yang sama tetapi dengan status yang berbeda saat memeriksa status cakupannya.