Dokumen ini menjelaskan praktik terbaik dan pertimbangan untuk mengupgrade Google Distributed Cloud. Anda akan mempelajari cara mempersiapkan upgrade cluster, dan praktik terbaik yang harus diikuti sebelum upgrade. Praktik terbaik ini membantu mengurangi risiko yang terkait dengan upgrade cluster.
Jika Anda memiliki beberapa lingkungan seperti test, development, dan production, sebaiknya mulai dengan lingkungan yang paling tidak penting, seperti test, dan verifikasi fungsi upgrade. Setelah Anda memverifikasi bahwa upgrade berhasil, lanjutkan ke lingkungan berikutnya. Ulangi proses ini hingga Anda mengupgrade lingkungan produksi. Pendekatan ini memungkinkan Anda berpindah dari satu titik penting ke titik penting berikutnya, dan memverifikasi bahwa upgrade dan beban kerja Anda berjalan dengan benar.
Checklist upgrade
Sebaiknya Anda mengikuti semua praktik terbaik dalam dokumen ini. Gunakan checklist berikut untuk membantu Anda melacak progres. Setiap item dalam daftar tertaut ke bagian dalam dokumen ini yang berisi informasi selengkapnya:
Setelah pemeriksaan ini selesai, Anda dapat memulai proses upgrade. Pantau progres hingga semua cluster berhasil diupgrade.
Merencanakan upgrade
Update dapat mengganggu. Sebelum memulai upgrade, rencanakan dengan cermat untuk memastikan lingkungan dan aplikasi Anda sudah siap dan dipersiapkan.
Perkirakan komitmen waktu dan rencanakan masa pemeliharaan
Durasi yang diperlukan untuk mengupgrade cluster bervariasi, bergantung pada jumlah node dan kepadatan workload yang berjalan di node tersebut. Untuk berhasil menyelesaikan upgrade cluster, gunakan periode pemeliharaan dengan waktu yang cukup.
Untuk menghitung perkiraan kasar upgrade, gunakan 10 minutes * the number of
nodes
untuk upgrade node serentak tunggal.
Misalnya, jika Anda memiliki lima puluh node dalam cluster, total waktu upgrade adalah sekitar lima ratus menit: 10 minutes * 50 nodes = 500 minutes
.
Memeriksa kompatibilitas produk Google Cloud lain
Jika cluster Anda menjalankan Cloud Service Mesh, Config Sync, atau Policy Controller, periksa Dukungan versi dan upgrade dan verifikasi versi yang didukung dengan Google Distributed Cloud sebelum dan setelah upgrade.
Pemeriksaan kompatibilitas didasarkan pada cluster admin atau pengguna tempat Cloud Service Mesh, Config Sync, atau Policy Controller di-deploy.
Memeriksa pemanfaatan resource cluster
Untuk memastikan bahwa Pod dapat dievakuasi saat node dikuras dan ada cukup banyak resource di cluster yang diupgrade untuk mengelola upgrade, periksa penggunaan resource saat ini di cluster. Untuk memeriksa penggunaan resource cluster, gunakan dasbor kustom di Google Cloud Observability.
Anda dapat menggunakan perintah, seperti kubectl top nodes
untuk mendapatkan penggunaan resource cluster saat ini, tetapi dasbor dapat memberikan tampilan yang lebih mendetail tentang resource yang digunakan dari waktu ke waktu. Data penggunaan resource ini dapat membantu menunjukkan kapan upgrade akan menyebabkan gangguan paling sedikit, seperti selama akhir pekan atau malam hari, bergantung pada beban kerja yang berjalan dan kasus penggunaan.
Waktu untuk upgrade cluster admin mungkin tidak terlalu penting dibandingkan dengan cluster pengguna, karena upgrade cluster admin biasanya tidak menyebabkan periode istirahat aplikasi. Namun, Anda tetap harus memeriksa ketersediaan resource sebelum memulai upgrade cluster admin. Selain itu, mengupgrade cluster admin dapat menimbulkan risiko tertentu, sehingga upgrade sebaiknya dilakukan selama periode penggunaan yang kurang aktif saat akses pengelolaan ke cluster tidak terlalu penting.
Resource bidang kontrol cluster admin
Semua pengontrol dan tugas upgrade berjalan di node bidang kontrol cluster admin. Periksa konsumsi resource node bidang kontrol ini untuk mengetahui ketersediaan resource komputasi. Proses upgrade biasanya memerlukan 1000 milicore CPU (1000 mCPU) dan RAM 2-3 GiB untuk setiap set pengontrol siklus proses. Perhatikan bahwa unit CPU 'mCPU' adalah singkatan dari "seperseribu core", sehingga 1.000 milicore setara dengan satu core di setiap node untuk setiap set pengontrol siklus proses. Untuk mengurangi resource komputasi tambahan yang diperlukan selama upgrade, coba pertahankan cluster pengguna pada versi yang sama.
Dalam contoh deployment berikut, dua cluster pengguna memiliki versi yang berbeda dengan 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 digunakan. Dalam contoh ini, ada tiga set pengontrol siklus proses:
1.13.3
, 1.13.0
, dan 1.13.2
. Setiap set pengontrol siklus proses menggunakan
total 1.000 mCPU dan RAM 3 GiB. Total konsumsi resource saat ini dari
pengontrol siklus proses ini adalah 3000 mCPU dan 9 GiB RAM.
Jika cluster pengguna 2 diupgrade ke 1.13.3
, kini ada dua set pengontrol siklus proses: 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 RAM 6 GiB.
Jika cluster pengguna 1 diupgrade ke 1.13.3
, semua fleet kini berjalan di versi yang sama: 1.13.3
:
Cluster admin | Cluster pengguna 1 | Cluster pengguna 2 |
---|---|---|
1.13.3 | 1.13.3 | 1.13.3 |
Sekarang hanya ada satu set pengontrol siklus proses, yang menggunakan total 1.000 mCPU dan RAM 3 GiB.
Dalam contoh berikut, semua cluster pengguna memiliki versi yang sama. Jika cluster admin diupgrade, hanya dua set pengontrol siklus proses yang digunakan, sehingga 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 6 GiB RAM hingga semua cluster pengguna diupgrade ke versi yang sama dengan cluster admin.
Jika node bidang kontrol tidak memiliki resource komputasi tambahan selama
upgrade, 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 cluster pengguna ke versi yang sama untuk menggabungkan versi dan
mengurangi jumlah pengontrol siklus proses yang digunakan. Jika upgrade sudah
macet, Anda juga dapat menggunakan kubectl edit deployment
untuk mengedit deployment
yang tertunda guna menurunkan permintaan CPU dan RAM agar sesuai dengan
bidang kontrol cluster admin.
Tabel berikut menjelaskan persyaratan resource komputasi untuk berbagai skenario upgrade:
Cluster | Resource cluster admin diperlukan |
---|---|
Upgrade cluster pengguna | Upgrade ke versi yang sama dengan cluster lain: N/A Upgrade ke versi yang berbeda dengan cluster admin atau pengguna lain: 1.000 mCPU dan RAM 3 GiB Cluster pengguna dalam cluster hybrid memiliki persyaratan resource yang sama. |
Upgrade cluster admin (dengan cluster pengguna) | 1000 mCPU dan RAM 3 GiB |
Upgrade cluster hybrid (tanpa cluster pengguna) | Lonjakan 1.000 mCPU dan RAM 3 GiB. Resource dikembalikan setelah digunakan. |
Mandiri | Lonjakan 200 mCPU dan RAM 1 GiB. Resource dikembalikan setelah digunakan. |
Mencadangkan cluster
Sebelum memulai upgrade,
buat cadangan cluster menggunakan perintah bmctl backup cluster
.
Karena file cadangan berisi informasi sensitif, simpan file cadangan dengan aman.
Pastikan cluster dikonfigurasi dan berfungsi dengan baik
Untuk memeriksa kondisi cluster sebelum upgrade, jalankan bmctl check cluster
di
cluster. Perintah ini menjalankan pemeriksaan lanjutan, seperti mengidentifikasi node yang tidak dikonfigurasi dengan benar, atau yang memiliki Pod dalam status macet.
Saat Anda menjalankan perintah bmctl upgrade cluster
untuk mengupgrade cluster, beberapa pemeriksaan pra-penerbangan akan dijalankan. Proses upgrade akan berhenti jika pemeriksaan ini tidak berhasil. Sebaiknya identifikasi dan perbaiki masalah ini secara proaktif dengan perintah
bmctl check cluster
, daripada mengandalkan pemeriksaan pra-penerbangan yang
ada untuk melindungi cluster dari kemungkinan kerusakan.
Meninjau deployment workload pengguna
Ada dua hal yang perlu dipertimbangkan untuk workload pengguna: pengurasan dan kompatibilitas API.
Pengurasan workload
Beban kerja pengguna pada node akan dikuras selama upgrade. Jika workload memiliki satu replika atau semua replika berada di node yang sama, pengurasan workload dapat menyebabkan gangguan pada layanan yang berjalan di cluster. Jalankan workload Anda dengan beberapa replika. Jumlah replika harus lebih besar dari jumlah node serentak.
Untuk menghindari upgrade yang macet, proses pengurasan saat mengupgrade hingga
1.33 tidak mematuhi anggaran gangguan pod (PDB). Workload mungkin berjalan dalam kondisi yang menurun, dan replika yang paling sedikit melayani adalah total
replica number - concurrent upgrade number
.
Kompatibilitas API
Untuk kompatibilitas API, periksa kompatibilitas API beban kerja Anda dengan versi minor Kubernetes yang lebih baru saat melakukan upgrade versi minor. Jika perlu, upgrade workload ke versi yang kompatibel. Jika memungkinkan, tim engineering GKE memberikan petunjuk untuk mengidentifikasi beban kerja yang menggunakan API yang tidak kompatibel, seperti API Kubernetes yang dihapus.
Jika Anda menggunakan Cloud Service Mesh, Config Sync, Policy Controller, periksa apakah versi yang diinstal kompatibel dengan Google Distributed Cloud versi baru. Untuk mengetahui informasi kompatibilitas versi, lihat Dukungan versi dan upgrade.
Mengaudit penggunaan webhook
Periksa apakah cluster Anda memiliki webhook, terutama resource Pod untuk tujuan audit seperti Policy Controller. Proses pengurasan selama upgrade cluster dapat mengganggu layanan webhook Policy Controller, yang dapat menyebabkan upgrade macet atau membutuhkan waktu yang lama. Sebaiknya nonaktifkan sementara webhook ini atau gunakan 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 cluster yang menggunakan fitur Pratinjau dapat diupgrade. Dalam beberapa kasus, kami secara eksplisit memblokir upgrade untuk cluster yang menggunakan fitur Pratinjau.
Untuk mengetahui informasi tentang perubahan yang menyebabkan gangguan terkait upgrade, lihat catatan rilis.
Memeriksa status SELinux
Jika ingin mengaktifkan SELinux untuk mengamankan container, Anda harus memastikan bahwa SELinux diaktifkan dalam mode Enforced
di semua mesin host Anda. Mulai dari rilis Google Distributed Cloud 1.9.0 atau yang lebih baru, Anda dapat mengaktifkan atau menonaktifkan SELinux sebelum atau setelah pembuatan cluster atau upgrade cluster. SELinux diaktifkan secara
default di Red Hat Enterprise Linux (RHEL). Jika SELinux dinonaktifkan di komputer host Anda atau Anda tidak yakin, lihat Mengamankan penampung Anda menggunakan SELinux untuk mengetahui petunjuk cara mengaktifkannya.
Google Distributed Cloud hanya mendukung SELinux di sistem RHEL.
Jangan ubah konfigurasi kepadatan Pod
Google Distributed Cloud mendukung konfigurasi hingga 250 pod maksimum per node dengan nodeConfig.PodDensity.MaxPodsPerNode
. Anda hanya dapat mengonfigurasi kepadatan pod
selama pembuatan cluster. Anda tidak dapat memperbarui setelan kepadatan pod untuk cluster yang sudah ada. Jangan mencoba mengubah konfigurasi kepadatan pod selama upgrade.
Pastikan node load balancer dan bidang kontrol tidak dalam mode pemeliharaan
Pastikan node bidang kontrol dan load balancer tidak dalam pemeliharaan sebelum memulai upgrade. Jika ada node dalam mode pemeliharaan, upgrade akan dijeda untuk memastikan ketersediaan node load balancer dan bidang kontrol yang memadai.
Langkah berikutnya
- Mengupgrade Google Distributed Cloud
- Pelajari lebih lanjut siklus proses dan tahapan upgrade
- Memecahkan masalah upgrade cluster