Siklus proses dan tahap upgrade cluster

Saat Anda mengupgrade Google Distributed Cloud, proses upgrade melibatkan beberapa langkah dan komponen. Untuk membantu memantau status upgrade atau mendiagnosis dan memecahkan masalah, sebaiknya ketahui apa yang terjadi saat Anda menjalankan perintah bmctl upgrade cluster. Dokumen ini menjelaskan secara detail komponen dan tahapan upgrade cluster.

Ringkasan

Proses upgrade akan memindahkan cluster Google Distributed Cloud Anda dari versi saat ini ke versi yang lebih tinggi.

Informasi versi ini disimpan di lokasi berikut sebagai bagian dari resource kustom cluster di cluster admin:

  • status.anthosBareMetalVersion: menentukan versi cluster saat ini.

  • spec.anthosBareMetalVersion: menentukan versi target, dan ditetapkan saat proses upgrade mulai berjalan.

Operasi upgrade yang berhasil akan merekonsiliasi status.anthosBareMetalVersion ke spec.anthosBareMetalVersion sehingga keduanya menampilkan versi target.

Kemiringan versi cluster

Kemiringan versi cluster adalah perbedaan versi antara cluster pengelolaan (hibrida atau admin) dan cluster pengguna terkelolanya. Saat Anda menambahkan atau mengupgrade cluster pengguna, aturan versi berikut akan berlaku:

1,29

Aturan berikut berlaku untuk cluster pengguna yang dikelola oleh cluster admin atau cluster hybrid versi 1.29:

  • Versi cluster pengguna tidak boleh lebih tinggi dari versi cluster pengelola (admin atau hybrid).

  • (1.29 Pratinjau) Cluster pengguna dapat memiliki maksimal dua versi minor di bawah versi cluster yang mengelola. Misalnya, cluster admin versi 1.29 dapat mengelola cluster pengguna 1.16. Pengelolaan kemiringan versi n-2 ini tersedia sebagai kemampuan Pratinjau untuk mengelola cluster pada versi 1.29.

  • (1.29 Pratinjau) Untuk cluster pengelola tertentu, cluster pengguna tidak perlu memiliki versi minor yang sama satu sama lain. Misalnya, cluster admin versi 1.29 dapat mengelola cluster pengguna versi 1.29, versi 1.28, dan versi 1.16. Pengelolaan kemiringan versi campuran ini tersedia sebagai kemampuan Pratinjau untuk mengelola cluster pada versi 1.29.

    Kemampuan pengelolaan multi-skew Pratinjau memberi Anda lebih banyak fleksibilitas untuk merencanakan upgrade perangkat. Misalnya, Anda tidak harus mengupgrade semua cluster pengguna versi 1.16 ke versi 1.28 sebelum dapat mengupgrade cluster admin ke versi 1.29.

1.28 dan yang lebih lama

Aturan berikut berlaku untuk cluster pengguna yang dikelola oleh cluster admin atau cluster hybrid versi 1.28 atau sebelumnya:

  • Versi cluster pengguna tidak boleh lebih tinggi dari versi cluster pengelola (admin atau hybrid).

  • Cluster pengguna dapat memiliki satu versi minor di bawah versi cluster yang mengelola. Misalnya, cluster admin versi 1.28 tidak dapat mengelola cluster pengguna di versi 1.15.

  • Untuk cluster pengelola tertentu, semua cluster pengguna terkelola harus menggunakan versi minor yang sama.

Untuk mengetahui informasi tentang aturan kemiringan versi untuk kumpulan node, lihat Aturan pembuatan versi kumpulan node.

Aturan versi

Saat mendownload dan menginstal versi baru bmctl, Anda dapat mengupgrade cluster pengguna, campuran, mandiri, dan admin Anda yang dibuat atau diupgrade dengan versi bmctl yang lebih lama. Cluster tidak dapat didowngrade ke versi yang lebih rendah.

Anda hanya dapat mengupgrade cluster ke versi yang cocok dengan versi bmctl yang Anda gunakan. Artinya, jika Anda menggunakan bmctl versi 1.29.200-gke.243, Anda dapat mengupgrade cluster ke versi 1.29.200-gke.243 saja.

Upgrade versi patch

Untuk versi minor tertentu, Anda dapat mengupgrade ke versi patch yang lebih tinggi. Artinya, Anda dapat mengupgrade cluster versi 1.29.X ke versi 1.29.Y selama Y lebih tinggi dari X. Misalnya, Anda dapat mengupgrade dari 1.28.0 ke 1.28.100 dan dapat mengupgrade dari 1.28.100 ke 1.28.300. Sebaiknya Anda mengupgrade ke versi patch terbaru jika memungkinkan untuk memastikan cluster Anda memiliki perbaikan keamanan terbaru.

Upgrade versi minor

Anda dapat mengupgrade cluster dari satu versi minor ke versi berikutnya, terlepas dari versi patch-nya. Artinya, Anda dapat melakukan upgrade dari 1.N.X ke 1.N+1.Y, dengan 1.N.X adalah versi cluster Anda dan N+1 adalah versi minor yang tersedia berikutnya. Dalam kasus ini, versi patch, X dan Y, tidak memengaruhi logika upgrade. Misalnya, Anda dapat mengupgrade dari 1.28.700-gke.150 ke 1.29.200-gke.243.

Anda tidak dapat melewati versi minor saat mengupgrade cluster. Jika Anda mencoba mengupgrade ke versi minor yang merupakan dua atau lebih versi minor yang lebih tinggi dari versi cluster, bmctl akan menampilkan error. Misalnya, Anda tidak dapat mengupgrade cluster 1.16.0 versi ke versi 1.29.0.

Cluster admin dapat mengelola cluster pengguna yang berada pada versi minor yang sama atau sebelumnya. Cluster pengguna terkelola tidak boleh memiliki lebih dari satu versi minor yang lebih rendah dari cluster admin, jadi sebelum mengupgrade cluster admin ke versi minor baru, pastikan semua cluster pengguna terkelola memiliki versi minor yang sama dengan cluster admin.

Aturan pembuatan versi kumpulan node

Saat Anda mengupgrade kumpulan node secara selektif, aturan versi berikut akan berlaku:

1,29

  • Versi cluster harus lebih besar dari atau sama dengan versi kumpulan node pekerja.

  • (1,29 GA) Kemiringan versi maksimum antara kumpulan node pekerja dan cluster adalah dua versi minor.

  • Kumpulan node pekerja tidak boleh dalam versi yang dirilis secara kronologis yang lebih lama dari versi cluster. Rilis sebelumnya tidak memiliki detail komprehensif untuk rilis berikutnya, yang merupakan persyaratan kompatibilitas.

    Misalnya, versi 1.16.6 yang dirilis setelah versi 1.28.100-gke.146 dirilis, sehingga Anda tidak dapat mengupgrade cluster dari versi 1.16.6 ke versi 1.28.100-gke.146 dan meninggalkan kumpulan node pekerja pada versi 1.16.6. Demikian pula, jika Anda mengupgrade cluster ke versi 1.28.100-gke.146, tetapi memilih untuk membiarkan kumpulan node pekerja di versi 1.16.5, Anda tidak dapat mengupgrade kumpulan node pekerja ke versi 1.16.6 saat cluster berada di versi 1.28.100-gke.146.

1,28

  • Versi cluster harus lebih besar dari atau sama dengan versi kumpulan node pekerja.

  • (1.28 Pratinjau) Versi maksimum kemiringan antara kumpulan node pekerja dan cluster adalah dua versi minor saat fitur Pratinjau kemiringan versi n-2 diaktifkan. Jika Anda tidak mengaktifkan kemampuan ini, distorsi versi maksimum antara kumpulan node pekerja dan cluster adalah satu versi minor.

  • Kumpulan node pekerja tidak boleh dalam versi yang dirilis secara kronologis yang lebih lama dari versi cluster. Rilis sebelumnya tidak memiliki detail komprehensif untuk rilis berikutnya, yang merupakan persyaratan kompatibilitas.

    Misalnya, versi 1.16.6 yang dirilis setelah versi 1.28.100-gke.146 dirilis, sehingga Anda tidak dapat mengupgrade cluster dari versi 1.16.6 ke versi 1.28.100-gke.146 dan meninggalkan kumpulan node pekerja pada versi 1.16.6. Demikian pula, jika Anda mengupgrade cluster ke versi 1.28.100-gke.146, tetapi memilih untuk membiarkan kumpulan node pekerja di versi 1.16.5, Anda tidak dapat mengupgrade kumpulan node pekerja ke versi 1.16.6 saat cluster berada di versi 1.28.100-gke.146.

1.16

  • Versi cluster harus lebih besar dari atau sama dengan versi kumpulan node pekerja.

  • Kemiringan versi maksimum antara kumpulan node pekerja dan cluster adalah satu versi minor.

  • Kumpulan node pekerja tidak boleh dalam versi yang dirilis secara kronologis yang lebih lama dari versi cluster. Rilis sebelumnya tidak memiliki detail komprehensif untuk rilis berikutnya, yang merupakan persyaratan kompatibilitas.

    Misalnya, versi 1.16.6 yang dirilis setelah versi 1.28.100-gke.146 dirilis, sehingga Anda tidak dapat mengupgrade cluster dari versi 1.16.6 ke versi 1.28.100-gke.146 dan meninggalkan kumpulan node pekerja pada versi 1.16.6. Demikian pula, jika Anda mengupgrade cluster ke versi 1.28.100-gke.146, tetapi memilih untuk membiarkan kumpulan node pekerja di versi 1.16.5, Anda tidak dapat mengupgrade kumpulan node pekerja ke versi 1.16.6 saat cluster berada di versi 1.28.100-gke.146.

Tabel berikut berisi versi kumpulan node yang didukung yang diizinkan untuk versi cluster tertentu:

1,29

Versi cluster (bidang kontrol) Versi node pool pekerja yang didukung
1.29.200-gke.243
  • 1.29.200-gke.243
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
1.29.100-gke.251
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.400-gke.77
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
1.29.0-gke.1449
  • 1.29.0-gke.1449
  • 1.28.300-gke.136
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.435
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0

1,28

Versi cluster (bidang kontrol) Versi node pool pekerja yang didukung
1.28.700-gke.150
  • 1.28.700-gke.150
  • 1.28.600-gke.163
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.600-gke.163
  • 1.28.600-gke.163
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.500-gke.120
  • 1.28.500-gke.120
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.400-gke.77
  • 1.28.400-gke.77
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.300-gke.131
  • 1.28.300-gke.131
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.200-gke.118
  • 1.28.200-gke.118
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.100-gke.146
  • 1.28.100-gke.146
  • 1.28.0-gke.425
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.28.0-gke.425
  • 1.28.0-gke.425
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

     

     

     

1.16

Versi cluster (bidang kontrol) Versi node pool pekerja yang didukung
1.16.10
  • 1.16.10
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.9
  • 1.16.9
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.8
  • 1.16.8
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.7
  • 1.16.7
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.6
  • 1.16.6
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.9
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.5
  • 1.16.5
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.8
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.4
  • 1.16.4
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.7
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.3
  • 1.16.3
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.6
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.2
  • 1.16.2
  • 1.16.1
  • 1.16.0
  • 1.15.5
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.1
  • 1.16.1
  • 1.16.0
  • 1.15.4
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0
1.16.0
  • 1.16.0
  • 1.15.3
  • 1.15.2
  • 1.15.1
  • 1.15.0

Mengupgrade komponen

Komponen diupgrade di tingkat node dan cluster. Di tingkat cluster, komponen berikut diupgrade:

  • Komponen cluster untuk jaringan, kemampuan observasi, dan penyimpanan.
  • Untuk cluster admin, hybrid, dan mandiri, pengontrol siklus proses.
  • gke-connect-agent.

Node dalam cluster dijalankan sebagai salah satu peran berikut, dengan berbagai komponen yang diupgrade, bergantung pada peran node:

Peran node Fungsi Komponen yang akan diupgrade
Pekerja Menjalankan workload pengguna Kubelet, runtime container (Docker atau containerd)
Bidang kontrol Menjalankan bidang kontrol Kubernetes, pengontrol siklus proses cluster, dan add-on platform edisi Google Kubernetes Engine (GKE) Enterprise Pod statis bidang kontrol Kubernetes (kubeapi-server, kube-scheduler, kube-controller-manager, dlld)

Pengontrol siklus proses seperti lifecycle-controllers-manager dan anthos-cluster-operator

Add-on platform edisi Google Kubernetes Engine (GKE) Enterprise seperti stackdriver-log-aggregator dan gke-connect-agent
Load balancer bidang kontrol Menjalankan HAProxy dan Keepahidup yang menyalurkan traffic ke kube-apiserver, dan menjalankan speaker MetalLB untuk mengklaim alamat IP virtual Mengontrol Pod statis load balancer bidang (HAProxy, Keepahidup)

Speaker MetalLB

Ekspektasi Periode nonaktif

Tabel berikut menjelaskan periode nonaktif yang diperkirakan dan potensi dampak saat Anda mengupgrade cluster. Tabel ini mengasumsikan bahwa Anda memiliki beberapa node cluster dan satu bidang kontrol HA. Jika Anda menjalankan cluster mandiri atau tidak memiliki bidang kontrol HA, periode nonaktif tambahan akan terjadi. Kecuali dinyatakan lain, periode nonaktif ini berlaku untuk upgrade cluster admin dan pengguna:

Komponen Ekspektasi periode nonaktif Saat periode nonaktif terjadi
Server API bidang kontrol Kubernetes (kube-apiserver), dlld, dan penjadwal Tanpa periode nonaktif T/A
Pengontrol siklus proses dan tugas ansible-runner (khusus cluster admin) Tanpa periode nonaktif T/A
Bidang kontrol Kubernetes loadbalancer-haproxy dan keepalived Periode nonaktif sementara (kurang dari 1 hingga 2 menit) saat load balancer mengalihkan traffic. Awal proses upgrade.
Kemampuan observasi pipeline-stackdriver dan metrics-server Operator habis dan diupgrade. Periode nonaktif seharusnya kurang dari 5 menit.

DaemonSets akan terus berfungsi tanpa periode nonaktif.		 Setelah node bidang kontrol menyelesaikan upgrade.
Antarmuka jaringan container (CNI) Tanpa periode nonaktif untuk rute jaringan yang ada.

DaemonSet di-deploy dua kali dua tanpa periode nonaktif.

Operator habis dan diupgrade. Periode nonaktif kurang dari 5 menit.		 Setelah node bidang kontrol menyelesaikan upgrade.
MetalLB (khusus cluster pengguna) Operator habis dan diupgrade. Periode nonaktif kurang dari 5 menit.

Tidak ada periode nonaktif untuk layanan yang ada		 Setelah node bidang kontrol menyelesaikan upgrade.
CoreDNS dan autoscaler DNS (khusus cluster pengguna) CoreDNS memiliki beberapa replika dengan autoscaler. Biasanya tidak ada periode nonaktif. Setelah node bidang kontrol menyelesaikan upgrade.
Penyedia volume lokal Tidak ada periode nonaktif untuk volume persisten (PV) yang disediakan yang ada.

Operator mungkin memiliki periode nonaktif selama 5 menit.		 Setelah node bidang kontrol menyelesaikan upgrade.
Istio / traffic masuk Operator Istio akan dihentikan dan diupgrade. Periode nonaktif sekitar 5 menit.

Traffic masuk yang telah dikonfigurasi saat ini akan terus berfungsi.		 Setelah node bidang kontrol menyelesaikan upgrade.
Operator sistem lainnya Periode nonaktif 5 menit saat habis dan diupgrade. Setelah node bidang kontrol menyelesaikan upgrade.
Workload pengguna Bergantung pada penyiapan, seperti jika sangat tersedia.

Tinjau deployment workload Anda sendiri untuk memahami potensi dampaknya.		 Saat node pekerja diupgrade.

Detail upgrade cluster pengguna

Bagian ini menjelaskan urutan upgrade komponen dan informasi status untuk upgrade cluster pengguna. Bagian berikut menjelaskan penyimpangan dari alur ini untuk upgrade cluster admin, hybrid, atau mandiri.

Diagram berikut menunjukkan proses pemeriksaan preflight untuk upgrade cluster pengguna:

Pemeriksaan preflight cluster menjalankan health check tambahan pada cluster sebelum proses upgrade dimulai.

Diagram sebelumnya menjelaskan langkah-langkah yang terjadi selama upgrade:

  • Perintah bmctl upgrade cluster akan membuat resource kustom PreflightCheck.
  • Pemeriksaan preflight ini menjalankan pemeriksaan tambahan seperti pemeriksaan upgrade cluster, health check jaringan, dan health check node.
  • Hasil pemeriksaan tambahan ini digabungkan untuk melaporkan kemampuan cluster agar berhasil diupgrade ke versi target.

Jika pemeriksaan preflight berhasil dan tidak ada masalah pemblokiran, komponen dalam cluster akan diupgrade dalam urutan tertentu, seperti yang ditunjukkan pada diagram berikut:

Load balancer bidang kontrol dan kumpulan node bidang kontrol telah diupgrade. Setelah itu, koneksi GKE, add-on cluster, serta kumpulan node load balancer dan kumpulan node pekerja akan diupgrade.

Dalam diagram sebelumnya, komponen diupgrade secara berurutan sebagai berikut:

  1. Upgrade dimulai dengan memperbarui kolom spec.anthosBareMetalVersion.
  2. Load balancer bidang kontrol diupgrade.
  3. Kumpulan node bidang kontrol diupgrade.
  4. Secara paralel, koneksi GKE akan di-upgrade, add-on cluster akan diupgrade, dan kumpulan node load balancer diupgrade.
    1. Setelah kumpulan node load balancer berhasil diupgrade, kumpulan node pekerja akan diupgrade.

  5. Jika semua komponen telah diupgrade, health check cluster akan dijalankan.

    Health check terus berjalan hingga semua pemeriksaan lulus.

  6. Setelah semua health check lulus, upgrade selesai.

Setiap komponen memiliki kolom statusnya sendiri di dalam resource kustom Cluster. Anda dapat memeriksa status di kolom ini untuk memahami progres upgrade:

Urutan Nama kolom Arti
1 status.controlPlaneNodepoolStatus Status disalin dari status kumpulan node bidang kontrol. Kolom ini berisi versi node kumpulan node bidang kontrol
2 status.anthosBareMetalLifecycleControllersManifestsVersion Versi lifecycles-controllers-manager yang diterapkan ke cluster. Kolom ini hanya tersedia untuk cluster admin, mandiri, atau hybrid.
2 status.anthosBareMetalManifestsVersion Versi cluster dari manifes yang terakhir diterapkan.
2 status.controlPlaneLoadBalancerNodepoolStatus Status disalin dari status node pool load balancer bidang kontrol. Kolom ini kosong jika tidak ada load balancer bidang kontrol terpisah yang ditentukan di Cluster.Spec.
3 status.anthosBareMetalVersions Peta versi gabungan dari versi ke nomor node.
4 status.anthosBareMetalVersion Status akhir dari versi yang diupgrade.

Detail upgrade cluster admin, hybrid, dan mandiri

Mulai bmctl versi 1.15.0, perilaku upgrade default untuk cluster terkelola mandiri (admin, hybrid, atau mandiri) adalah upgrade yang siap pakai. Artinya, saat Anda mengupgrade cluster ke versi 1.15.0 atau yang lebih baru, upgrade akan menggunakan pengontrol siklus proses, bukan cluster bootstrap, untuk mengelola seluruh proses upgrade. Perubahan ini menyederhanakan proses dan mengurangi persyaratan resource, sehingga upgrade cluster menjadi lebih andal dan skalabel.

Meskipun penggunaan cluster bootstrap untuk upgrade tidak direkomendasikan, opsi ini masih tersedia. Untuk menggunakan cluster bootstrap saat melakukan upgrade, jalankan perintah bmctl upgrade dengan flag --use-bootstrap=true. Tahapan upgrade berbeda-beda, bergantung pada metode yang Anda gunakan.

Upgrade di tempat

Proses upgrade default yang sudah siap untuk cluster yang dikelola sendiri mirip dengan proses upgrade cluster pengguna. Namun, saat Anda menggunakan proses upgrade di tempat, versi baru preflightcheck-operator akan di-deploy sebelum pemeriksaan preflight cluster dan health check dijalankan:

Versi baru operator preflightcheck di-deploy sebelum pemeriksaan preflight cluster menjalankan health check tambahan di cluster.

Seperti upgrade cluster pengguna, proses upgrade dimulai dengan memperbarui kolom Cluster.spec.anthosBareMetalVersion ke versi target. Dua langkah tambahan dijalankan sebelum komponen diperbarui, seperti yang ditunjukkan dalam diagram berikut: lifecycle-controller-manager mengupgrade sendiri ke versi target, lalu men-deploy versi target anthos-cluster-operator. anthos-cluster-operator ini akan melakukan langkah-langkah yang tersisa dalam proses upgrade:

Lifecycle-controller-manager dan anthos-cluster-operator di-deploy sebelum cluster lainnya diupgrade dalam urutan yang sama seperti komponen dalam cluster pengguna.

Setelah berhasil, anthos-cluster-operator merekonsiliasi versi target dari spec.anthosBareMetalVersion menjadi status.anthosBareMetalVersion.

Mengupgrade dengan cluster bootstrap

Proses untuk mengupgrade cluster admin, hybrid, atau mandiri mirip dengan cluster pengguna yang dibahas di bagian sebelumnya.

Perbedaan utamanya adalah perintah bmctl upgrade cluster memulai proses untuk membuat cluster bootstrap. Cluster bootstrap ini adalah cluster sementara yang mengelola cluster hybrid, admin, atau mandiri selama upgrade.

Proses untuk mentransfer kepemilikan pengelolaan cluster ke cluster bootstrap disebut pivot. Proses upgrade lainnya mengikuti proses yang sama seperti upgrade cluster pengguna.

Selama proses upgrade, resource di cluster target tetap tidak berlaku. Progres upgrade hanya ditampilkan dalam resource cluster bootstrap.

Jika perlu, Anda dapat mengakses cluster bootstrap untuk membantu memantau dan men-debug proses upgrade. Cluster bootstrap dapat diakses melalui bmctl-workspace/.kindkubeconfig.

Untuk mentransfer kembali kepemilikan pengelolaan cluster setelah upgrade selesai, cluster akan melakukan pivot pada resource dari cluster bootstrap ke cluster yang diupgrade. Tidak ada langkah manual yang Anda lakukan untuk membuat pivot cluster selama proses upgrade. Cluster bootstrap dihapus setelah upgrade cluster berhasil.

Penghentian node

Upgrade cluster Google Distributed Cloud dapat menyebabkan gangguan aplikasi saat node dihentikan. Proses pengosongan ini menyebabkan semua Pod yang berjalan pada node dinonaktifkan dan dimulai ulang pada node yang tersisa dalam cluster.

Deployment dapat digunakan untuk menoleransi gangguan tersebut. Deployment dapat menentukan beberapa replika aplikasi atau layanan yang harus dijalankan. Aplikasi dengan beberapa replika akan mengalami sedikit atau tidak ada gangguan selama upgrade.

PodDisruptionBudgets (PDB)

Saat Anda mengupgrade cluster, Google Distributed Cloud akan menggunakan alur mode pemeliharaan untuk menguras node.

Mulai rilis 1.29, node dikosongkan dengan Eviction API, yang menerima PodDisruptionBudgets (PDB). PDB dapat digunakan untuk memastikan bahwa jumlah replika yang ditentukan selalu berjalan di cluster dalam kondisi berjalan normal. PDB memungkinkan Anda membatasi gangguan pada workload saat Pod-nya perlu dijadwalkan ulang. Penghentian node berbasis penghapusan tersedia sebagai GA untuk rilis 1.29.

Pada rilis 1.28 dan yang lebih lama, Google Distributed Cloud tidak menerima PDB jika node menguras selama upgrade. Sebaliknya, proses pengeringan {i>node<i} adalah upaya terbaik. Beberapa Pod mungkin terjebak dalam status Terminating dan menolak untuk mengosongkan node. Upgrade akan dilanjutkan, bahkan jika Pod macet, saat proses pengurasan pada node memerlukan waktu lebih dari 20 menit.

Untuk mengetahui informasi selengkapnya, lihat Memasukkan node ke dalam mode pemeliharaan.

Langkah selanjutnya