Siklus proses dan tahap upgrade cluster

Saat Anda mengupgrade Google Distributed Cloud, proses upgrade melibatkan beberapa langkah dan komponennya. 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 cluster {i>upgrade.<i}

Ringkasan

Proses upgrade memindahkan cluster Google Distributed Cloud Anda dari 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 disetel saat proses upgrade mulai berjalan.

Operasi upgrade yang berhasil membuat rekonsiliasi status.anthosBareMetalVersion hingga spec.anthosBareMetalVersion sehingga keduanya menunjukkan versi target.

Kemiringan versi cluster

Kemiringan versi cluster adalah perbedaan versi antara cluster (hybrid atau admin) dan cluster pengguna terkelola miliknya. Saat Anda menambahkan atau mengupgrade cluster pengguna, aturan versi berikut akan berlaku:

1,29

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

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

  • (1.29 Pratinjau) Cluster pengguna dapat maksimal dua versi minor di bawah versi cluster pengelola. Sebagai 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 di versi 1.29.

  • (1.29 Pratinjau) Untuk pengelolaan tertentu cluster pengguna tidak perlu memiliki versi minor yang sama lainnya. Misalnya, admin versi 1.29 cluster dapat mengelola pengguna versi 1.29, versi 1.28, dan versi 1.16 klaster. Pengelolaan kemiringan versi campuran ini tersedia sebagai Kemampuan Pratinjau untuk dan mengelola cluster di versi 1.29.

    Pengelolaan multi-skew Pratinjau baru akan memberi Anda lebih banyak fleksibilitas untuk merencanakan upgrade fleet. Sebagai misalnya, Anda tidak harus mengupgrade semua cluster pengguna versi 1.16 ke versi 1.28 agar Anda dapat mengupgrade cluster admin ke versi 1,29.

1.28 dan yang lebih lama

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

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

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

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

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

Aturan versi

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

Anda hanya dapat mengupgrade cluster ke versi yang sesuai dengan versi bmctl yang Anda gunakan. Artinya, jika Anda menggunakan versi 1.29.300--gke.185 dari bmctl, Anda dapat mengupgrade cluster ke versi 1.29.300--gke.185 saja.

Upgrade versi patch

Untuk versi minor tertentu, Anda dapat mengupgrade ke versi patch yang lebih tinggi. Yaitu, Anda dapat mengupgrade 1.29.X cluster versi ke versi 1.29.Y selama Y lebih besar dari X. Misalnya, Anda dapat melakukan upgrade dari 1.28.0 ke 1.28.100 dan Anda dapat mengupgrade dari 1.28.100 untuk 1.28.300. Sebaiknya upgrade 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 patch. Artinya, Anda dapat meningkatkan versi dari 1.N.X hingga 1.N+1.Y, dengan 1.N.X adalah versi cluster Anda dan N+1 adalah cluster berikutnya versi minornya. Versi patch, X dan Y, dalam kasus ini tidak akan memengaruhi logika upgrade. Sebagai misalnya, Anda dapat mengupgrade dari 1.28.700-gke.150 ke 1.29.300--gke.185.

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

Cluster admin dapat mengelola cluster pengguna yang berada di kelompok pengguna di bawah umur 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, memastikan bahwa semua kelompok pengguna terkelola menggunakan versi minor yang sama dengan ke cluster admin.

Aturan pembuatan versi kumpulan node

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

1,29

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

  • (1.29 GA) Kemiringan versi maksimum antara kumpulan node pekerja dan 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 selanjutnya, yang merupakan persyaratan untuk kompatibilitas mundur.

    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 node pekerja pool di versi 1.16.6. Demikian pula, jika Anda mengupgrade cluster ke versi 1.28.100-gke.146, tetapi memilih untuk meninggalkan kumpulan node pekerja di versi 1.16.5, Anda tidak dapat mengupgrade kumpulan node pekerja ke versi 1.16.6 sedangkan cluster yang digunakan adalah versi 1.28.100-gke.146.

1,28

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

  • (1.28 Pratinjau) Versi maksimum kemiringan antara kumpulan node pekerja dan cluster merupakan dua versi minor saat versi n-2 condong Fitur Pratinjau diaktifkan. Jika Anda jangan mengaktifkan kemampuan ini, distorsi versi maksimum antara worker kumpulan node, sedangkan cluster merupakan salah 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 selanjutnya, yang merupakan persyaratan untuk kompatibilitas mundur.

    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 node pekerja pool di versi 1.16.6. Demikian pula, jika Anda mengupgrade cluster ke versi 1.28.100-gke.146, tetapi memilih untuk meninggalkan kumpulan node pekerja di versi 1.16.5, Anda tidak dapat mengupgrade kumpulan node pekerja ke versi 1.16.6 sedangkan cluster yang digunakan adalah versi 1.28.100-gke.146.

1.16

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

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

  • 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 selanjutnya, yang merupakan persyaratan untuk kompatibilitas mundur.

    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 node pekerja pool di versi 1.16.6. Demikian pula, jika Anda mengupgrade cluster ke versi 1.28.100-gke.146, tetapi memilih untuk meninggalkan kumpulan node pekerja di versi 1.16.5, Anda tidak dapat mengupgrade kumpulan node pekerja ke versi 1.16.6 sedangkan cluster yang digunakan adalah versi 1.28.100-gke.146.

Tabel berikut mencantumkan 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.300-gke.185
  • 1.29.300-gke.185
  • 1.29.200-gke.243
  • 1.29.100-gke.251
  • 1.29.0-gke.1449
  • 1.28.700-gke.150
  • 1.28.600-gke.163
  • 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.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.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.11
  • 1.16.11
  • 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.10
  • 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.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 level 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 komponen yang berbeda-beda 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, dll.)

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 Keepalive yang menyalurkan traffic ke kube-apiserver, dan menjalankan speaker MetalLB untuk mengklaim IP virtual alamat 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 HA bidang kontrol. Jika Anda menjalankan cluster mandiri atau tidak memiliki kontrol HA pesawat, akan ada periode nonaktif tambahan. Kecuali dinyatakan lain, periode nonaktif ini berlaku untuk upgrade cluster pengguna dan admin:

Komponen Ekspektasi periode nonaktif Saat periode nonaktif terjadi
Server API bidang kontrol Kubernetes (kube-apiserver), {i>etcd<i}, dan penjadwal Tanpa periode nonaktif T/A
Pengontrol siklus proses dan tugas ansible-runner (admin khusus cluster) 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 lalu lintas data. Awal proses upgrade.
Kemampuan observasi pipeline-stackdriver dan metrics-server Operator habis dan diupgrade. Periode nonaktif seharusnya kurang dari 5 menit.

DaemonSets 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 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. Sekitar 5 menit periode nonaktif.

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 membuat PreflightCheck kustom resource Anda
  • 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 diupgrade dalam urutan tertentu, seperti ditunjukkan dalam 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 mengupdate spec.anthosBareMetalVersion kolom tersebut.
  2. Load balancer bidang kontrol diupgrade.
  3. Kumpulan node bidang kontrol diupgrade.
  4. Secara paralel, GKE Connect diupgrade, add-on cluster node pool load balancer diupgrade.
    1. Setelah kumpulan node load balancer berhasil diupgrade, worker kumpulan node 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 berikut untuk memahami progres upgrade:

Urutan Nama kolom Arti
1 status.controlPlaneNodepoolStatus Status disalin dari status kumpulan node bidang kontrol. Lapangan mencakup versi node kumpulan node bidang kontrol
2 status.anthosBareMetalLifecycleControllersManifestsVersion Versi lifecycles-controllers-manager yang diterapkan ke . Kolom ini hanya tersedia untuk admin, mandiri, atau campuran klaster.
2 status.anthosBareMetalManifestsVersion Versi cluster dari manifes yang terakhir diterapkan.
2 status.controlPlaneLoadBalancerNodepoolStatus Status disalin dari kumpulan node load balancer bidang kontrol . Kolom ini kosong jika tidak ada load balancer bidang kontrol terpisah yang yang ditentukan dalam 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 dari bmctl versi 1.15.0, perilaku upgrade default untuk Cluster yang dikelola sendiri (admin, hybrid, atau mandiri) merupakan upgrade yang siap pakai. Artinya, saat Anda mengupgrade cluster ke versi 1.15.0 atau yang lebih tinggi, upgrade menggunakan pengontrol siklus proses, bukan cluster bootstrap, untuk mengelola seluruh proses upgrade. Perubahan ini menyederhanakan proses dan mengurangi khusus, sehingga upgrade cluster menjadi lebih andal dan skalabel.

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

Upgrade di tempat

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

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 Cluster.spec.anthosBareMetalVersion ke versi target. Dua langkah-langkah tambahan yang dijalankan sebelum komponen diupdate, seperti yang diagram: lifecycle-controller-manager mengupgrade sendiri ke target versi, lalu men-deploy versi target anthos-cluster-operator. Ini anthos-cluster-operator 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 untuk status.anthosBareMetalVersion.

Mengupgrade dengan cluster bootstrap

Proses untuk mengupgrade cluster admin, hybrid, atau mandiri mirip dengan 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 bootstrap cluster 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 tercermin dalam resource 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 cluster upgrade berhasil.

Penghentian node

Upgrade cluster Google Distributed Cloud dapat menyebabkan gangguan aplikasi karena node terkuras. Proses pengosongan ini menyebabkan semua Pod yang berjalan pada node mematikan dan memulai ulang node yang tersisa di cluster.

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

PodDisruptionBudgets (PDB)

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

Mulai rilis 1.29, node dikosongkan dengan Eviction API, yang memenuhi PodDisruptionBudgets (PDB). PDB dapat digunakan untuk memastikan bahwa sebuah jumlah replika yang 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.

Dalam rilis 1.28 dan yang lebih lama, Google Distributed Cloud tidak menerima PDB saat node selama upgrade berlangsung. Sebaliknya, proses pengeringan {i>node<i} adalah upaya terbaik. Agak besar Pod mungkin terjebak dalam status Terminating dan menolak untuk mengosongkan node. Tujuan upgrade dapat dilanjutkan, bahkan dengan Pod yang macet, saat proses pengosongan pada node memerlukan waktu lebih dari 20 menit.

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

Langkah selanjutnya