Halaman ini menunjukkan cara menyelesaikan masalah upgrade cluster Google Kubernetes Engine (GKE).
Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.Masalah: kube-apiserver tidak responsif setelah upgrade bidang kontrol
Masalah berikut terjadi saat Anda memulai upgrade bidang kontrol manual versi GKE cluster. Beberapa webhook akses yang di-deploy oleh pengguna dapat memblokir komponen sistem sehingga tidak dapat membuat peran RBAC permisif yang diperlukan supaya berfungsi dengan benar. Selama upgrade bidang kontrol, Google Cloud akan membuat ulang komponen server Kubernetes API (kube-apiserver). Jika webhook memblokir peran RBAC untuk komponen server API, server API tidak akan dimulai dan upgrade cluster tidak akan selesai.
Meskipun webhook berfungsi dengan benar, webhook dapat menyebabkan upgrade cluster gagal karena webhook mungkin tidak dapat dijangkau dari bidang kontrol yang baru dibuat.
Pesan error di gcloud CLI mirip dengan yang berikut ini:
FAILED: All cluster resources were brought up, but: component "KubeApiserverReady" from endpoint "readyz of kube apiserver is not successful" is unhealthy.
Untuk mengidentifikasi webhook yang gagal, periksa log audit GKE untuk panggilan RBAC dengan informasi berikut:
protoPayload.resourceName="RBAC_RULE"
protoPayload.authenticationInfo.principalEmail="system:apiserver"
RBAC_RULE
adalah nama lengkap peran RBAC, seperti
rbac.authorization.k8s.io/v1/clusterroles/system:controller:horizontal-pod-autoscaler
.
Nama webhook yang gagal ditampilkan di log dengan format berikut:
admission webhook WEBHOOK_NAME denied the request
Untuk mengatasi masalah ini, coba langkah-langkah berikut:
- Sesuaikan batasan untuk memungkinkan pembuatan dan pembaruan ClusterRole yang memiliki
awalan
system:
. - Sesuaikan webhook Anda agar tidak menghalangi permintaan untuk membuat dan memperbarui peran RBAC sistem.
- Nonaktifkan webhook.
Mengapa ini terjadi?
Kubernetes akan otomatis merekonsiliasi{track-name="k8sLink" track-type="troubleshooting"} peran RBAC sistem default dengan kebijakan default dalam versi minor terbaru. Kebijakan default untuk peran sistem terkadang berubah pada versi Kubernetes baru.
Untuk melakukan rekonsiliasi ini, GKE membuat atau mengupdate ClusterRoles dan ClusterRoleBindings di cluster. Jika Anda memiliki webhook yang menghalangi dan menolak permintaan pembuatan atau update karena cakupan izin yang digunakan kebijakan RBAC default, server API tidak dapat berfungsi pada versi minor yang baru.
Masalah: Workload dikeluarkan setelah upgrade cluster Standard
Workload Anda mungkin berisiko dikeluarkan setelah upgrade cluster jika semua hal berikut terpenuhi:
- Workload sistem memerlukan lebih banyak ruang saat bidang kontrol cluster menjalankan versi GKE baru.
- Node yang ada tidak memiliki resource yang cukup untuk menjalankan workload sistem baru dan workload yang ada.
- Autoscaler cluster dinonaktifkan untuk cluster.
Untuk mengatasi masalah ini, coba langkah berikut:
- Mengaktifkan penskalaan otomatis untuk node pool yang ada
- Mengaktifkan penyediaan otomatis node
- Membuat node pool baru
- Meningkatkan skala node pool yang ada
Masalah: Versi node tidak kompatibel dengan versi panel kontrol
Periksa versi Kubernetes yang dijalankan oleh panel kontrol cluster Anda, lalu periksa versi Kubernetes yang dijalankan oleh node pool cluster Anda. Jika salah satu node pool cluster memiliki lebih dari dua versi minor yang lebih lama daripada panel kontrol, hal ini mungkin menyebabkan masalah pada cluster Anda.
Secara berkala, tim GKE melakukan upgrade pada control plane cluster untuk Anda. Bidang kontrol diupgrade ke Kubernetes versi stabil yang lebih baru. Secara default, node cluster telah mengaktifkan upgrade otomatis, dan sebaiknya Anda tidak menonaktifkannya.
Jika upgrade otomatis dinonaktifkan untuk node cluster, dan Anda tidak secara manual mengupgrade versi node pool ke versi yang kompatibel dengan panel kontrol, panel kontrol Anda pada akhirnya akan tidak kompatibel dengan node karena panel kontrol secara otomatis diupgrade dari waktu ke waktu. Inkompatibilitas antara panel kontrol cluster Anda dan node dapat menyebabkan masalah yang tidak terduga.
Kebijakan dukungan ketidaksesuaian versi dan versi Kubernetes menegaskan bahwa panel kontrol kompatibel dengan node hingga dua versi minor yang lebih lama dari panel kontrol. Misalnya, panel kontrol Kubernetes 1.19 kompatibel dengan node Kubernetes 1.19, 1.18, dan 1.17. Untuk menyelesaikan masalah ini, upgrade versi node pool secara manual ke versi yang kompatibel dengan panel kontrol.
Jika Anda mengkhawatirkan bahwa proses upgrade dapat menyebabkan gangguan pada workload yang berjalan pada node yang terpengaruh, selesaikan langkah-langkah berikut untuk memigrasikan workload ke node pool baru:
- Buat node pool baru dengan versi yang kompatibel.
- Menghalangi node dari node pool yang ada.
- Opsional: Perbarui beban kerja yang berjalan di node pool yang ada untuk menambahkan nodeSelector untuk label
cloud.google.com/gke-nodepool:NEW_NODE_POOL_NAME
, denganNEW_NODE_POOL_NAME
adalah nama node pool baru. Hal ini memastikan bahwa GKE menempatkan workload tersebut di node dalam node pool baru. - Drain node pool yang ada.
- Pastikan workload berhasil berjalan di node pool baru. Jika sudah, Anda dapat menghapus node pool lama. Jika Anda melihat gangguan workload, jadwalkan ulang workload di node yang ada dengan membatalkan pembatasan node di node pool yang ada dan menghabiskan node baru. Pecahkan masalah dan coba lagi.
Masalah: Pod terjebak dalam status tertunda setelah mengonfigurasi Node Allocatable
Setelah mengonfigurasi Node Allocatable dan melakukan upgrade versi node, Anda mungkin melihat bahwa Pod yang berjalan berubah menjadi tertunda.
Jika Pod tertunda setelah upgrade, sebaiknya lakukan hal berikut:
Pastikan permintaan CPU dan Memori untuk Pod Anda tidak melebihi penggunaan puncaknya. Dengan GKE yang mencadangkan CPU dan memori untuk overhead, Pod tidak dapat meminta resource ini. Pod yang meminta CPU atau memori yang melebihi penggunaannya akan mencegah Pod lain meminta resource ini, dan mungkin membuat cluster kurang dimanfaatkan. Untuk mengetahui informasi selengkapnya, silakan membaca Cara Pod dengan permintaan resource dijadwalkan.
Pertimbangkan untuk mengubah ukuran cluster Anda. Untuk mengetahui petunjuknya, lihat Mengubah ukuran cluster.
Kembalikan perubahan ini dengan mendowngrade cluster Anda. Untuk mengetahui petunjuknya, lihat Mengupgrade cluster atau node pool secara manual.
- Konfigurasikan cluster Anda untuk mengirim metrik scheduler Kubernetes ke Cloud Monitoring dan melihat metrik scheduler.
Langkah selanjutnya
Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.