이 페이지에서는 베어메탈용 Google Distributed Cloud Virtual의 Kubernetes 컨트롤러 관리자(kube-controller-manager) 문제를 해결하는 방법을 설명합니다.
리더 선택 손실
이 오류는 kube-controller-manager(KCM)가 예기치 않게 다시 시작될 때 리전 클러스터나 복제된 제어 영역에서 관찰될 수 있습니다. 다시 시작하면 자체적으로 종료하거나 kubelet으로 다시 시작될 수 있습니다. KCM 로그에는 leaderelection lost 메시지가 포함될 수 있습니다.
이 시나리오는 리더가 KCM 상태 점검의 일환으로 여전히 적극적으로 주도하고 있는지 확인할 때 발생할 수 있습니다.
리더가 더 이상 선두에 있지 않거나 임대 확인이 실패하면 상태 점검에서 비정상을 보고하고 리더가 다시 시작됩니다.
coordination.k8s.io 그룹의 Lease 리소스를 가져와 리더 선택 상태를 검색할 수 있습니다.
모든 임대를 확인하려면 다음
kubectl명령어를 실행합니다.kubectl -n kube-system get leaselease/kube-controller-manager와 같이 지정된 임대 상태를 확인하려면 다음kubectl describe명령어를 사용합니다.kubectl -n kube-system describe lease/kube-controller-managerEvents섹션에서LeaderElection이벤트를 확인합니다. 누가 리더이고 언제 리더 역할을 수행하는지 검토합니다. 다음 출력 예시에서는 첫 번째 노드가 수동으로 종료되면 두 번째 노드가 즉시 리더십을 인계한다는 것을 보여줍니다.Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal LeaderElection 26m kube-controller-manager control-plane_056a86ec-84c5-48b8-b58d-86f3fde2ecdd became leader Normal LeaderElection 5m20s kube-controller-manager control-plane2_b0475d49-7010-4f03-8a9d-34f82ed60cd4 became leadername별로 그룹화된kubernetes.io/anthos/leader_election_master_status측정항목을 사용하여 리더십을 잃거나 얻는 프로세스를 관찰할 수도 있습니다.
리더 선택 프로세스는 현재 리더가 실패한 경우에만 발생합니다. kube-controller-manager의 container_name별로 필터링된 kubernetes.io/anthos/container/uptime 및 kubernetes.io/anthos/container/restart_count 측정항목을 확인하여 실패를 확인할 수 있습니다.
리더 선택 프로세스가 반복적으로 실행되거나 실패하는 문제가 발생하는 경우 다음 해결 고려 사항을 검토합니다.
- KCM이 몇 분 이내에 다시 시작되면 KCM 로그에서 API 서버에 대한 실패한 요청을 확인합니다. 실패한 요청은 구성요소 또는 서비스 일부 간의 연결 문제가 과부하임을 나타냅니다.
- 컨트롤러 관리자가 너무 오랫동안 API 서버와 통신할 수 없으면 갱신이 실패하고 나중에 연결이 복원되더라도 KCM 인스턴스에서 리더십을 상실합니다.
- 제어 영역이 복제되면 새 리더가 다운타임 없이 원활하게 인계됩니다. 별도의 조치가 필요하지 않습니다. 멀티 클라우드 또는 리전 클러스터의 제어 영역은 항상 복제됩니다. 복제된 제어 영역에 대해 리더 선택을 중지하려고 시도하지 마세요. 다운타임 없이 리더 선택을 다시 사용 설정할 수 없습니다.