베어메탈용 GKE 관측 가능성 문제 해결

이 문서는 베어메탈용 GKE의 관측 가능성 문제 해결을 돕기 위해 작성되었습니다. 이러한 문제가 발생하면 제안된 해결 방법을 검토하세요.

추가 지원이 필요하면 Google 지원에 문의하세요.

Cloud 감사 로그가 수집되지 않음

클러스터 구성의 clusterOperations 섹션에 disableCloudAuditLogging 플래그가 설정되어 있지 않으면 Cloud 감사 로그는 기본적으로 사용 설정되어 있습니다.

Cloud 감사 로그가 사용 설정된 경우 로그가 수집되지 않는 가장 일반적인 이유는 권한 때문입니다. 이 시나리오에서는 Cloud 감사 로그 프록시 컨테이너에 권한 거부 오류 메시지가 표시됩니다.

Cloud 감사 로그 프록시 컨테이너는 모든 베어메탈용 GKE 클러스터에서 DaemonSet로 실행됩니다.

권한 오류가 표시되면 문제 해결 단계에 따라 권한 문제를 해결합니다.

kube-state-metrics 측정항목이 수집되지 않음

kube-state-metrics(KSM)는 클러스터에서 단일 복제본 배포로 실행되며 클러스터의 거의 모든 리소스에 대한 측정항목을 생성합니다. KSM 및 gke-metrics-agent가 동일한 노드에서 실행될 때는 모든 노드의 측정항목 에이전트 간에 중단 발생 위험이 더 큽니다.

KSM 측정항목 이름은 kube_pod_container_info와 같은 kube_<ResourceKind> 패턴을 따릅니다. kube_onpremusercluster_로 시작하는 측정항목은 KSM이 아닌 온프레미스 클러스터 컨트롤러에서 시작됩니다.

KSM 측정항목이 누락되었으면 다음 문제 해결 단계를 검토합니다.

  • Cloud Monitoring에서 kubernetes.io/anthos/container/... 같은 요약 API 측정항목을 사용하여 KSM의 CPU, 메모리, 재시작 횟수를 확인합니다 . 이는 KSM을 사용하는 별도의 파이프라인입니다. KSM 포드가 리소스 부족으로 제한되지 않는지 확인합니다.
    • 이러한 요약 API 측정항목을 KSM에 사용할 수 없으면 동일 노드의 gke-metrics-agent에 동일한 문제가 있을 수 있습니다.
  • 클러스터에서 KSM 포드와 KSM과 동일한 노드에 있는 gke-metrics-agent 포드의 상태 및 로그를 확인합니다.

kube-state-metrics 비정상 종료 루프

증상

Cloud Monitoring에서는 kube-state-metrics(KSM)의 측정항목을 사용할 수 없습니다.

원인

이 시나리오는 큰 클러스터 또는 리소스 양이 많은 클러스터에서 발생할 가능성이 더 높습니다. KSM은 단일 복제본 배포로 실행되며 포드, 배포, DaemonSet, ConfigMap, 보안 비밀, PersistentVolume과 같은 클러스터의 거의 모든 리소스를 나열합니다. 측정항목은 이러한 각 리소스 객체에 생성됩니다. 포드가 10,000개 넘는 클러스터와 같이 리소스에 많은 객체가 포함된 경우 KSM에 메모리 부족이 발생할 수 있습니다.

영향을 받는 버전

이 문제는 모든 버전의 베어메탈용 GKE에서 발생할 수 있습니다.

마지막 베어메탈용 GKE 버전 몇 개에서 기본 CPU 및 메모리 한도가 증가했으므로 이러한 리소스 문제의 발생 빈도가 줄어들 것입니다.

해결 방법

메모리 부족 문제 때문인지 확인하려면 다음 단계를 검토하세요.

  • kubectl describe pod 또는 kubectl get pod -o yaml을 사용하고 오류 상태 메시지를 확인합니다.
  • 메모리 소비와 KSM에 대한 사용 측정항목을 확인하고 시작하기 전 한도에 도달하는지 확인합니다.

메모리 부족 문제 때문인 경우 다음 해결 방법 중 하나를 사용합니다.

  • KSM의 메모리 요청 및 한도를 늘립니다.

    KSM의 CPU 및 메모리를 조정하려면 kube-state-metrics에 Stackdriver 커스텀 리소스의 resourceOverride를 사용합니다.

  • KSM에서 측정항목 수를 줄입니다.

    베어메탈용 GKE 1.13의 경우 KSM이 기본적으로 핵심 측정항목이라고 하는 소수의 측정항목만 노출합니다. 이 동작은 리소스 사용량이 이전 버전보다 적지만 동일한 절차에 따라 KSM 측정항목 수를 더 줄일 수 있음을 의미합니다.

    베어메탈용 GKE 1.13 이전 버전에서는 KSM이 기본 플래그를 사용합니다. 이 구성은 많은 수의 측정항목을 노출합니다.

gke-metrics-agent 비정상 종료 루프

kube-state-metrics가 있는 노드에서 gke-metrics-agent에 메모리 부족 문제만 발생하는 경우 많은 수의 kube-state-metrics 측정항목이 문제의 원인입니다. 이 문제를 완화하려면 이전 섹션에서 설명한 대로 stackdriver-operator를 축소하고 필요한 소수의 측정항목 집합을 노출하도록 KSM을 수정합니다. 클러스터가 베어메탈용 GKE 1.13으로 업그레이드된 후 기본적으로 KSM이 더 적은 수의 핵심 측정항목을 노출하는 경우 백업 stackdriver-operator를 조정해야 합니다.

메모리 부족 이벤트와 관련이 없는 문제는 gke-metric-agent의 포드 로그를 확인합니다. resourceAttrOverride 필드를 Stackdriver 커스텀 리소스에 추가하여 모든 gke-metrics-agent 포드에 맞게 CPU와 메모리를 조정할 수 있습니다.

stackdriver-metadata-agent 비정상 종료 루프

증상

Cloud Monitoring에서 측정항목을 필터링할 때 사용 가능한 시스템 메타데이터 라벨이 없습니다.

원인

stackdriver-metadata-agent 비정상 종료 루프의 가장 일반적인 원인은 메모리 부족 이벤트 때문입니다. 이 이벤트는 kube-state-metrics와 비슷합니다. stackdriver-metadata-agent는 모든 리소스를 나열하지는 않지만 포드, 배포, NetworkPolicy와 같은 관련 리소스 유형의 모든 객체를 나열합니다. 에이전트가 단일 복제본 배포로 실행되어 객체 수가 너무 큰 경우 메모리 부족 이벤트 위험이 증가합니다.

영향을 받는 버전

이 문제는 모든 버전의 베어메탈용 GKE에서 발생할 수 있습니다.

마지막 베어메탈용 GKE 버전 몇 개에서 기본 CPU 및 메모리 한도가 증가했으므로 이러한 리소스 문제의 발생 빈도가 줄어들 것입니다.

해결 방법

메모리 부족 문제 때문인지 확인하려면 다음 단계를 검토하세요.

  • kubectl describe pod 또는 kubectl get pod -o yaml을 사용하고 오류 상태 메시지를 확인합니다.
  • 메모리 소비와 stackdriver-metadata-agent에 대한 사용 측정항목을 확인하고 시작하기 전 한도에 도달하는지 확인합니다.
메모리 부족으로 인해 문제가 발생하는 것으로 확인되면 Stackdriver 커스텀 리소스의 resourceAttrOverride 필드에서 메모리 한도를 늘립니다.

metrics-server 비정상 종료 루프

증상

수평형 포드 자동 확장 처리 및 kubectl top가 클러스터에서 작동하지 않습니다.

원인 및 영향을 받는 버전

이 문제는 아주 자주 발생하지는 않지만 대규모 클러스터 또는 포드 밀도가 높은 클러스터에서 메모리 부족 오류로 인해 발생합니다.

이 문제는 모든 버전의 베어메탈용 GKE에서 발생할 수 있습니다.

해결 방법

측정항목 서버 리소스 한도를 늘립니다. 베어메탈용 GKE 버전 1.13 이상에서 metrics-server의 네임스페이스 및 해당 구성이 kube-system에서 gke-managed-metrics-server로 이동했습니다.

베어메탈용 GKE의 경우 클러스터 업데이트 또는 업그레이드 시 nanny 구성 편집이 취소됩니다. 구성 변경사항을 다시 적용해야 합니다. 이 제한사항을 해결하려면 metrics-server-operator를 축소하고 metrics-server 포드를 수동으로 변경합니다.

다음 단계

추가 지원이 필요하면 Google 지원에 문의하세요.