Praktik terbaik untuk upgrade cluster Google Distributed Cloud

Praktik terbaik upgrade terstruktur untuk Google Distributed Cloud memungkinkan Anda meminimalkan gangguan layanan dan mengurangi risiko operasional. Validasi pra-upgrade membantu memastikan bahwa cluster dan workload Anda tetap stabil di setiap transisi versi.

Untuk lingkungan yang mencakup tingkat pengujian, pengembangan, dan produksi, lakukan upgrade secara berurutan mulai dari tingkat yang paling tidak penting. Memverifikasi kondisi cluster dan perilaku workload di setiap tahap membantu Anda mengidentifikasi potensi masalah sebelum mengupdate sistem produksi.

Checklist upgrade

Sebaiknya ikuti 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 progresnya hingga semua cluster berhasil diupgrade.

Merencanakan upgrade

Update dapat mengganggu. Sebelum memulai upgrade, rencanakan dengan cermat untuk memastikan bahwa lingkungan dan aplikasi Anda sudah siap dan dipersiapkan.

Memperkirakan komitmen waktu dan merencanakan masa pemeliharaan

Durasi waktu yang diperlukan untuk mengupgrade cluster bervariasi, bergantung pada jumlah node dan kepadatan workload yang berjalan di dalamnya. 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 serentak tunggal.

Misalnya, jika Anda memiliki lima puluh node dalam sebuah cluster, total waktu upgrade akan menjadi sekitar lima ratus menit: 10 minutes * 50 nodes = 500 minutes.

Periksa kompatibilitas produk Google Cloud lainnya

Jika cluster Anda menjalankan Cloud Service Mesh, Config Sync, atau Pengontrol Kebijakan, 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 Pengontrol Kebijakan di-deploy.

Memeriksa pemanfaatan resource cluster

Untuk memastikan bahwa Pod dapat dievakuasi saat node dikosongkan dan ada cukup resource dalam cluster yang sedang diupgrade untuk mengelola upgrade, periksa penggunaan resource cluster saat ini. Untuk memeriksa penggunaan resource bagi cluster Anda, 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 workload yang berjalan dan kasus penggunaan.

Waktu untuk upgrade cluster admin mungkin tidak terlalu penting dibandingkan untuk cluster pengguna, karena upgrade cluster admin biasanya tidak menyebabkan periode nonaktif aplikasi. Namun, Anda tetap harus memeriksa resource yang tersedia sebelum memulai upgrade cluster admin. Selain itu, mengupgrade cluster admin mungkin menimbulkan beberapa risiko, sehingga mungkin direkomendasikan selama periode penggunaan yang kurang aktif saat akses pengelolaan ke cluster kurang 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 resource komputasi yang tersedia. Proses upgrade biasanya memerlukan 1.000 millicore CPU (1.000 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 millicore 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 berada di versi yang berbeda dengan cluster admin:

Cluster admin Cluster pengguna 1 Cluster pengguna 2
1.13.3 1.13.0 1.13.2

Satu set 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 3.000 mCPU dan RAM 9 GiB.

Jika cluster pengguna 2 diupgrade ke 1.13.3, sekarang 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 pada 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 RAM 6 GiB 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 yang diperlukan
Upgrade cluster pengguna Upgrade ke versi yang sama dari cluster lain: T/A

Upgrade ke versi yang berbeda dari 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) 1.000 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, cadangkan cluster menggunakan perintah bmctl backup cluster.

Karena file cadangan berisi informasi sensitif, simpan file cadangan dengan aman.

Memastikan cluster dikonfigurasi dan berfungsi dengan baik

Untuk memeriksa responsivitas cluster sebelum upgrade, jalankan bmctl check cluster di cluster. Perintah ini menjalankan pemeriksaan lanjutan, seperti untuk mengidentifikasi node yang tidak dikonfigurasi dengan benar, atau yang memiliki Pod yang macet.

Saat Anda menjalankan perintah bmctl upgrade cluster untuk mengupgrade cluster, beberapa pemeriksaan preflight 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 preflight yang ada untuk melindungi cluster dari kemungkinan kerusakan.

Meninjau deployment workload pengguna

Ada dua area yang perlu dipertimbangkan untuk workload pengguna: pengosongan dan kompatibilitas API.

Pengosongan workload

Workload pengguna di node akan dikosongkan selama upgrade. Jika workload memiliki satu replika atau semua replika berada di node yang sama, pengosongan 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 pengosongan saat mengupgrade hingga versi 1.36 tidak mematuhi anggaran gangguan pod (PDB). Workload mungkin berjalan dalam status menurun, dan replika yang paling sedikit menyajikan adalah total replica number - concurrent upgrade number.

Kompatibilitas API

Untuk kompatibilitas API, periksa kompatibilitas API workload 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 workload yang menggunakan API yang tidak kompatibel, seperti Kubernetes API yang dihapus.

Jika Anda menggunakan Cloud Service Mesh, Config Sync, Pengontrol Kebijakan, periksa apakah versi yang diinstal kompatibel dengan versi baru Google Distributed Cloud. Untuk informasi kompatibilitas versi, lihat Dukungan versi dan upgrade.

Mengaudit penggunaan webhook

Periksa apakah cluster Anda memiliki webhook, terutama resource Pod untuk tujuan audit seperti Pengontrol Kebijakan. Proses pengosongan selama upgrade cluster dapat mengganggu layanan webhook Pengontrol Kebijakan, yang dapat menyebabkan upgrade terhenti atau memerlukan waktu lama. Sebaiknya nonaktifkan webhook ini untuk sementara, atau gunakan deployment ketersediaan tinggi (HA).

Meninjau penggunaan fitur Pratinjau

Fitur Pratinjau dapat berubah sewaktu-waktu 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 dapat 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. Mulai dari Google Distributed Cloud rilis 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 mesin host atau Anda tidak yakin, lihat Mengamankan container 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 maksimum 250 pod 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 ada. Jangan mencoba mengubah konfigurasi kepadatan pod selama upgrade.

Memastikan node bidang kontrol dan load balancer tidak dalam mode pemeliharaan

Pastikan node bidang kontrol dan load balancer tidak sedang dalam pemeliharaan sebelum memulai upgrade. Jika ada node yang berada dalam mode pemeliharaan, upgrade akan dijeda untuk memastikan node pool bidang kontrol dan load balancer tersedia secara memadai.

Langkah berikutnya