Dokumen ini menjelaskan praktik terbaik dan pertimbangan untuk mengupgrade Google Distributed Cloud. Anda akan mempelajari cara mempersiapkan upgrade cluster, dan cara terbaik yang harus diikuti sebelum upgrade. Praktik terbaik ini membantu mengurangi risiko terkait upgrade cluster.
Jika Anda memiliki beberapa lingkungan seperti test, pengembangan, dan produksi, sebaiknya mulai dengan lingkungan yang paling tidak kritis seperti test, dan memverifikasi fungsi upgrade. Setelah Anda memverifikasi bahwa upgrade berhasil, lanjutkan ke lingkungan berikutnya. Ulangi proses ini hingga Anda mengupgrade lingkungan produksi. Pendekatan ini memungkinkan Anda beralih dari satu titik penting ke langkah berikutnya, dan memverifikasi bahwa upgrade dan beban kerja Anda semuanya berjalan dengan benar.
Upgrade checklist
Sebaiknya ikuti semua praktik terbaik dalam dokumen ini. Gunakan daftar periksa berikut untuk membantu melacak kemajuan Anda. Link setiap item dalam daftar ke bagian dalam dokumen ini dengan informasi selengkapnya:
Setelah pemeriksaan ini selesai, Anda dapat memulai proses upgrade. Memantau progres hingga semua cluster berhasil diupgrade.
Merencanakan upgrade
Update dapat mengganggu. Sebelum Anda memulai peningkatan, rencanakan dengan saksama untuk memastikan bahwa lingkungan dan aplikasi Anda siap dan siap.
Memperkirakan komitmen waktu dan merencanakan masa pemeliharaan
Waktu yang diperlukan untuk mengupgrade cluster bervariasi, bergantung pada jumlah {i>node<i} dan kepadatan beban kerja yang berjalan padanya. Agar berhasil menyelesaikan upgrade cluster, gunakan masa pemeliharaan dengan waktu yang cukup.
Untuk menghitung perkiraan kasar upgrade, gunakan 10 minutes * the number of
nodes
untuk upgrade node tunggal serentak.
Misalnya, jika Anda memiliki lima puluh node dalam sebuah cluster, total waktu upgradenya adalah
menjadi sekitar lima ratus menit: 10 minutes * 50 nodes = 500 minutes
.
Memeriksa kompatibilitas komponen GKE Enterprise lainnya
Jika cluster Anda menjalankan komponen GKE Enterprise seperti Cloud Service Mesh, Config Sync, Pengontrol Kebijakan, atau Pengontrol Konfigurasi, centang Dukungan upgrade dan versi GKE Enterprise dan verifikasi versi yang didukung dengan Google Distributed Cloud sebelum dan sesudah {i>upgrade.<i}
Pemeriksaan kompatibilitas didasarkan pada admin atau cluster pengguna yang Cloud Service Mesh, Config Sync, Pengontrol Kebijakan, atau Pengontrol Konfigurasi di-deploy ke dalam aplikasi tersebut.
Memeriksa penggunaan resource cluster
Untuk memastikan bahwa Pod dapat dievakuasi ketika node terkuras dan bahwa ada cukup resource dalam cluster yang sedang diupgrade untuk mengelola upgrade. Periksa penggunaan resource cluster saat ini. Untuk memeriksa penggunaan resource pada menggunakan dasbor kustom di Google Cloud Observability.
Anda dapat menggunakan perintah, seperti kubectl top nodes
untuk mendapatkan cluster saat ini
penggunaan resource, tetapi dasbor dapat memberikan tampilan resource yang lebih mendetail
yang digunakan seiring waktu. Data penggunaan resource ini dapat
membantu menunjukkan kapan
upgrade akan menyebabkan gangguan yang paling sedikit, seperti selama akhir pekan atau malam,
tergantung pada workload yang berjalan
dan kasus penggunaannya.
Waktu untuk upgrade cluster admin mungkin kurang penting dibandingkan untuk karena upgrade cluster admin biasanya tidak memperkenalkan periode nonaktif aplikasi. Namun, penting untuk memeriksa ketersediaan sebelum Anda memulai upgrade cluster admin. Selain itu, mengupgrade admin mungkin menyiratkan risiko tertentu, dan oleh karena itu mungkin direkomendasikan dalam periode penggunaan aktif saat akses pengelolaan ke cluster tidak terlalu penting.
Resource bidang kontrol cluster admin
Semua tugas dan pengontrol upgrade berjalan di bidang kontrol cluster admin node. Periksa pemakaian resource node bidang kontrol ini untuk mengetahui ketersediaan resource komputasi. Proses upgrade biasanya memerlukan 1.000 millicore CPU (1.000 mCPU) dan 2-3 GiB RAM untuk setiap set pengontrol siklus proses. Perlu diketahui bahwa unit CPU 'mCPU' singkatan dari "seribuan inti", jadi 1000 millicores adalah setara dengan satu inti di setiap node untuk setiap set pengontrol siklus proses. Untuk mengurangi resource komputasi tambahan yang diperlukan selama upgrade, cobalah menjaga cluster pengguna pada versi yang sama.
Dalam contoh deployment berikut, kedua cluster pengguna berada pada titik yang berbeda versi selain cluster admin:
Cluster Admin | Cluster pengguna 1 | Cluster pengguna 2 |
---|---|---|
1.13.3 | 1.13.0 | 1.13.2 |
Serangkaian pengontrol siklus proses di-deploy di pengontrol admin untuk setiap
versi yang sedang digunakan. Dalam contoh ini, ada tiga kumpulan pengontrol siklus proses:
1.13.3
, 1.13.0
, dan 1.13.2
. Setiap kumpulan pengontrol siklus proses menggunakan
total 1.000 mCPU dan 3 GiB RAM. Total konsumsi resource saat ini dari
pengontrol siklus proses ini sebesar 3.000 mCPU dan RAM 9 GiB.
Jika cluster pengguna 2 diupgrade ke 1.13.3
, kini ada dua kumpulan siklus proses
pengontrol: 1.13.3
dan 1.13.0
:
Cluster Admin | Cluster pengguna 1 | Cluster pengguna 2 |
---|---|---|
1.13.3 | 1.13.0 | 1.13.3 |
Pengontrol siklus proses kini menggunakan total 2.000 mCPU dan 6 GiB RAM.
Jika cluster pengguna 1 diupgrade ke 1.13.3
, semua fleet kini berjalan dengan cara yang sama
versi: 1.13.3
:
Cluster Admin | Cluster pengguna 1 | Cluster pengguna 2 |
---|---|---|
1.13.3 | 1.13.3 | 1.13.3 |
Kini hanya ada satu rangkaian pengontrol siklus proses, yang menggunakan total 1.000 mCPU dan 3 GiB RAM.
Dalam contoh berikut, semua cluster pengguna adalah versi yang sama. Jika setelah cluster admin diupgrade, hanya dua rangkaian pengontrol siklus proses yang digunakan, jadi konsumsi resource komputasi berkurang:
Cluster Admin | Cluster pengguna 1 | Cluster pengguna 2 |
---|---|---|
1.14.0 | 1.13.3 | 1.13.3 |
Dalam contoh ini, pengontrol siklus proses kembali menggunakan total 2.000 mCPU dan RAM 6 GiB hingga semua cluster pengguna diupgrade ke versi yang sama dengan ke cluster admin.
Jika node bidang kontrol tidak memiliki resource komputasi tambahan
Anda mungkin melihat Pod seperti anthos-cluster-operator
,
capi-controller-manager
, cap-controller-manager
, atau
cap-kubeadm-bootstraper
dalam status Pending
. Untuk mengatasi masalah ini, upgrade
beberapa klaster pengguna ke versi yang sama
untuk mengonsolidasikan versi dan
mengurangi jumlah pengontrol siklus proses yang digunakan. Jika upgrade Anda sudah
mengalami masalah, Anda juga dapat menggunakan kubectl edit deployment
untuk mengedit
deployment untuk menurunkan permintaan CPU dan RAM agar bisa masuk ke dalam cluster admin
bidang kontrol.
Tabel berikut menjelaskan persyaratan resource komputasi untuk berbagai skenario upgrade:
Cluster | Resource cluster admin diperlukan |
---|---|
Upgrade cluster pengguna | Upgrade ke versi yang sama dari cluster lain: T/A Upgrade ke versi cluster admin atau pengguna lain yang berbeda: 1.000 mCPU dan 3 GiB RAM Cluster pengguna di cluster hybrid memiliki resource yang sama lainnya. |
Upgrade cluster admin (dengan cluster pengguna) | 1.000 mCPU dan 3 GiB RAM |
Upgrade cluster hybrid (tanpa cluster pengguna) | 1.000 mCPU dan lonjakan RAM 3 GiB. Resource akan ditampilkan setelah digunakan. |
Mandiri | 200 mCPU dan 1 GiB RAM. Resource akan ditampilkan setelah digunakan. |
Mencadangkan cluster
Sebelum Anda memulai upgrade,
mencadangkan cluster menggunakan perintah bmctl backup cluster
.
Karena file cadangan berisi informasi sensitif, simpan file cadangan dengan aman.
Memastikan cluster telah dikonfigurasi dan berfungsi dengan baik
Untuk memeriksa kondisi cluster sebelum upgrade, jalankan bmctl check cluster
di
gugus ini. Perintah tersebut menjalankan pemeriksaan lanjutan, seperti untuk mengidentifikasi node yang
tidak dikonfigurasi dengan benar, atau yang memiliki Pod dengan status macet.
Saat Anda menjalankan perintah bmctl upgrade cluster
untuk mengupgrade cluster, beberapa
pemeriksaan preflight berjalan. Proses upgrade akan berhenti jika pemeriksaan ini tidak
berhasil. Sebaiknya identifikasi dan perbaiki masalah ini secara proaktif dengan
bmctl check cluster
daripada mengandalkan pemeriksaan preflight yang
untuk melindungi klaster dari berbagai
kemungkinan kerusakan.
Meninjau deployment workload pengguna
Ada dua area yang perlu dipertimbangkan untuk beban kerja pengguna: pengosongan dan API kompatibilitas yang berbeda.
Penghentian beban kerja
Beban kerja pengguna pada node habis selama upgrade. Jika beban kerja memiliki replika tunggal atau semua replika ada di node yang sama, pengosongan beban kerja mungkin menyebabkan gangguan pada layanan yang sedang berjalan di cluster. Jalankan workload Anda dengan beberapa replika. Nomor replika harus di atas node serentak angka
Untuk menghindari upgrade macet, proses pengurasan upgrade ke
1.30 tidak mematuhi anggaran gangguan pod (PDB). Workload
dapat berjalan dalam kondisi menurun, dan replika penayangan yang paling sedikit adalah total
replica number - concurrent upgrade number
.
Kompatibilitas API
Untuk kompatibilitas API, periksa kompatibilitas API workload Anda dengan minor yang lebih baru versi Kubernetes saat melakukan upgrade versi minor. Jika perlu, upgrade workload ke versi yang kompatibel. Jika memungkinkan, tim engineer GKE Enterprise memberikan petunjuk untuk mengidentifikasi workload menggunakan API yang tidak kompatibel, seperti API Kubernetes dihapus.
Jika Anda menggunakan Cloud Service Mesh, Config Sync, Pengontrol Kebijakan, Pengontrol Konfigurasi, atau GKE Enterprise lainnya , periksa apakah versi yang diinstal kompatibel dengan versi Google Distributed Cloud. Untuk kompatibilitas versi komponen GKE Enterprise informasi, lihat Dukungan upgrade dan versi GKE Enterprise.
Mengaudit penggunaan webhook
Memeriksa apakah cluster Anda memiliki webhook, terutama resource Pod untuk diaudit seperti Pengontrol Kebijakan. Proses pengosongan selama upgrade cluster dapat mengganggu layanan webhook Pengontrol Kebijakan, yang dapat menyebabkan upgrade macet atau memakan waktu lama. Sebaiknya nonaktifkan fitur ini untuk sementara webhook, atau menggunakan deployment dengan ketersediaan tinggi (HA).
Meninjau penggunaan fitur Pratinjau
Fitur Pratinjau dapat berubah dan disediakan hanya untuk tujuan pengujian dan evaluasi. Jangan gunakan fitur Pratinjau di cluster produksi Anda. Kami tidak menjamin bahwa yang menggunakan fitur Pratinjau dapat diupgrade. Dalam beberapa kasus, kita secara eksplisit memblokir upgrade untuk cluster yang menggunakan fitur Pratinjau.
Untuk mengetahui informasi tentang perubahan yang dapat menyebabkan gangguan terkait upgrade, lihat catatan rilis.
Memeriksa status SELinux
Jika Anda ingin mengaktifkan SELinux untuk
mengamankan kontainer Anda, Anda harus memastikan
SELinux diaktifkan dalam mode Enforced
di semua mesin host Anda. Dimulai dengan
Google Distributed Cloud rilis 1.9.0 atau yang lebih baru, Anda dapat mengaktifkan atau menonaktifkan SELinux
sebelum atau setelah pembuatan atau upgrade cluster. SELinux diaktifkan oleh
default di Red Hat Enterprise Linux (RHEL). Jika SELinux dinonaktifkan pada
mesin {i>host<i} Anda atau Anda
tidak yakin, lihat
Mengamankan container Anda menggunakan SELinux
untuk mendapatkan petunjuk cara mengaktifkannya.
Google Distributed Cloud mendukung SELinux hanya di sistem RHEL.
Jangan ubah konfigurasi kepadatan Pod
Google Distributed Cloud mendukung konfigurasi hingga 250 pod maksimum per
dengan nodeConfig.PodDensity.MaxPodsPerNode
. Anda dapat mengonfigurasi kepadatan pod
hanya selama pembuatan cluster. Anda tidak dapat memperbarui setelan kepadatan pod yang ada
klaster. Jangan mencoba mengubah konfigurasi kepadatan pod selama upgrade.
Pastikan node bidang kontrol dan load balancer tidak dalam mode pemeliharaan
Pastikan bidang kontrol dan node load balancer tidak sedang dalam pemeliharaan sebelum memulai upgrade. Jika node ada dalam mode pemeliharaan, upgrade jeda untuk memastikan bidang kontrol dan kumpulan node load balancer memadai yang tersedia.
Langkah selanjutnya
- Upgrade Google Distributed Cloud
- Pelajari kebijakan siklus proses dan tahapan upgrade
- Memecahkan masalah upgrade cluster