Memecahkan masalah pengelola pengontrol Kubernetes
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Halaman ini menunjukkan cara menyelesaikan masalah pada pengelola
pengontrol Kubernetes (kube-controller-manager) untuk Google Distributed Cloud.
Pemilihan pemimpin gagal
Error ini mungkin terjadi di cluster regional atau bidang kontrol yang direplikasi
saat kube-controller-manager (KCM) dimulai ulang secara tidak terduga. Mulai ulang ini mungkin
melibatkan penghentian sendiri atau dimulai ulang oleh kubelet. Log KCM mungkin
mencakup pesan leaderelection lost.
Skenario ini dapat terjadi saat pemimpin memeriksa apakah pemimpin masih aktif memimpin sebagai bagian dari health check KCM.
Jika pemimpin tidak lagi memimpin atau pemeriksaan sewa gagal, health check akan melaporkan bahwa pemimpin tidak responsif, dan pemimpin akan dimulai ulang.
Status pemilihan pemimpin dapat diambil dengan mendapatkan resource Lease dari
grup coordination.k8s.io:
Untuk melihat semua sewa, jalankan perintah kubectl berikut:
kubectl-nkube-systemgetlease
Untuk memeriksa status sewa tertentu, seperti lease/kube-controller-manager,
gunakan perintah kubectl describe berikut:
Di bagian Events, periksa peristiwa LeaderElection. Tinjau siapa yang mengambil alih kepemimpinan dan kapan hal itu terjadi. Output contoh berikut menunjukkan bahwa saat node pertama dimatikan secara manual, node kedua langsung mengambil alih kepemimpinan:
Anda juga dapat mengamati proses kehilangan dan mendapatkan kepemimpinan menggunakan
metrik kubernetes.io/anthos/leader_election_master_status yang dikelompokkan menurut name.
Proses pemilihan pemimpin hanya terjadi jika pemimpin saat ini gagal. Anda dapat
mengonfirmasi kegagalan dengan melihat metrik kubernetes.io/anthos/container/uptime dan
kubernetes.io/anthos/container/restart_count yang difilter menurut
container_namekube-controller-manager.
Jika Anda mengalami masalah proses pemilihan pemimpin yang berjalan atau gagal berulang kali, tinjau pertimbangan perbaikan berikut:
Jika KCM dimulai ulang setiap beberapa menit atau kurang, periksa log KCM untuk mengetahui permintaan yang gagal ke server API. Permintaan yang gagal menunjukkan masalah konektivitas antara komponen atau sebagian layanan kelebihan beban.
Jika pengelola pengontrol gagal berkomunikasi dengan server API terlalu
lama, perpanjangan akan gagal dan instance KCM akan kehilangan kepemimpinannya, meskipun
koneksi dipulihkan nanti.
Jika bidang kontrol direplikasi, pemimpin baru harus mengambil alih dengan lancar
tanpa periode nonaktif. Anda tidak perlu melakukan tindakan apa pun. Bidang kontrol cluster multicloud atau regional selalu direplikasi. Jangan mencoba menonaktifkan pemilihan pemimpin untuk bidang kontrol yang direplikasi. Anda tidak dapat mengaktifkan kembali pemilihan pemimpin tanpa periode nonaktif.
Langkah berikutnya
Jika Anda memerlukan bantuan tambahan, hubungi
Cloud Customer Care.
Anda juga dapat melihat bagian
Mendapatkan dukungan untuk mengetahui informasi selengkapnya tentang sumber dukungan, termasuk yang berikut:
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-04 UTC."],[],[],null,["This pages shows you how to resolve issues with the Kubernetes controller\nmanager (`kube-controller-manager`) for Google Distributed Cloud.\n\nLeader election lost\n\nThis error might be observed in a regional cluster or replicated control plane\nwhen `kube-controller-manager` (KCM) restarts unexpectedly. This restart might\ninvolve quitting itself or being restarted by `kubelet`. The KCM logs might\ninclude `leaderelection lost` messages.\n\nThis scenario can occur when the leader checks if it's still actively leading as\npart of the KCM health check.\n\nIf the leader is no longer leading or the lease check fails, the health check\nreports to be unhealthy, and the leader is restarted.\n\nThe leader election status can be retrieved by getting the `Lease` resources of\nthe `coordination.k8s.io` group:\n\n1. To see all leases, run the following `kubectl` command:\n\n kubectl -n kube-system get lease\n\n2. To check status of a given lease, such as `lease/kube-controller-manager`,\n use the following `kubectl describe` command:\n\n kubectl -n kube-system describe lease/kube-controller-manager\n\n Under the `Events` section, check for `LeaderElection` events. Review who\n takes the leadership and when that happens. The following example output shows\n that when the first node was manually shut down, the second instantaneously\n takes over the leadership: \n\n Events:\n Type Reason Age From Message\n ---- ------ ---- ---- -------\n Normal LeaderElection 26m kube-controller-manager control-plane_056a86ec-84c5-48b8-b58d-86f3fde2ecdd became leader\n Normal LeaderElection 5m20s kube-controller-manager control-plane2_b0475d49-7010-4f03-8a9d-34f82ed60cd4 became leader\n\n You can also observe the process of losing and gaining leadership by using the\n `kubernetes.io/anthos/leader_election_master_status` metric grouped by `name`.\n\nThe leader election process only happens if the current leader fails. You can\nconfirm the failure by looking at `kubernetes.io/anthos/container/uptime` and\n`kubernetes.io/anthos/container/restart_count` metrics filtered by a\n`container_name` of `kube-controller-manager`.\n\nIf you experience issues of the leader election process repeatedly running or\nfailing, review the following remediation considerations:\n\n- If KCM restarts every few minutes or less, check the KCM logs for failed requests to API server. Failed requests indicate connectivity issues between the components or part of the service is overloaded.\n- If the controller manager fails to communicate with the API server for too long, the renewal fails and the KCM instance loses its leadership, even if the connection is later restored.\n- If the control plane is replicated, the new leader should smoothly take over without downtime. No action is required. The control plane of a multi-cloud or regional cluster is always replicated. Don't attempt to disable leader election for a replicated control plane. You can't re-enable leader election without downtime.\n\nWhat's next\n\nIf you need additional assistance, reach out to\n\n[Cloud Customer Care](/support-hub).\nYou can also see\n[Getting support](/kubernetes-engine/distributed-cloud/bare-metal/docs/getting-support) for more information about support resources, including the following:\n\n- [Requirements](/kubernetes-engine/distributed-cloud/bare-metal/docs/getting-support#intro-support) for opening a support case.\n- [Tools](/kubernetes-engine/distributed-cloud/bare-metal/docs/getting-support#support-tools) to help you troubleshoot, such as your environment configuration, logs, and metrics.\n- Supported [components](/kubernetes-engine/distributed-cloud/bare-metal/docs/getting-support#what-we-support)."]]
