Tentang upgrade cluster dengan urutan peluncuran

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 pada fleet atau cakupan tim, karena Anda dapat membuat urutan peluncuran yang diatur dengan metode pengelompokan tersebut.

Memenuhi syarat upgrade di seluruh lingkungan

Untuk mengupgrade cluster secara otomatis dengan urutan peluncuran, gunakan fleet 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, dan tetapkan berapa lama waktu pengujian soak 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:

Urutan peluncuran berbasis fleet. Anda dapat mengatur cluster ke dalam fleet, atau membaginya lebih lanjut dalam fleet dengan cakupan.

Dengan urutan berbasis fleet, saat GKE menyediakan target upgrade baru di saluran rilis tempat semua cluster dalam urutan ini terdaftar, GKE akan mengupgrade fleet cluster ini dalam urutan ini, dengan cluster fleet upstream yang memenuhi syarat versi baru untuk cluster di fleet downstream, hingga lima 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 hulu dan sebelum dimulai di fleet hilir—Anda dapat mengonfirmasi bahwa beban kerja Anda berjalan seperti yang diharapkan pada cluster yang diupgrade.

Urutan peluncuran berbasis tim

Jika Anda telah membagi lebih lanjut cluster dalam fleet 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 kemampuan observasi yang tercakup dalam tim serta pengurutan peluncuran.

Urutan peluncuran berbasis cakupan. Anda dapat mengatur cluster ke dalam fleet, atau membaginya lebih lanjut dalam fleet dengan cakupan.

Dengan cakupan tim, Anda dapat membuat beberapa urutan peluncuran dalam satu fleet, masing-masing dengan saluran rilisnya sendiri, target upgrade, dan waktu tunggu 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.

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:

  1. 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".
  2. 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.

  3. GKE melakukan langkah-langkah berikut untuk upgrade bidang kontrol:

    1. GKE memulai periode perendaman untuk upgrade control plane setelah semua upgrade control plane cluster dalam grup pertama selesai. GKE juga memulai periode perendaman jika lebih dari 30 hari telah berlalu sejak upgrade control plane dimulai. Untuk mengetahui informasi selengkapnya, lihat Upgrade yang tidak diselesaikan dalam waktu 30 hari akan dipaksa untuk direndam guna membuka blokir urutan.

    2. Setelah periode perendaman untuk upgrade bidang kontrol cluster pada grup pertama selesai, GKE akan memulai upgrade bidang kontrol pada grup kedua ke versi baru. Namun, pahami batasan berikut:

  4. Selain mengontrol upgrade control plane, GKE melakukan langkah-langkah berikut untuk upgrade node:

    1. GKE memulai periode perendaman untuk upgrade node setelah semua upgrade node cluster dalam grup pertama selesai. GKE juga memulai periode perendaman jika lebih dari 30 hari telah berlalu sejak upgrade node dimulai. Untuk mengetahui informasi selengkapnya, lihat Upgrade yang tidak diselesaikan dalam waktu 30 hari akan dipaksa untuk direndam guna membuka blokir urutan.
    2. Setelah periode perendaman untuk upgrade node dalam grup pertama selesai, GKE akan memulai upgrade node dalam grup kedua ke versi baru. Namun, pahami peringatan berikut:

  5. 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 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 memberikan kontrol yang lebih besar kepada admin tim aplikasi atas upgrade cluster mereka, 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 channel Stabil dan waktu pengujian yang lebih lama, sementara cluster tim situs frontend menggunakan channel Cepat dan waktu pengujian 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 yang ada di cluster mencapai akhir dukungan.

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.

Cluster yang menjalankan versi yang lebih baru dari target upgrade tidak mencegah upgrade

Jika grup downstream memiliki cluster yang menjalankan versi yang lebih baru daripada target upgrade yang memenuhi syarat oleh grup upstream, GKE akan mengupgrade cluster yang memenuhi syarat untuk target upgrade dan mengabaikan cluster yang sudah menggunakan versi yang lebih baru. Hal ini tidak mencegah urutan peluncuran berlanjut, selama setidaknya satu cluster dalam grup downstream memenuhi syarat untuk target upgrade.

Misalnya, jika grup upstream memenuhi syarat upgrade ke 1.23, dan grup downstream memiliki cluster yang menjalankan 1.22 dan 1.24, GKE akan mengupgrade cluster yang menjalankan 1.22 ke 1.23, dan mengabaikan cluster yang menjalankan 1.24.

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.

Grup upstream memenuhi syarat beberapa target upgrade untuk grup downstream

Jika GKE mengupgrade cluster dalam grup upstream beberapa kali sebelum mengupgrade cluster dalam grup downstream, GKE akan mengupgrade cluster dalam grup downstream ke versi terbaru yang memenuhi syarat oleh grup upstream, yang memenuhi syarat untuk cluster dalam grup downstream. Untuk upgrade bidang kontrol, versi ini paling banyak satu versi minor lebih baru daripada versi bidang kontrol cluster dalam grup hilir. Untuk upgrade node, versi ini dapat sama dengan, tetapi tidak lebih baru dari versi bidang kontrol cluster dalam grup downstream.

Misalnya, skenario ini relevan jika Anda telah mengonfigurasi pengecualian pemeliharaan untuk mencegah upgrade sementara untuk grup hilir, yang mencakup cluster produksi Anda. Namun, grup upstream Anda, yang mencakup cluster praproduksi, juga tidak menggunakan pengecualian pemeliharaan untuk mencegah upgrade. Jadi, grup upstream Anda diupgrade beberapa kali, sehingga memenuhi syarat beberapa target upgrade potensial, sementara grup downstream Anda tidak diupgrade.

Upgrade yang tidak diselesaikan dalam waktu 30 hari akan dipaksa direndam untuk membuka blokir urutan

Untuk memastikan urutan peluncuran selesai mengupgrade cluster, GKE memulai periode perendaman untuk grup jika upgrade bidang kontrol atau node, masing-masing, tidak selesai di semua cluster dalam waktu upgrade maksimum (30 hari). Upgrade untuk cluster yang tersisa dalam grup masih dapat dilanjutkan selama periode penyerapan. Untuk mengetahui informasi selengkapnya, lihat baris untuk FORCED_SOAKING di Tabel informasi status untuk urutan peluncuran.

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 lima tahap deployment saja, karena Anda hanya dapat membuat urutan peluncuran dengan maksimal lima grup cluster. Anda tidak dapat menautkan grup dalam beberapa urutan peluncuran untuk membuat urutan peluncuran dengan lebih dari lima grup. Urutan berbasis fleet dapat mencakup hingga lima fleet, dan urutan berbasis tim dapat mencakup hingga tiga cakupan tim.
  • 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:

  • Pastikan semua cluster dalam urutan peluncuran terdaftar di saluran rilis yang sama. Sebaiknya semua cluster menjalankan versi minor yang sama agar memenuhi syarat satu target upgrade. Untuk mengetahui informasi selengkapnya, lihat Kelayakan peluncuran.
  • Jika Anda menggunakan pengurutan 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.
  • Buat urutan peluncuran antar-cluster dalam organisasi yang sama. Anda tidak dapat membuat urutan dengan cluster di beberapa organisasi.

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.

Langkah selanjutnya