Tentang urutan peluncuran dengan tahap kustom

Autopilot Standard

Rollout sequencing with custom stages

• Urutan Peluncuran dengan tahapan kustom (Pratinjau)
• Pengurutan Peluncuran (GA)

Pratinjau

Fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum dari Persyaratan Khusus Layanan. Fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap 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 yang tersedia secara umum dari urutan peluncuran yang menggunakan model yang lebih linear tanpa tahap kustom.

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

• Upgrade cluster
• Ringkasan pengelolaan fleet
• Saluran rilis
• Skema pembuatan versi di GKE
• Pengujian soak

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 tersedia secara umum dan 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 pengembangan model berbasis fleet, yang menawarkan kontrol dan fleksibilitas yang lebih terperinci. Dengan tahap kustom, Anda dapat menentukan tahap tertentu dalam kumpulan perangkat 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.

Bagian selanjutnya dari dokumen ini hanya berkaitan dengan pengurutan peluncuran dengan tahap kustom.

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:

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.

Konsep utama

• Waktu perendaman: periode ini adalah periode tunggu yang dapat dikonfigurasi yang terjadi setelah semua cluster dalam tahap diupgrade. Waktu tunggu ini memungkinkan Anda memvalidasi versi baru di satu lingkungan dan menemukan potensi masalah sebelum upgrade dilanjutkan ke lingkungan berikutnya. Anda dapat mengonfigurasi waktu perendaman hingga 30 hari untuk setiap tahap dalam urutan. Waktu perendaman yang lebih lama di tahap praproduksi memberi Anda lebih banyak waktu untuk validasi.
• RolloutSequence: ini adalah resource utama yang Anda gunakan untuk menentukan urutan upgrade. RolloutSequence berisi serangkaian tahap yang berurutan, yang memverifikasi bahwa cluster di tahap sebelumnya telah diupgrade sepenuhnya dan telah menyelesaikan periode rendamnya sebelum upgrade dilanjutkan ke tahap berikutnya.
• Rollout: objek ini memungkinkan Anda mengamati progres upgrade satu versi melalui urutan Anda. Anda dapat menggunakan Rollout untuk melihat status peluncuran, melacak progres, dan melihat apakah ada cluster yang tidak memenuhi syarat untuk upgrade dan alasannya.
• Project host khusus: sebaiknya gunakan project Google Cloud khusus untuk menghosting objek RolloutSequence Anda. Menempatkan urutan dalam project khusus memberikan titik kontrol pusat yang netral untuk urutan peluncuran Anda, yang merupakan praktik terbaik serupa untuk mengelola pipeline CI/CD.

Praktik terbaik:

Buat dan kelola resource RolloutSequence Anda di project host khusus.

• Tahap: tahap adalah langkah dalam urutan peluncuran. Setiap tahap berisi sekelompok cluster yang diupgrade bersama-sama.
• Fleet: fleet adalah cara utama untuk mengelompokkan cluster. Tahap dalam urutan peluncuran hanya dapat mereferensikan satu fleet.
• Pemilih label: urutan peluncuran terdiri dari satu atau beberapa tahap. Setiap tahap berisi cluster dari satu fleet, dan Anda dapat menggunakan pemilih label pada cluster untuk membagi fleet lebih lanjut ke dalam beberapa tahap. Pendekatan ini memungkinkan strategi seperti peluncuran bertahap, di mana subset kecil cluster produksi diupgrade terlebih dahulu.

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 .

Peringatan: GKE mungkin tidak dapat melanjutkan upgrade otomatis dalam urutan peluncuran jika ada perbedaan versi antar-cluster di seluruh grup dalam urutan. Untuk mengetahui informasi selengkapnya, lihat Kelayakan Peluncuran.

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:

• Anda dapat mengubah waktu berdiam default untuk grup dalam urutan peluncuran, yang berguna jika pengujian mengungkapkan bahwa versi tertentu memerlukan lebih banyak atau lebih sedikit perendaman. Perubahan pada waktu perendaman ini memperbarui waktu perendaman default untuk semua peluncuran saat ini dan mendatang (ke versi apa pun) yang dibuat setelah modifikasi.

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

Perhatian: Jika Anda mengubah urutan selama peluncuran, khususnya perubahan yang memengaruhi cluster yang berpartisipasi, GKE akan segera membatalkan semua peluncuran yang ada. Jika Anda hanya mengubah waktu perendaman urutan, GKE tidak akan membatalkan peluncuran.

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

Administrator platform di bank komunitas mengelola tiga lingkungan deployment utama: Pengujian, Tahapan, dan Produksi. Cluster Produksi didistribusikan di beberapa region, dengan berbagai tingkat kritikalitas. Untuk mengelola upgrade secara efektif, administrator mengelompokkan cluster di setiap lingkungan ke dalam fleet. Sebagaimana diperlukan untuk pengurutan peluncuran, setiap cluster di ketiga fleet terdaftar di saluran rilis yang sama—dalam hal ini, saluran Reguler—dan semua cluster menjalankan versi minor yang sama.

Tujuan utama administrator adalah memastikan bahwa versi GKE baru diperiksa secara menyeluruh sebelum mencapai lingkungan produksi penting bank. Mereka juga ingin meng-upgrade cluster secara bertahap di region dengan traffic yang lebih rendah terlebih dahulu, lalu berpindah ke region dengan traffic yang lebih tinggi, dan terakhir ke region yang paling penting. Untuk mencapainya, mereka menggunakan urutan peluncuran dengan tahap kustom untuk menentukan strategi upgrade progresif yang mencakup pemberian label pada cluster produksi sesuai dengan wilayahnya. Dengan pendekatan ini, mereka dapat memvalidasi versi baru pada sebagian kecil traffic produksi sebelum peluncuran penuh.

Untuk menerapkan rencana ini, administrator menerapkan label berikut ke cluster di fleet Produksi:

• Cluster di us-west1 (traffic lebih rendah) diberi label prod-region: us-west1.
• Cluster di europe-west1 (traffic lebih tinggi) diberi label prod-region: europe-west1.
• Cluster di us-east1 (traffic paling penting) tidak diberi label. Tahap akhir untuk fleet dalam urutan harus bertindak sebagai 'catch-all' untuk semua cluster yang tersisa. Oleh karena itu, administrator tidak perlu menambahkan label ke cluster yang tersisa ini.

Selanjutnya, di project host khusus yang digunakan untuk mengelola konfigurasi CI/CD, mereka menentukan objek RolloutSequence. Urutan baru ini memiliki lima tahap yang berbeda:

1. Pengujian: tahap ini mencakup semua cluster dalam fleet testing. Administrator menetapkan waktu rendam selama tiga hari untuk memungkinkan validasi menyeluruh.
2. Penyiapan: tahap ini mencakup semua cluster dalam armada staging, dengan waktu perendaman selama tiga hari.
3. Produksi di region us-west1: tahap ini menargetkan fleet produksi, tetapi menggunakan label-selector untuk menyertakan hanya cluster dengan label prod-region: us-west1. Tahap ini memungkinkan administrator memantau masalah pada subset kecil cluster produksi dengan waktu perendaman selama tiga hari.
4. Produksi di region europe-west1: tahap ini mencakup cluster di fleet production yang memiliki label prod-region: europe-west1. Administrator menetapkan waktu rendam empat hari yang lebih lama untuk validasi yang lebih menyeluruh.
5. Produksi di region us-east1: tahap akhir ini mencakup cluster yang tersisa di fleet production; yaitu, semua cluster di us-east1.

Pendekatan ini memberi administrator kontrol terperinci atas upgrade produksi mereka, sehingga meningkatkan keamanan dan keandalan proses upgrade secara signifikan dengan mendeteksi potensi masalah sebelum dapat memengaruhi seluruh lingkungan produksi.

Selama upgrade patch rutin, pengujian otomatis bank berhasil diselesaikan di lingkungan staging jauh lebih cepat dari yang diperkirakan. Administrator mengamati bahwa versi baru stabil dan memutuskan bahwa waktu rendam tiga hari setelah upgrade fleet Staging tidak perlu terlalu lama untuk jenis update rutin ini.

Untuk mempercepat peluncuran ini, administrator mengubah RolloutSequence definisi dan mengurangi durasi pengujian untuk tahap us-west1 Armada produksi. Karena perubahan pada definisi RolloutSequence ini memperbarui waktu tunggu default untuk semua peluncuran saat ini dan mendatang, administrator membuat catatan untuk mengembalikan waktu tunggu ke periode tiga hari semula setelah peluncuran patch khusus ini selesai. Pendekatan ini membantu memastikan waktu perendaman standar yang lebih hati-hati diterapkan untuk upgrade versi minor di masa mendatang.

Administrator menggunakan masa pemeliharaan dan pengecualian sehingga GKE mengupgrade cluster saat tidak mengganggu bank. GKE mempertimbangkan ketersediaan pemeliharaan untuk cluster yang diupgrade dalam urutan peluncuran.

• Administrator 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 lonjakan dan blue-green untuk node, yang menyeimbangkan antara kecepatan dan toleransi risiko, tergantung pada beban kerja yang berjalan pada node tersebut.

Kelayakan peluncuran

Agar versi dapat diluncurkan melalui urutan menggunakan tahap kustom, cluster harus memenuhi syarat untuk target upgrade dari saluran rilisnya. Saat versi GKE baru tersedia, sistem akan membuat objek Rollout jika cluster dalam urutan memenuhi syarat untuk versi baru. Meskipun kami merekomendasikan agar semua cluster terdaftar di saluran rilis yang sama, jika tidak, GKE akan memilih versi dari saluran yang paling konservatif dalam urutan tersebut. Misalnya, jika cluster dicampur antara saluran Stabil dan Reguler, GKE akan memilih versi dari saluran Stabil.

Rollout kemudian berlanjut melalui tahapan yang ditentukan dalam RolloutSequence. Dalam tahap tertentu, peluncuran bidang kontrol dan peluncuran node pool dapat berjalan secara paralel. Aturan utama yang mengatur progres ini adalah bahwa saat tahap berada dalam status SOAKING dengan versi tertentu, tahap tersebut tidak memenuhi syarat untuk memulai Rollout baru untuk versi yang lebih baru. Praktik ini membantu memastikan bahwa suatu versi divalidasi sepenuhnya sebelum upgrade berikutnya dimulai. Anda dapat mengamati progres dan kelayakan setiap cluster dengan memantau objek Peluncuran. Jika menemukan perbedaan versi yang membuat cluster tidak memenuhi syarat, Anda mungkin perlu mengambil tindakan, seperti mengupgrade cluster secara manual, agar urutan dapat dilanjutkan. Jika cluster tidak memenuhi syarat untuk peluncuran apa pun, GKE tidak akan mengupgrade cluster secara otomatis hingga versi saat ini mencapai akhir dukungan.

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

Jika tahap dalam urutan berisi cluster yang menjalankan versi yang lebih baru daripada versi target peluncuran, GKE akan mengupgrade cluster yang memenuhi syarat untuk versi target dan mengabaikan cluster yang sudah menggunakan versi yang lebih baru. Perilaku ini tidak mencegah urutan peluncuran berlanjut ke tahap berikutnya.

Misalnya, jika versi target peluncuran untuk tahap adalah 1.32, dan tahap tersebut memiliki cluster yang menjalankan 1.31 dan 1.33, GKE akan mengupgrade cluster pada versi 1.31 ke 1.32, dan mengabaikan cluster yang sudah menggunakan versi 1.33.

Tahap sebelumnya memenuhi syarat beberapa target upgrade untuk tahap berikutnya

Tahap sebelumnya dalam urutan dapat menyelesaikan peluncuran untuk beberapa versi baru sementara tahap berikutnya dijeda (misalnya, oleh pengecualian pemeliharaan) atau masih memproses upgrade sebelumnya. Dalam hal ini, saat tahap berikutnya siap menerima upgrade baru, GKE akan mengupgrade tahap tersebut ke versi terbaru yang memenuhi syarat. Untuk upgrade bidang kontrol, versi ini paling banyak satu versi minor lebih baru daripada versi bidang kontrol cluster pada tahap berikutnya. Untuk upgrade node, versi ini dapat sama dengan, tetapi tidak lebih baru dari, versi bidang kontrol cluster pada tahap berikutnya.

Misalnya, skenario ini relevan jika Anda mengonfigurasi pengecualian pemeliharaan untuk mencegah upgrade sementara pada cluster produksi. Jika cluster praproduksi Anda tidak memiliki pengecualian pemeliharaan yang sama, cluster ini mungkin diupgrade beberapa kali, sehingga memenuhi syarat beberapa versi baru, tetapi tahap produksi Anda tidak diupgrade.

Perendaman paksa setelah 30 hari

Untuk membantu 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 perendaman.

Cara kerja pengurutan peluncuran dengan fitur upgrade lainnya

Pengurutan peluncuran bekerja bersama dengan fitur upgrade GKE lainnya:

• Masa dan pengecualian pemeliharaan: Anda tetap dapat menggunakan masa dan pengecualian pemeliharaan untuk mengontrol kapan upgrade dapat dan tidak dapat dilakukan di cluster Anda. GKE memulai upgrade cluster hanya 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, situasi ini dapat mencegah penyelesaian upgrade cluster dalam sebuah tahap. Jika upgrade cluster tidak dapat diselesaikan dalam waktu 30 hari karena masa pemeliharaan atau pengecualian, tahap akan memasuki fase rendam terlepas dari apakah semua cluster telah selesai diupgrade. Peluncuran bidang kontrol dan node pool dapat berjalan secara paralel dalam tahap tertentu.

• Strategi upgrade node: pengurutan peluncuran tidak memengaruhi strategi upgrade node yang dikonfigurasi (misalnya, upgrade blue-green). Mirip dengan upgrade cluster yang tidak memiliki urutan peluncuran, GKE menggunakan upgrade lonjakan 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. 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. Situasi ini juga dapat diperburuk oleh masa pemeliharaan yang tidak cukup besar untuk menyelesaikan upgrade node.

• Saluran rilis: sebaiknya daftarkan semua cluster dalam urutan peluncuran di saluran rilis yang sama.

• Deteksi penggunaan fitur yang tidak digunakan lagi: Deteksi penggunaan fitur yang tidak digunakan lagi oleh GKE masih berfungsi seperti yang diharapkan, sehingga berpotensi menjeda upgrade pada cluster yang menggunakan API yang tidak digunakan lagi.

• Upgrade manual: mengupgrade cluster secara manual pada tahap pertama urutan tidak dengan sendirinya memenuhi syarat versi tersebut atau memicu peluncuran untuk dilanjutkan. Proses peluncuran otomatis didorong oleh target upgrade otomatis resmi yang ditetapkan untuk saluran rilis. Upgrade manual mengupdate cluster, tetapi urutan mulai berlanjut untuk versi tersebut hanya setelah menjadi target upgrade otomatis yang ditetapkan.

Menerima beberapa upgrade dalam satu urutan

Saluran rilis memilih target upgrade untuk cluster. Jika versi baru tersedia saat upgrade ke target sebelumnya masih berlangsung, tahap pertama dapat memulai peluncuran versi baru meskipun tahap selanjutnya masih menerima upgrade sebelumnya. Misalnya, jika grup ketiga dalam suatu urutan meluncurkan versi 1.31.12-gke.1265000, grup pertama dalam urutan dapat secara serentak meluncurkan versi 1.31.13-gke.1008000.

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

Batasan

Batasan berikut berlaku saat Anda mengupgrade cluster dengan menggunakan urutan peluncuran dengan tahap kustom:

• Anda tidak dapat menggunakan konsol Google Cloud untuk membuat atau melihat urutan peluncuran dengan tahapan kustom.
• Saat urutan peluncuran mereferensikan armada, Anda harus menyertakan seluruh armada . Batasan ini berarti bahwa jika Anda menentukan tahapan untuk menargetkan hanya subset cluster dari armada dengan label-selector (misalnya, untuk deployment bertahap), Anda juga harus menentukan tahapan "catch-all" berikutnya yang mencakup semua cluster yang tersisa dari armada yang sama. Tahap umum ini menargetkan fleet yang sama, tetapi tidak menyertakan label-selector, sehingga secara otomatis menyertakan semua cluster yang tidak dipilih oleh tahap sebelumnya dalam urutan.
• Jika Anda mengubah urutan selama peluncuran, khususnya perubahan yang memengaruhi cluster yang berpartisipasi, GKE akan segera membatalkan semua peluncuran yang ada. Jika Anda hanya mengubah waktu perendaman urutan, GKE tidak akan membatalkan peluncuran.
• Anda tidak dapat mempercepat peluncuran aktif untuk versi tertentu secara manual. Saat Anda mengubah durasi perendaman dalam definisi urutan peluncuran, perubahan akan memperbarui waktu perendaman default untuk semua peluncuran saat ini dan mendatang yang dibuat setelah perubahan.
• GKE secara otomatis mengupgrade cluster yang telah mencapai akhir dukungan ke versi yang didukung, dan upgrade ini mungkin tidak mengikuti urutan peluncuran yang ditentukan.
• Tahap dapat mereferensikan maksimal satu armada. Anda tidak dapat memiliki beberapa kumpulan armada dalam satu tahap.
• Satu fleet hanya dapat direferensikan dalam satu urutan peluncuran. Dua urutan peluncuran tidak dapat mereferensikan armada yang sama.

Masalah umum

Bagian ini menguraikan masalah umum untuk pengurutan peluncuran dengan tahap kustom.

• Jika tahap dalam urutan peluncuran tidak berisi cluster, tahap tersebut akan dilewati, tetapi waktu penyesuaian yang ditentukan untuk tahap tersebut tetap berlalu sebelum peluncuran dilanjutkan ke tahap berikutnya.

Langkah berikutnya

• Mengurutkan peluncuran upgrade cluster dengan tahap kustom