Praktik terbaik untuk GKE pada upgrade cluster Bare Metal

Dokumen ini menjelaskan praktik terbaik dan pertimbangan untuk mengupgrade GKE pada Bare Metal. Anda akan mempelajari cara mempersiapkan upgrade cluster, dan praktik terbaik yang harus diikuti sebelum upgrade. Praktik terbaik ini membantu mengurangi risiko terkait upgrade cluster.

Jika Anda memiliki beberapa lingkungan seperti pengujian, pengembangan, dan produksi, sebaiknya memulai dengan lingkungan yang paling tidak kritis, seperti pengujian, dan memverifikasi fungsi upgrade. Setelah Anda memastikan bahwa upgrade berhasil, lanjutkan ke lingkungan berikutnya. Ulangi proses ini sampai Anda mengupgrade lingkungan produksi. Pendekatan ini memungkinkan Anda berpindah dari satu titik penting ke titik berikutnya, dan memverifikasi bahwa upgrade dan workload Anda semua berjalan dengan benar.

Checklist upgrade

Sebaiknya ikuti semua praktik terbaik dalam dokumen ini. Gunakan checklist berikut untuk membantu melacak progres Anda. Setiap item dalam daftar tertaut ke bagian dalam dokumen ini yang berisi informasi lebih lanjut:

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 siap digunakan.

Memperkirakan komitmen waktu dan merencanakan masa pemeliharaan

Jumlah waktu yang diperlukan untuk mengupgrade cluster bervariasi, bergantung pada jumlah node dan kepadatan beban kerja yang berjalan di cluster tersebut. 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 satu upgrade node serentak.

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

Memeriksa kompatibilitas komponen GKE Enterprise lainnya

Jika cluster Anda menjalankan komponen GKE Enterprise seperti Anthos Service Mesh, Config Sync, Pengontrol Kebijakan, atau Pengontrol Konfigurasi, periksa matriks kompatibilitas GKE Enterprise dan verifikasi versi yang didukung dengan GKE pada Bare Metal sebelum dan sesudah upgrade.

Pemeriksaan kompatibilitas didasarkan pada admin atau cluster pengguna tempat Anthos Service Mesh, Config Sync, Pengontrol Kebijakan, atau Pengontrol Konfigurasi 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 pada cluster Anda, gunakan dasbor kustom di Kemampuan Observasi Google Cloud.

Anda dapat menggunakan perintah, seperti kubectl top nodes untuk mengetahui penggunaan resource cluster saat ini, tetapi dasbor dapat memberikan gambaran 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 dan kasus penggunaan yang berjalan.

Waktu untuk upgrade cluster admin mungkin kurang penting dibandingkan untuk cluster pengguna, karena upgrade cluster admin biasanya tidak menyebabkan periode nonaktif aplikasi. Namun, penting untuk memeriksa resource yang tersedia sebelum Anda memulai upgrade cluster admin. Selain itu, mengupgrade cluster admin mungkin menyiratkan beberapa risiko, sehingga mungkin direkomendasikan selama periode penggunaan yang kurang aktif jika 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 resource komputasi yang tersedia. Proses upgrade biasanya memerlukan CPU 1.000 milicore (1.000 mCPU) dan RAM 2-3 GiB untuk setiap set pengontrol siklus proses. Perlu diperhatikan bahwa unit CPU 'mCPU' adalah singkatan dari "seperseribu inti", sehingga 1.000 milicore setara dengan satu inti pada setiap node untuk setiap set pengontrol siklus proses. Untuk mengurangi resource komputasi tambahan yang diperlukan selama upgrade, cobalah pertahankan cluster pengguna pada versi yang sama.

Pada contoh deployment berikut, kedua 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 kumpulan pengontrol siklus proses: 1.13.3, 1.13.0, dan 1.13.2. Setiap set pengontrol siklus proses menggunakan total 1.000 mCPU dan 3 GiB RAM. Total konsumsi resource saat ini dari pengontrol siklus proses ini adalah 3.000 mCPU dan 9 GiB RAM.

Jika cluster pengguna 2 diupgrade ke 1.13.3, sekarang ada dua kumpulan 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

Saat ini, pengontrol siklus proses menggunakan total 2.000 mCPU dan 6 GiB RAM.

Jika cluster pengguna 1 diupgrade ke 1.13.3, semua fleet sekarang akan berjalan dalam versi yang sama: 1.13.3:

Cluster admin Cluster pengguna 1 Cluster pengguna 2
1.13.3 1.13.3 1.13.3

Kini hanya ada satu set pengontrol siklus proses, yang menggunakan total 1.000 mCPU dan 3 GiB RAM.

Pada contoh berikut, semua cluster pengguna memiliki versi yang sama. Jika cluster admin diupgrade, hanya dua set pengontrol siklus proses yang akan digunakan, sehingga konsumsi resource komputasi dikurangi:

Cluster admin Cluster pengguna 1 Cluster pengguna 2
1.14.0 1.13.3 1.13.3

Dalam contoh ini, pengontrol siklus proses menggunakan total 2.000 mCPU dan 6 GiB RAM lagi 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 terhenti, 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 cluster lain yang sama: T/A

Upgrade ke versi cluster pengguna atau admin lain yang berbeda: 1.000 mCPU dan 3 GiB RAM

Cluster pengguna di 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 RAM 1.000 mCPU dan 3 GiB. Resource akan ditampilkan setelah digunakan.
Mandiri Lonjakan RAM 1 GiB dan 200 mCPU. Resource akan ditampilkan setelah digunakan.

Cadangkan cluster

Sebelum memulai upgrade, cadangkan cluster menggunakan perintah bmctl backup cluster.

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

Memverifikasi bahwa cluster telah dikonfigurasi dan berfungsi dengan benar

Untuk memeriksa kondisi cluster sebelum upgrade, jalankan bmctl check cluster di cluster tersebut. Perintah ini menjalankan pemeriksaan lanjutan, misalnya untuk mengidentifikasi node yang tidak dikonfigurasi dengan benar, atau yang memiliki Pod yang berada dalam status macet.

Saat Anda menjalankan perintah bmctl upgrade cluster untuk mengupgrade cluster, beberapa pemeriksaan preflight akan berjalan. Proses upgrade akan berhenti jika pemeriksaan ini tidak berhasil. Sebaiknya identifikasi dan perbaiki masalah ini secara proaktif dengan perintah bmctl check cluster, bukan mengandalkan pemeriksaan preflight yang ada untuk melindungi cluster dari kemungkinan kerusakan.

Meninjau deployment workload pengguna

Ada dua area yang perlu dipertimbangkan untuk beban kerja pengguna: pengurasan dan kompatibilitas API.

Pengosongan workload

Beban kerja pengguna pada node terkuras selama upgrade. Jika beban kerja memiliki satu replika atau semua replika berada di node yang sama, pengosongan beban kerja dapat menyebabkan gangguan pada layanan yang berjalan di cluster. Jalankan workload Anda dengan beberapa replika. Nomor replika harus di atas jumlah node serentak.

Untuk menghindari upgrade yang macet, proses penghentian upgrade hingga 1,16 tidak mematuhi anggaran gangguan pod (PDB). Workload mungkin berjalan dalam status menurun, dan replika yang paling tidak dilayani 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 beban kerja ke versi yang kompatibel. Jika memungkinkan, tim engineer GKE Enterprise akan memberikan petunjuk untuk mengidentifikasi beban kerja menggunakan API yang tidak kompatibel, seperti menghapus Kubernetes API.

Jika Anda menggunakan Anthos Service Mesh, Config Sync, Pengontrol Kebijakan, dan Pengontrol Konfigurasi, atau komponen GKE Enterprise lainnya, periksa apakah versi yang diinstal kompatibel dengan GKE versi baru di Bare Metal. Untuk mengetahui informasi kompatibilitas versi komponen GKE Enterprise, lihat dukungan upgrade dan versi GKE Enterprise.

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 yang sangat tersedia.

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 dapat menyebabkan gangguan terkait upgrade, lihat catatan rilis.

Periksa status SELinux

Jika ingin mengaktifkan SELinux untuk mengamankan penampung, Anda harus memastikan bahwa SELinux diaktifkan dalam mode Enforced di semua mesin host. Mulai GKE pada rilis Bare Metal 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) dan CentOS. Jika SELinux dinonaktifkan di mesin host atau Anda tidak yakin, lihat Mengamankan container menggunakan SELinux untuk mengetahui petunjuk cara mengaktifkannya.

GKE di Bare Metal mendukung SELinux hanya di sistem RHEL dan CentOS.

Jangan ubah konfigurasi kepadatan Pod

GKE di Bare Metal 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 ada. Jangan mencoba mengubah konfigurasi kepadatan pod selama upgrade.

Memastikan bidang kontrol dan node load balancer tidak dalam mode pemeliharaan

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

Langkah selanjutnya