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 cakupan tim atau fleet, karena Anda dapat membuat urutan peluncuran yang diatur dengan metode pengelompokan.
Memenuhi syarat upgrade di seluruh lingkungan
Untuk mengupgrade cluster secara otomatis dengan urutan peluncuran, gunakan fleets atau cakupan tim tempat Anda mengelompokkan cluster dengan saluran rilis dan versi minor yang sama ke dalam tahap-tahap deployment. Pilih urutan fleet atau urutan cakupan tim, lalu tetapkan berapa lama waktu pengujian perendaman yang Anda inginkan di antara setiap grup cluster. Kemudian, saat GKE memilih versi baru untuk upgrade otomatis di saluran rilis, grup cluster Anda akan diupgrade sesuai urutan yang telah Anda tentukan, dan Anda dapat memvalidasi bahwa beban kerja berjalan seperti yang diharapkan dengan versi baru 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, merujuk ke grup sebelumnya, dan downstream merujuk ke grup berikutnya.
Selama waktu perendaman yang dikonfigurasi di antara fleet—setelah upgrade selesai di fleet upstream dan sebelum dimulai di fleet downstream—Anda dapat mengonfirmasi bahwa beban kerja Anda berjalan seperti yang diharapkan di cluster yang diupgrade.
Urutan peluncuran berbasis tim
Jika telah membagi cluster dalam fleet lebih lanjut menurut tim atau aplikasi, Anda dapat membuat urutan peluncuran antar-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 visibilitas cakupan tim serta urutan peluncuran.
Dengan cakupan tim, Anda dapat membuat beberapa urutan peluncuran dalam satu fleet, masing-masing dengan saluran rilisnya sendiri, target upgrade, dan waktu rendam independen. Urutan peluncuran berbasis tim berfungsi identik dengan urutan peluncuran berbasis fleet, kecuali upgrade memenuhi syarat antara cluster tim tertentu di setiap fleet, bukan fleet-to-fleet. Hal ini sangat berguna bagi operator aplikasi yang ingin mengelola upgrade dalam cluster tim mereka sendiri.
Urutan peluncuran berbasis tim masih dalam Pratinjau, sedangkan urutan peluncuran berbasis fleet 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 dapat mengontrol urutan grup (fleet atau cakupan) cluster diupgrade, dan menentukan waktu rendam untuk memilih berapa lama GKE 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 mengupgrade control plane setelah semua upgrade control plane cluster dalam grup pertama selesai, atau 30 hari telah berlalu sejak upgrade control plane 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.
- Konfigurasi strategi upgrade node untuk menyeimbangkan antara kecepatan dan toleransi risiko, bergantung pada beban kerja yang berjalan pada node 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 fleet berdasarkan aplikasi, dan memberi admin tim aplikasi mereka kontrol yang lebih besar atas upgrade cluster, mereka dapat menggunakan cakupan tim. Dengan cakupan tim, admin tim aplikasi dapat membuat urutan peluncuran independen dengan grup cluster yang ditetapkan ke tim mereka, yang berpotensi berjalan di saluran rilis yang berbeda, atau dengan waktu tunggu yang berbeda.
Misalnya, jika tim database ingin cluster mereka menggunakan saluran Stabil dan waktu perendaman yang lebih lama, sedangkan cluster tim situs frontend menggunakan saluran Cepat dan waktu perendaman yang lebih singkat, mereka dapat menggunakan cakupan tim untuk membuat urutan peluncuran terpisah. Jenis urutan ini diilustrasikan oleh diagram urutan peluncuran berbasis tim. Untuk melakukannya bagi lingkungan Anda, ikuti petunjuk untuk beralih antara urutan peluncuran berbasis fleet dan berbasis tim.
Perhatikan bahwa penggunaan fitur ini memerlukan cluster single-tenancy: dengan kata lain, setiap cluster hanya dikaitkan dengan satu tim. Cluster bersama (yang didukung dalam pengelolaan tim armada umum) tidak didukung untuk pengurutan peluncuran. Anda dapat mempelajari lebih lanjut cara mengelola cluster untuk tim di Pengelolaan tim fleet.
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 dalam urutan peluncuran tidak memiliki target upgrade yang memenuhi syarat, GKE tidak akan mengupgrade cluster secara otomatis hingga versi minor cluster yang ada mencapai akhir siklus proses.
Untuk memecahkan masalah kelayakan peluncuran, lihat Memecahkan masalah kelayakan peluncuran.
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 project host fleet.
Batasan
Agar berhasil mengupgrade cluster dengan urutan peluncuran, Anda harus mematuhi batasan berikut:
- Jika Anda menggunakan urutan peluncuran berbasis tim, daftarkan cluster hanya dalam satu cakupan tim. Jika sebuah cluster didaftarkan dalam beberapa cakupan tim, GKE tidak dapat mengupgrade cluster tersebut secara otomatis dalam urutan peluncuran berbasis tim.
- Membuat urutan peluncuran berbasis tim dengan beberapa cakupan tim dalam fleet yang sama 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 antar-cakupan tim, atau urutan peluncuran antar-fleet. Anda tidak dapat membuat urutan campuran dengan fleet dan cakupan tim dalam 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
COMPLETEdan 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.