시스템 측정항목 문제 해결

Autopilot Standard

---

이 페이지에서는 Google Kubernetes Engine(GKE) 클러스터에서 시스템 측정항목 관련 문제를 해결하는 방법을 보여줍니다.

추가 지원이 필요하면 Cloud Customer Care에 문의하세요.

클러스터의 측정항목이 Cloud Monitoring에 표시되지 않음

프로젝트에서 Monitoring API와 Logging API를 사용 설정했는지 확인합니다. Google Cloud 콘솔의 Cloud Monitoring 개요에서 프로젝트를 볼 수 있는지도 확인해야 합니다.

문제가 계속되면 다음과 같은 가능한 원인을 확인하세요.

• 클러스터에서 모니터링을 사용 설정했나요?

  기본적으로 Google Cloud 콘솔과 Google Cloud CLI에서 생성된 클러스터에는 모니터링이 사용 설정되지만 다음 명령어를 실행하거나 Google Cloud 콘솔에서 클러스터 세부정보를 클릭하여 사용 설정 여부를 확인할 수 있습니다.

  gcloud container clusters describe CLUSTER_NAME
  

  이 명령어의 출력에는 다음 예시와 같이 monitoringConfig 섹션의 enableComponents 목록에 있는 SYSTEM_COMPONENTS가 포함됩니다.

  monitoringConfig:
    componentConfig:
      enableComponents:
      - SYSTEM_COMPONENTS
  

  모니터링이 사용 설정되어 있지 않으면 다음 명령어를 실행하여 사용 설정합니다.

  gcloud container clusters update CLUSTER_NAME --monitoring=SYSTEM
  

• 클러스터가 만들어진 지 또는 모니터링이 사용 설정된 지 얼마나 되었나요?

  새 클러스터의 측정항목이 Cloud Monitoring에 표시되는 데 최대 1시간이 걸릴 수 있습니다.

• 클러스터에서 실행되는 heapster 또는 gke-metrics-agent(OpenTelemetry Collector)가 kube-system 네임스페이스에 있나요?

  클러스터에 리소스가 부족하므로 이 Pod가 워크로드를 예약하지 못할 수 있습니다. kubectl get pods --namespace=kube-system을 실행하고 이름에 heapster 또는 gke-metrics-agent가 있는 Pod를 찾아 Heapster 또는 OpenTelemetry가 실행 중인지 확인합니다.

• 클러스터의 컨트롤 플레인이 노드와 통신할 수 있나요?

  Cloud Monitoring은 이 통신을 사용합니다. 다음 명령어를 실행하여 컨트롤 플레인이 노드와 통신하는지 확인할 수 있습니다.

  kubectl logs POD_NAME
  

  이 명령어가 오류를 반환하면 SSH 터널이 문제의 원인일 수 있습니다. 문제 해결 단계는 SSH 문제 해결을 참조하세요.

측정항목 에이전트에 충분한 메모리가 있는지 확인

위의 문제 해결 단계를 시도했는데도 측정항목이 계속 표시되지 않으면 측정항목 에이전트에 메모리가 부족한 것일 수 있습니다.

대부분의 경우 GKE 측정항목 에이전트에 대한 기본 리소스 할당만으로 충분합니다. 하지만 DaemonSet가 반복적으로 비정상 종료되는 경우 다음 안내에 따라 종료 이유를 확인할 수 있습니다.

1. GKE 측정항목 에이전트 포드의 이름을 가져옵니다.

   kubectl get pods -n kube-system -l component=gke-metrics-agent
   

2. 상태가 CrashLoopBackOff인 포드를 찾습니다.

   출력은 다음과 비슷합니다.

   NAME                    READY STATUS           RESTARTS AGE
   gke-metrics-agent-5857x 0/1   CrashLoopBackOff 6        12m
   

3. 상태가 CrashLoopBackOff인 포드를 설명합니다.

   kubectl describe pod POD_NAME -n kube-system
   

   POD_NAME을 이전 단계의 포드 이름으로 바꿉니다.

   포드의 종료 이유가 OOMKilled인 경우 에이전트에 추가 메모리가 필요합니다.

   출력은 다음과 비슷합니다.

     containerStatuses:
     ...
     lastState:
       terminated:
         ...
         exitCode: 1
         finishedAt: "2021-11-22T23:36:32Z"
         reason: OOMKilled
         startedAt: "2021-11-22T23:35:54Z"
   

4. 실패한 측정항목 에이전트가 있는 노드에 노드 라벨을 추가합니다. 영구 또는 임시 노드 라벨을 사용할 수 있습니다. 20MB를 더 추가하는 것이 좋습니다. 에이전트가 계속 다운되면 이 명령어를 다시 실행하고 노드 라벨을 더 많은 추가 메모리를 요청하는 라벨로 바꿀 수 있습니다.

   영구 라벨로 노드 풀을 업데이트하려면 다음 명령어를 실행합니다.

   gcloud container node-pools update NODEPOOL_NAME \
       --cluster=CLUSTER_NAME \
       --node-labels=ADDITIONAL_MEMORY_NODE_LABEL \
       --location=COMPUTE_LOCATION
   

   다음을 바꿉니다.

   • NODEPOOL_NAME: 노드 풀의 이름입니다.
   • CLUSTER_NAME: 기존 클러스터의 이름입니다.
   • ADDITIONAL_MEMORY_NODE_LABEL: 추가 메모리 노드 라벨 중 하나로서 다음 값 중 하나를 사용합니다.
     • 10MB 추가: cloud.google.com/gke-metrics-agent-scaling-level=10
     • 20MB 추가: cloud.google.com/gke-metrics-agent-scaling-level=20
     • 50MB 추가: cloud.google.com/gke-metrics-agent-scaling-level=50
     • 100MB 추가: cloud.google.com/gke-metrics-agent-scaling-level=100
     • 200MB 추가: cloud.google.com/gke-metrics-agent-scaling-level=200
     • 500MB 추가: cloud.google.com/gke-metrics-agent-scaling-level=500
   • COMPUTE_LOCATION: 클러스터의 Compute Engine 위치입니다.

   또는 다음 명령어를 사용하여 업그레이드한 후 유지되지 않는 임시 노드 라벨을 추가할 수 있습니다.

   kubectl label node/NODE_NAME \
   ADDITIONAL_MEMORY_NODE_LABEL --overwrite
   

   다음을 바꿉니다.

   • NODE_NAME: 영향을 받는 측정항목 에이전트의 노드 이름
   • ADDITIONAL_MEMORY_NODE_LABEL: 추가 메모리 노드 라벨 중 하나. 위 예시의 값 중 하나를 사용하세요.

다음 단계

• Cloud Logging 에이전트와 관련된 문제가 있으면 문제해결 문서를 참조하세요.

• 추가 지원이 필요하면 Cloud Customer Care에 연락합니다.