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. GKE juga menyediakan versi urutan peluncuran yang menggunakan tahap kustom (Pratinjau) untuk memberi Anda kontrol yang lebih terperinci atas upgrade cluster.

Dokumen ini mengasumsikan bahwa Anda sudah mengetahui hal-hal berikut:

Untuk mengonfigurasi urutan peluncuran, lihat Mengurutkan peluncuran upgrade cluster.

Ringkasan

Urutan peluncuran GKE memungkinkan Anda menentukan urutan upgrade cluster yang spesifik dan teratur di seluruh lingkungan—seperti mengupgrade cluster di lingkungan pengembangan terlebih dahulu, lalu lingkungan pengujian, dan terakhir produksi. Strategi progresif ini menyediakan waktu pemrosesan bawaan, sehingga Anda dapat menemukan dan memitigasi potensi masalah sebelum upgrade mencapai sistem paling penting Anda.

Pengurutan peluncuran dibangun berdasarkan konsep armada, yang merupakan pengelompokan logis cluster GKE yang dipetakan ke lingkungan (misalnya, pengujian). Untuk menggunakan fitur ini, Anda menentukan urutan yang terdiri dari fleet dan menetapkan waktu berdiam di antara setiap grup. Saat GKE memilih versi baru, cluster Anda akan diupgrade dalam urutan yang ditentukan, sehingga Anda dapat memvalidasi beban kerja sebelum versi di-deploy sepenuhnya ke lingkungan produksi Anda.

Fleet mendukung keanggotaan ringan, yang memungkinkan Anda mengelompokkan cluster secara logis untuk urutan peluncuran tanpa mengaktifkan semua konfigurasi dan fitur tingkat fleet. Keanggotaan ringan adalah pilihan yang baik jika Anda ingin menggunakan pengurutan peluncuran tanpa beberapa implikasi lain dari pengelolaan fleet penuh, seperti kesamaan namespace tingkat fleet. Untuk mengetahui informasi selengkapnya, lihat Langganan ringan.

Memilih strategi pengurutan peluncuran

GKE menawarkan dua versi urutan peluncuran. Kedua versi dibangun berdasarkan prinsip inti yang sama, yaitu upgrade progresif berbasis fleet, tetapi menawarkan tingkat fleksibilitas yang berbeda. Bagian ini membantu Anda memutuskan versi mana yang paling sesuai untuk kasus penggunaan Anda.

  • Pengurutan peluncuran berbasis fleet (GA): versi ini adalah strategi yang direkomendasikan untuk sebagian besar kasus penggunaan produksi. Pengurutan peluncuran berbasis fleet menyediakan metode yang stabil dan didukung untuk meluncurkan upgrade secara progresif di seluruh lingkungan (seperti pengujian, staging, dan produksi), serta menggunakan urutan fleet linier.

  • Urutan peluncuran dengan tahap kustom (Pratinjau): versi ini adalah evolusi model berbasis fleet, yang menawarkan kontrol dan fleksibilitas yang lebih terperinci. Dengan tahap kustom, Anda dapat menentukan tahap tertentu dalam armada menggunakan label, sehingga menjadikannya pilihan yang tepat untuk strategi peluncuran yang lebih kompleks seperti men-deploy versi baru pada subkumpulan kecil cluster produksi sebelum peluncuran yang lebih luas. Pilih opsi ini jika Anda memerlukan fleksibilitas lebih atau ingin melihat pratinjau kemampuan pengurutan peluncuran terbaru.

Urutan peluncuran berbasis fleet

Untuk mengupgrade cluster secara otomatis dengan urutan peluncuran, gunakan fleet tempat Anda mengelompokkan cluster dengan saluran rilis dan versi minor yang sama ke dalam tahap-tahap deployment. Tentukan urutan fleet dan waktu 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.

Diagram berikut mengilustrasikan cara GKE mengupgrade cluster secara otomatis dalam urutan peluncuran yang diatur dengan fleet:

Urutan peluncuran berbasis fleet tempat Anda mengelompokkan cluster ke dalam fleet.
Gambar: Urutan peluncuran berbasis fleet

Dengan urutan berbasis armada, saat GKE menyediakan target upgrade baru di saluran rilis tempat semua cluster dalam urutan ini terdaftar, GKE akan mengupgrade armada cluster ini dalam urutan ini, dengan cluster armada upstream yang memenuhi syarat versi baru untuk cluster di armada downstream, hingga lima armada. Upstream, dalam urutan peluncuran, mengacu pada grup sebelumnya, dan downstream mengacu pada grup berikutnya.

Selama waktu perendaman yang dikonfigurasi di antara fleet, Anda dapat memastikan bahwa beban kerja Anda berjalan seperti yang diharapkan pada cluster yang diupgrade.

Urutan peluncuran dengan tahap kustom

Saat menggunakan pengurutan peluncuran dengan tahap kustom, Anda menentukan urutan upgrade armada dan menetapkan waktu perendaman. Selain itu, Anda juga dapat melakukan hal berikut:

  • Tentukan urutan dengan tahapan terperinci yang dapat menargetkan subkumpulan cluster tertentu dalam armada menggunakan label, sehingga menjadikannya pilihan yang baik untuk strategi seperti peluncuran bertahap.
  • Dapatkan kontrol dan kemampuan pengamatan yang lebih baik melalui objek API RolloutSequence dan Rollout yang baru.

Metode ini memberikan fleksibilitas dan kontrol terperinci terbesar atas upgrade cluster Anda. Untuk menargetkan subset cluster tertentu dalam armada, Anda menggunakan label-selector untuk menargetkan hanya cluster yang memiliki label Kubernetes tertentu.

Diagram berikut mengilustrasikan cara GKE mengupgrade cluster secara otomatis dalam urutan peluncuran yang menggunakan tahap kustom. Target tahap cluster dengan label-selector bernama canary di fleet prod:

Urutan peluncuran dengan tahap kustom di GKE.
Gambar: Urutan peluncuran dengan tahapan kustom

Saat target upgrade baru tersedia di saluran rilis tempat semua cluster dalam urutan ini terdaftar, GKE akan mengupgrade cluster di fleet Pengujian terlebih dahulu, diikuti dengan cluster di fleet Staging. Kemudian, di fleet Production, GKE memprioritaskan cluster yang cocok dengan label-selector. Karena prod-cluster-1 diberi label dengan canary: true, GKE akan mengupgrade cluster ini berikutnya. GKE mengupgrade semua cluster yang tersisa di fleet Produksi (di tahap Utama) di akhir proses karena tahap ini tidak memiliki pemilih label.

Selama waktu perendaman yang dikonfigurasi di antara tahap, Anda dapat memastikan bahwa beban kerja Anda berjalan seperti yang diharapkan pada cluster yang diupgrade. Contoh sebelumnya menunjukkan satu tahap kustom di fleet Produksi, tetapi Anda dapat menambahkan beberapa tahap ke fleet mana pun atau hanya menggunakan satu fleet dengan beberapa tahap.

Untuk mengetahui informasi selengkapnya tentang urutan peluncuran dengan tahap kustom, lihat Tentang urutan peluncuran dengan tahap kustom.

Bagian selanjutnya dari dokumen ini hanya berkaitan dengan pengurutan peluncuran berbasis fleet.

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) cluster diupgrade. Anda juga menentukan waktu berdiam yang menentukan berapa lama GKE 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 baru untuk cluster pada versi minor di saluran rilis tertentu, dengan catatan rilis yang mirip dengan pesan berikut: "Bidang kontrol dan node dengan upgrade otomatis yang diaktifkan di saluran Reguler akan diupgrade dari versi 1.29 ke versi 1.30.14-gke.1150000 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. Setelah semua upgrade control plane cluster dalam grup pertama selesai, GKE akan memulai periode perendaman untuk upgrade control plane. GKE juga memulai periode perendaman jika lebih dari 30 hari telah berlalu sejak upgrade control plane dimulai.

    2. Setelah periode perendaman untuk upgrade control plane cluster grup pertama selesai, GKE akan mulai mengupgrade control plane grup kedua ke versi baru. Namun, perhatikan pertimbangan berikut:

      • Dalam beberapa kasus, GKE mungkin mengupgrade bidang kontrol cluster grup pertama beberapa kali sebelum mengupgrade bidang kontrol cluster grup kedua. Jika situasi ini terjadi, GKE akan memilih versi terbaru yang juga memiliki atribut berikut:
        • Versi memenuhi syarat oleh grup pertama.
        • Versi ini paling banyak satu versi minor lebih baru daripada versi bidang kontrol cluster grup kedua.
      • GKE tidak mengupgrade control plane cluster dalam grup kedua yang memiliki versi lebih baru daripada target upgrade otomatis yang memenuhi syarat oleh grup pertama.

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

    1. Setelah semua upgrade node cluster dalam grup pertama selesai, GKE memulai periode perendaman untuk upgrade node. GKE juga memulai periode perendaman jika lebih dari 30 hari telah berlalu sejak upgrade node dimulai.
    2. Setelah periode perendaman untuk upgrade node grup pertama selesai, GKE akan mulai mengupgrade node grup kedua ke versi baru. Namun, perhatikan pertimbangan berikut:
      • Dalam beberapa kasus, GKE mungkin mengupgrade node cluster grup pertama beberapa kali sebelum mengupgrade node cluster grup kedua. Jika situasi ini terjadi, GKE akan memilih versi terbaru yang juga memiliki atribut berikut:
        • Versi memenuhi syarat oleh grup pertama.
        • Versinya tidak lebih baru dari versi bidang kontrol cluster grup kedua.
      • GKE tidak mengupgrade node cluster dalam grup kedua yang memiliki versi lebih baru daripada target upgrade otomatis yang memenuhi syarat oleh grup pertama.

  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, selama waktu rendam, pastikan beban kerja Anda dengan cluster yang menjalankan versi GKE baru berfungsi seperti yang diharapkan .

Upgrade cluster juga mungkin tidak dapat dilakukan karena masa pemeliharaan atau pengecualian, penggunaan API yang tidak digunakan lagi, atau alasan lainnya.

Cara mengontrol upgrade dalam urutan peluncuran

Dengan upgrade cluster dalam urutan peluncuran, grup cluster diupgrade sesuai urutan yang Anda tentukan, dan tercakup dalam setiap grup selama waktu yang Anda pilih. Saat upgrade sedang berlangsung, Anda dapat memeriksa status dan mengelola 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 node pool.
    • 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.

Contoh: Bank komunitas secara bertahap meluncurkan perubahan dari Pengujian hingga Produksi

Sebagai contoh, administrator platform di bank komunitas mengelola tiga lingkungan deployment utama: Pengujian, Staging, dan Produksi. Setiap lingkungan memiliki grup cluster yang diatur dalam fleet. 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 untuk memverifikasi bahwa beban kerjanya berjalan seperti yang diharapkan 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 mengizinkan 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 sehingga 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.

Kelayakan peluncuran berbasis fleet

Agar cluster dapat diupgrade secara otomatis dengan urutan peluncuran, semua cluster di semua fleet 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 2025-R45 menetapkan target upgrade untuk beberapa versi minor dalam cluster yang terdaftar di saluran Reguler. Target upgrade dapat berupa versi minor baru (1.30 hingga 1.31), atau hanya versi patch baru (1.31.x-gke.x hingga 1.31.13-gke.1023000). Dalam rilis ini, di saluran Reguler, versi baru berikut tersedia untuk cluster pada versi minor tertentu:

  • Cluster pada 1.30 diupgrade ke 1.31.13-gke.1023000.
  • Cluster pada 1.31 diupgrade ke 1.32.9-gke.1108000.
  • Cluster pada 1.32 diupgrade ke 1.33.5-gke.1162000.

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.30, cluster tersebut dapat diupgrade ke 1.31.13-gke.1023000, dan cluster yang menjalankan 1.32 dapat diupgrade ke 1.33.5-gke.1162000. 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

Agar cluster di grup downstream dapat mulai diupgrade, grup upstream harus berhasil memenuhi syarat satu target upgrade umum yang memenuhi syarat untuk semua cluster di grup downstream. Jika grup upstream memiliki cluster yang berhasil diupgrade ke dua versi berbeda (seperti yang dapat terjadi saat grup upstream adalah grup pertama dalam urutan), maka grup upstream memenuhi syarat versi yang lebih rendah dari kedua versi tersebut sebagai target upgrade umum untuk grup downstream. Misalnya, jika grup upstream memiliki beberapa cluster yang diupgrade ke 1.31.13-gke.1023000 dan cluster lainnya diupgrade ke 1.33.5-gke.1162000, maka grup tersebut memenuhi syarat 1.31.13-gke.1023000 sebagai target upgrade umum untuk grup downstream.

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. Perilaku ini tidak mencegah urutan peluncuran berlanjut, selama setidaknya satu cluster di grup downstream memenuhi syarat untuk target upgrade.

Misalnya, jika grup upstream memenuhi syarat upgrade ke 1.32, dan grup downstream memiliki cluster yang menjalankan 1.31 dan 1.33, GKE akan mengupgrade cluster yang menjalankan 1.31 ke 1.32, dan mengabaikan cluster yang menjalankan 1.33.

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.31.13-gke.1023000, tetapi cluster dalam grup kedua menjalankan versi yang lebih baru, seperti 1.32.9-gke.1108000, cluster grup kedua tidak akan diupgrade secara otomatis. Grup pertama memenuhi syarat 1.31.13-gke.1023000, tetapi cluster dalam grup kedua (saat ini 1.32) hanya memenuhi syarat untuk target upgrade 1.33.5-gke.1162000, sehingga GKE tidak dapat mengupgrade cluster ini secara otomatis. 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 control plane 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 penyesuaian. Untuk mengetahui informasi selengkapnya, lihat baris untuk FORCED_SOAKING di Tabel informasi status untuk urutan peluncuran.

Cara kerja pengurutan peluncuran berbasis fleet 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 berbasis fleet 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 mengetahui informasi selengkapnya, lihat Menunda penyelesaian peluncuran versi grup.

Cara kerja pengurutan peluncuran berbasis fleet 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 mengetahui informasi selengkapnya, lihat 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 mengetahui 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. Perilaku 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.

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.31.12-gke.1265000, grup pertama dalam urutan dapat secara serentak meluncurkan 1.31.13-gke.1008000.

Pertimbangan saat memilih urutan peluncuran berbasis fleet

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, strategi 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.
  • Anda sering melakukan upgrade manual yang menyebabkan cluster dalam satu grup memiliki versi target upgrade otomatis yang berbeda.

Batasan urutan peluncuran berbasis fleet

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.
  • 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-cluster dalam organisasi yang sama. Anda tidak dapat membuat urutan dengan cluster di beberapa organisasi.

Masalah umum pada pengurutan peluncuran berbasis fleet

  • Jika grup berisi cluster dari lokasi yang berbeda, upgrade cluster mungkin hanya tersedia untuk sementara beberapa cluster karena peluncuran versi baru secara bertahap. Perilaku 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.

Langkah berikutnya