Praktik terbaik untuk GKE pada upgrade cluster VMware

Dokumen ini menjelaskan praktik terbaik dan pertimbangan untuk mengupgrade GKE di VMware. 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

Agar proses upgrade berjalan selancar mungkin, tinjau dan selesaikan pemeriksaan berikut sebelum Anda mulai mengupgrade cluster:

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

Secara default, semua kumpulan node diupgrade secara paralel, tetapi di dalam setiap kumpulan node, node akan diupgrade secara berurutan. Jadi, total waktu untuk upgrade bergantung pada jumlah node di kumpulan node terbesar. Untuk menghitung perkiraan kasar waktu upgrade, gunakan 15 menit * jumlah node di kumpulan node terbesar. Misalnya, jika Anda memiliki 10 node di kumpulan terbesar, total waktu upgrade akan menjadi sekitar 150 menit.

Pada versi 1.28 dan yang lebih baru, Anda dapat mempercepat upgrade dengan menetapkan nilai maxSurge untuk masing-masing kumpulan node.

Mencadangkan cluster admin dan pengguna

Sebelum memulai upgrade, cadangkan cluster pengguna dan admin Anda.

Cadangan cluster pengguna adalah snapshot dari penyimpanan etcd cluster pengguna. Penyimpanan etcd berisi semua objek Kubernetes dan objek kustom yang diperlukan untuk mengelola status cluster. Snapshot berisi data yang diperlukan untuk membuat ulang komponen dan workload cluster. Untuk mengetahui informasi selengkapnya, lihat cara mencadangkan cluster pengguna.

Dengan GKE di VMware versi 1.8 dan yang lebih baru, Anda dapat menyiapkan pencadangan otomatis dengan clusterBackup.datastore di file konfigurasi cluster admin. Untuk mengaktifkan fitur ini di cluster yang ada, edit file konfigurasi cluster admin dan tambahkan kolom clusterBackup.datastore, lalu jalankan gkectl update admin.

Setelah clusterBackup.datastore diaktifkan, cluster admin Anda akan otomatis dicadangkan di etcd pada datastore vSphere yang dikonfigurasi. Proses pencadangan ini berulang setiap kali ada perubahan pada cluster admin. Saat Anda memulai upgrade cluster, tugas pencadangan akan berjalan sebelum mengupgrade cluster.

Untuk memulihkan cluster admin dari cadangannya jika Anda mengalami masalah, lihat Mencadangkan dan memulihkan cluster admin dengan gkectl.

Meninjau penggunaan PodDisruptionBudgets

Di Kubernetes, PodDisruptionBudgets (PDB) dapat membantu mencegah periode nonaktif atau pemadaman aplikasi yang tidak diinginkan. PDB menginstruksikan penjadwal untuk selalu menjaga sejumlah Pod tetap berjalan, sementara Pod lain mungkin gagal. Perilaku ini adalah cara yang berguna untuk menyediakan ketersediaan aplikasi.

  1. Untuk memeriksa PDB yang dikonfigurasi di cluster Anda, gunakan perintah kubectl get pdb:

    kubectl get pdb -A --kubeconfig KUBECONFIG

    Ganti KUBECONFIG dengan nama file kubeconfig Anda.

    Contoh output berikut menunjukkan PDB bernama istio-ingress, istiod, dan kube-dns:

    NAMESPACE     NAME            MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
gke-system    istio-ingress   1               N/A               1                     16d
gke-system    istiod          1               N/A               1                     16d
kube-system   kube-dns        1               N/A               1                     16d

Dalam tabel sebelumnya, setiap PDB menentukan bahwa setidaknya satu Pod harus selalu tersedia. Ketersediaan ini menjadi sangat penting selama upgrade ketika node dihabiskan.

Memeriksa PDB yang tidak dapat dipenuhi. Misalnya, Anda dapat menetapkan ketersediaan minimum 1, saat Deployment hanya menampilkan 1 replika. Dalam contoh ini, operasi pengosongan terganggu karena PDB tidak dapat dipenuhi oleh pengontrol resource.

Untuk memastikan PDB tidak mengganggu prosedur upgrade, periksa semua PDB di cluster tertentu sebelum memulai upgrade. Anda mungkin perlu berkoordinasi dengan tim pengembangan dan pemilik aplikasi untuk mengubah atau menonaktifkan PDB sementara waktu selama upgrade cluster.

GKE di VMware menjalankan pemeriksaan preflight selama proses upgrade untuk memperingatkan tentang PDB. Namun, Anda juga harus memverifikasi PDB secara manual untuk memastikan pengalaman upgrade yang lancar. Untuk mempelajari PDB lebih lanjut, lihat Menentukan Anggaran Gangguan untuk Aplikasi.

Meninjau alamat IP yang tersedia

Pertimbangan alamat IP berikut berlaku selama upgrade cluster:

  • Proses upgrade cluster akan membuat node baru dan menghabiskan resource sebelum menghapus node lama. Sebaiknya selalu miliki alamat IP N+1 untuk admin atau cluster pengguna, dengan N adalah jumlah node dalam cluster.
  • Saat menggunakan alamat IP statis, alamat IP yang diperlukan harus tercantum dalam file blok IP.
  • Jika Anda menggunakan DHCP, pastikan bahwa VM baru bisa mendapatkan sewa IP tambahan di subnet yang diinginkan selama upgrade.
    • Jika Anda perlu menambahkan alamat IP, perbarui file blok IP, lalu jalankan perintah gkectl update. Untuk mengetahui informasi selengkapnya, lihat Merencanakan alamat IP.
  • Jika Anda menggunakan alamat IP statis dan ingin mempercepat proses upgrade cluster pengguna, cantumkan alamat IP yang cukup dalam file blok IP Anda sehingga setiap kumpulan node dapat memiliki alamat IP tambahan. Pendekatan ini memungkinkan proses mempercepat prosedur penambahan dan penghapusan VM seperti yang dilakukan pada basis per kumpulan node.
    • Meskipun pendekatan ini adalah opsi yang bagus untuk mempercepat upgrade cluster pengguna, pertimbangkan ketersediaan resource dan performa lingkungan vSphere Anda sebelum melanjutkan.
  • Jika hanya ada satu IP cadangan untuk seluruh cluster pengguna, batasan ini akan memperlambat proses upgrade menjadi hanya satu VM pada satu waktu, meskipun beberapa kumpulan node digunakan.

Memeriksa pemanfaatan cluster

Pastikan Pod dapat dievakuasi saat node habis dan ada resource yang cukup di cluster yang diupgrade untuk mengelola upgrade. Untuk memeriksa penggunaan resource cluster saat ini, Anda dapat menggunakan dasbor kustom di Kemampuan Observasi Google Cloud, atau langsung di cluster menggunakan perintah seperti kubectl top nodes.

Perintah yang Anda jalankan terhadap cluster akan menampilkan snapshot penggunaan resource cluster saat ini. 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 dan kasus penggunaan yang sedang 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 gratis di vSphere sebelum 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.

Untuk mengetahui informasi selengkapnya, lihat layanan apa saja yang terpengaruh selama upgrade cluster.

Memeriksa pemanfaatan vSphere

Pastikan ada cukup resource pada infrastruktur vSphere yang mendasarinya. Untuk memeriksa penggunaan resource ini, pilih cluster di vCenter dan tinjau tab Ringkasan.

Tab ringkasan menunjukkan konsumsi memori, CPU, dan penyimpanan secara keseluruhan di seluruh cluster. Karena upgrade GKE pada VMware memerlukan resource tambahan, Anda juga harus memeriksa apakah cluster dapat menangani permintaan resource tambahan ini.

Sebagai aturan umum, cluster vSphere Anda harus dapat mendukung resource tambahan berikut:

  • +1 VM per upgrade cluster admin
  • +1 VM per kumpulan node per upgrade cluster pengguna

Misalnya, anggaplah cluster pengguna memiliki 3 kumpulan node dengan setiap kumpulan node memiliki node yang menggunakan 8 vCPU dan RAM 32 GB atau lebih. Karena upgrade terjadi secara paralel untuk 3 kumpulan node secara default, prosedur upgrade akan menggunakan resource tambahan berikut untuk 3 node lonjakan tambahan:

  • 24 vCPU
  • RAM 256 GB
  • Kapasitas disk VM + 256 GB vSwap

Proses upgrade akan membuat VM menggunakan operasi clone vSphere. Meng-clone beberapa VM dari template dapat menimbulkan tekanan pada sistem penyimpanan yang mendasarinya dalam bentuk peningkatan operasi I/O. Upgrade dapat sangat melambat jika subsistem penyimpanan yang mendasarinya tidak mampu memberikan performa yang memadai selama upgrade.

Meskipun vSphere didesain untuk penggunaan resource secara bersamaan dan memiliki mekanisme untuk menyediakan resource, meskipun jika diberikan secara berlebihan, kami sangat menyarankan untuk tidak melakukan overcommit memori VM. Overcommit memori dapat menyebabkan dampak performa yang serius, yang memengaruhi seluruh cluster karena vSphere menyebabkan "RAM yang hilang" karena menukar halaman ke datastore. Perilaku ini dapat menyebabkan masalah selama upgrade cluster, dan menyebabkan dampak performa pada VM lain yang berjalan di cluster vSphere.

Jika resource yang tersedia hampir habis, matikan VM yang tidak diperlukan untuk membantu memenuhi persyaratan tambahan ini dan mencegah potensi performa.

Memeriksa kondisi dan konfigurasi cluster

Jalankan alat berikut di semua cluster sebelum upgrade:

  • Perintah gkectl diagnose: gkectl diagnose memastikan semua cluster sehat. Perintah ini menjalankan pemeriksaan lanjutan, misalnya untuk mengidentifikasi node yang tidak dikonfigurasi dengan benar, atau yang memiliki Pod yang berada dalam status macet.

  • Alat pra-upgrade: selain memeriksa kondisi dan konfigurasi cluster, alat pra-upgrade akan memeriksa potensi masalah umum yang dapat terjadi selama upgrade cluster.

Meskipun perintah gkectl upgrade menjalankan pemeriksaan preflight dan menghentikan proses upgrade jika pemeriksaan ini tidak berhasil, pemeriksaan preflight ada untuk melindungi cluster dari kemungkinan kerusakan. Sebaiknya gunakan alat untuk mengidentifikasi dan memperbaiki masalah sebelum upgrade, bukan mengandalkan pemeriksaan preflight.

Jika perintah gkectl diagnose menampilkan peringatan Cluster unhealthy, perbaiki masalah sebelum Anda mencoba melakukan upgrade.

Untuk informasi selengkapnya, lihat Mendiagnosis masalah cluster.

Menggunakan Deployment untuk meminimalkan gangguan aplikasi

Karena node perlu dihabiskan selama update, upgrade cluster dapat menyebabkan gangguan aplikasi. Mengosongkan node berarti semua Pod yang berjalan harus dinonaktifkan dan dimulai ulang pada node yang tersisa dalam cluster.

Jika memungkinkan, aplikasi Anda sebaiknya menggunakan Deployment. Dengan pendekatan ini, aplikasi didesain untuk menangani gangguan. Dampak apa pun harus minimal untuk Deployment yang memiliki beberapa replika. Anda masih dapat mengupgrade cluster jika aplikasi tidak menggunakan Deployment.

Ada juga aturan untuk Deployment yang memastikan bahwa sejumlah replika selalu berjalan. Aturan ini disebut PodDisruptionBudgets (PDB). Dengan PDB, Anda dapat membatasi gangguan pada beban kerja saat Pod-nya harus dijadwalkan ulang karena alasan tertentu, seperti upgrade atau pemeliharaan pada node cluster, dan hal ini penting untuk diperiksa sebelum upgrade.

Menggunakan pasangan load balancer dengan ketersediaan tinggi

Jika Anda menggunakan Seesaw sebagai load balancer di cluster, load balancer akan otomatis diupgrade saat Anda mengupgrade cluster. Upgrade ini dapat menyebabkan gangguan layanan. Untuk mengurangi dampak upgrade dan kegagalan load balancer, Anda dapat menggunakan pasangan ketersediaan tinggi (pasangan HA). Dalam konfigurasi ini, sistem membuat dan mengonfigurasi dua VM load balancer, sehingga failover terhadap peer lainnya dapat terjadi.

Untuk meningkatkan ketersediaan layanan (yaitu, ke server Kubernetes API), sebaiknya selalu gunakan pasangan HA di depan cluster admin. Untuk mempelajari Seesaw dan konfigurasi HA-nya lebih lanjut, lihat Load balancing paket dengan Seesaw.

Untuk mencegah gangguan layanan selama upgrade dengan pasangan HA, cluster akan memulai failover sebelum membuat VM load balancer baru. Jika cluster pengguna hanya menggunakan satu instance load balancer, gangguan layanan akan terjadi hingga upgrade untuk load balancer selesai.

Sebaiknya Anda memiliki pasangan load balancer dengan ketersediaan tinggi (HA) jika cluster pengguna itu sendiri juga dikonfigurasi agar memiliki ketersediaan tinggi. Rangkaian praktik terbaik ini mengasumsikan bahwa cluster pengguna dengan ketersediaan tinggi (HA) menggunakan pasangan load balancer dengan ketersediaan tinggi (HA).

Jika GKE di VMware versi 1.11 atau 1.12 menggunakan MetalLB sebagai load balancer yang dipaketkan, penyiapan pra-upgrade tidak diperlukan. Load balancer diupgrade selama proses upgrade cluster.

Menentukan cara mengupgrade setiap cluster pengguna

Pada versi 1.14 dan yang lebih baru, Anda dapat memilih untuk mengupgrade cluster pengguna secara keseluruhan (artinya, Anda dapat mengupgrade bidang kontrol dan semua kumpulan node dalam cluster), atau Anda dapat mengupgrade bidang kontrol cluster pengguna dan membiarkan kumpulan node tetap pada versi saat ini. Untuk mengetahui informasi tentang alasan mengapa Anda perlu mengupgrade bidang kontrol secara terpisah, lihat Upgrade cluster pengguna.

Dalam lingkungan multi-cluster, lacak cluster pengguna mana yang telah diupgrade dan catat nomor versinya. Jika Anda memutuskan untuk mengupgrade bidang kontrol dan kumpulan node secara terpisah, catat versi bidang kontrol dan setiap kumpulan node di setiap cluster.

Memeriksa versi cluster pengguna dan admin

Gkectl

  • Untuk memeriksa versi cluster pengguna:

    gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Ganti ADMIN_CLUSTER_KUBECONFIG dengan jalur file kubeconfig untuk cluster admin Anda.

  • Untuk memeriksa versi cluster admin:

    gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

gcloud CLI

Untuk cluster yang terdaftar di GKE On-Prem API, Anda dapat menggunakan gcloud CLI untuk mendapatkan versi cluster pengguna, node pool di cluster pengguna, dan cluster admin.

  1. Pastikan Anda memiliki gcloud CLI versi terbaru. Update komponen gcloud CLI, jika diperlukan:

    gcloud components update

  2. Jalankan perintah berikut untuk memeriksa versi:

  • Untuk memeriksa versi cluster pengguna:

    gcloud container vmware clusters list \
    --project=PROJECT_ID \
    --location=-

    Ganti PROJECT_ID Project ID project host armada Anda.

    Jika Anda menetapkan --location=-, artinya Anda mencantumkan semua cluster di semua region. Jika Anda perlu menentukan cakupan dalam daftar, tetapkan --location ke region yang Anda tentukan saat mendaftarkan cluster.

    Output perintah ini mencakup versi cluster.

  • Untuk memeriksa versi cluster admin:

    gcloud container vmware admin-clusters list \
    --project=PROJECT_ID \
    --location=-

Periksa versi node cluster:

Anda dapat menggunakan kubectl untuk mendapatkan versi node cluster, tetapi kubectl akan menampilkan versi Kubernetes. Untuk mendapatkan GKE pada versi VMware yang sesuai untuk versi Kubernetes, lihat Histori versi.

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Ganti USER_CLUSTER_KUBECONFIG dengan jalur file kubeconfig untuk cluster pengguna Anda.

Periksa apakah sertifikat CA perlu dirotasi

Selama upgrade, sertifikat leaf akan dirotasi, tetapi sertifikat CA tidak. Anda harus merotasi sertifikat CA secara manual setidaknya sekali setiap lima tahun. Untuk informasi selengkapnya, lihat Merotasi otoritas sertifikat cluster pengguna dan Merotasi sertifikat CA cluster admin.

Perbedaan berbagai jenis cluster

Ada dua jenis cluster yang berbeda:

  • Cluster pengguna
  • Cluster admin

Bergantung pada cara Anda membuat cluster pengguna, cluster mungkin berisi node pekerja dan node bidang kontrol (Controlplane V2) atau hanya node pekerja (kubeception). Dengan kubeception, bidang kontrol untuk cluster pengguna berjalan pada satu atau beberapa node dalam cluster admin. Pada kedua kasus ini, pada versi 1.14 dan yang lebih baru, Anda dapat mengupgrade bidang kontrol cluster pengguna secara terpisah dari kumpulan node yang menjalankan beban kerja Anda.

Perbedaan efek cluster pengguna versus upgrade cluster admin

Prosedur upgrade GKE di VMware melibatkan proses pengurasan node yang menghapus semua Pod dari node. Proses ini akan membuat VM baru untuk setiap node pekerja yang dikuras dan menambahkannya ke cluster. Node pekerja yang telah dikosongkan kemudian dihapus dari inventaris VMware. Selama proses ini, beban kerja apa pun yang berjalan pada node ini akan dihentikan dan dimulai ulang pada node lain yang tersedia di cluster.

Bergantung pada arsitektur beban kerja yang dipilih, prosedur ini mungkin berdampak pada ketersediaan aplikasi. Untuk menghindari terlalu banyak beban pada kemampuan resource cluster, GKE di VMware mengupgrade satu node pada satu waktu.

Gangguan cluster pengguna

Tabel berikut menjelaskan dampak upgrade cluster pengguna yang diterapkan:

Fungsi Cluster admin Cluster pengguna non-HA Cluster pengguna dengan ketersediaan tinggi (HA)
Akses Kubernetes API Tidak terpengaruh Tidak terpengaruh Tidak terpengaruh
Workload pengguna Tidak terpengaruh Tidak terpengaruh Tidak terpengaruh
Anggaran Gangguan Pod* Tidak terpengaruh Tidak terpengaruh Tidak terpengaruh
Node bidang kontrol Tidak terpengaruh Terpengaruh Tidak terpengaruh
Autoscaler pod (VMware) Tidak terpengaruh Tidak terpengaruh Tidak terpengaruh
Perbaikan otomatis Tidak terpengaruh Tidak terpengaruh Tidak terpengaruh
Penskalaan otomatis node (VMware) Tidak terpengaruh Tidak terpengaruh Tidak terpengaruh
Penskalaan otomatis Pod horizontal Terpengaruh Terpengaruh Tidak terpengaruh
  • * : PDB bisa mengakibatkan kegagalan atau penghentian upgrade.
  • Terpengaruh: gangguan layanan selama upgrade akan terlihat hingga upgrade selesai.
  • Tidak terpengaruh: gangguan layanan dapat terjadi dalam waktu yang sangat singkat, tetapi hampir tidak terlihat.

Node bidang kontrol cluster pengguna, baik yang berjalan di cluster admin (kubeception) maupun di cluster pengguna itu sendiri (Controlplane V2), tidak menjalankan beban kerja pengguna apa pun. Selama upgrade, node bidang kontrol ini dikosongkan, lalu diupdate sebagaimana mestinya.

Dalam lingkungan dengan bidang kontrol ketersediaan tinggi (HA), mengupgrade bidang kontrol cluster pengguna tidak akan mengganggu beban kerja pengguna. Dalam lingkungan dengan ketersediaan tinggi (HA), mengupgrade cluster admin tidak mengganggu beban kerja pengguna. Untuk cluster pengguna yang menggunakan Controlplane V2, mengupgrade bidang kontrol saja tidak akan mengganggu beban kerja pengguna.

Selama upgrade di lingkungan bidang kontrol non-HA, bidang kontrol tidak dapat mengontrol tindakan penskalaan, pemulihan, atau deployment Pod. Selama gangguan singkat pada bidang kontrol selama upgrade, beban kerja pengguna dapat terpengaruh jika berada dalam status penskalaan, deployment, atau pemulihan. Artinya, peluncuran akan gagal selama upgrade di lingkungan non-HA.

Untuk meningkatkan ketersediaan dan mengurangi gangguan cluster pengguna produksi selama upgrade, sebaiknya gunakan tiga node bidang kontrol (mode ketersediaan tinggi).

Gangguan cluster admin

Tabel berikut menjelaskan dampak upgrade cluster admin yang diterapkan:

Fungsi Cluster admin Cluster pengguna non-HA Cluster pengguna dengan ketersediaan tinggi (HA)
Akses Kubernetes API Terpengaruh Terpengaruh Tidak terpengaruh
Workload pengguna Tidak terpengaruh Tidak terpengaruh Tidak terpengaruh
Node bidang kontrol Terpengaruh Terpengaruh Tidak terpengaruh
Autoscaler Pod Terpengaruh Terpengaruh Tidak terpengaruh
Perbaikan Otomatis Terpengaruh Terpengaruh Tidak terpengaruh
Penskalaan otomatis node Terpengaruh Terpengaruh Tidak terpengaruh
Penskalaan otomatis Pod horizontal Terpengaruh Terpengaruh Tidak terpengaruh
  • Terpengaruh: gangguan layanan selama upgrade akan terlihat hingga upgrade selesai.
  • Tidak terpengaruh: gangguan layanan dapat terjadi dalam waktu yang sangat singkat, tetapi hampir tidak terlihat.

Langkah selanjutnya