Cloud Service Mesh 단계별 문제 해결

이 섹션에서는 Cloud Service Mesh를 사용할 때의 문제를 해결하는 방법을 설명합니다. 추가 지원이 필요하면 지원 받기를 참조하세요.

문제 해결 단계

Cloud Service Mesh 문제를 해결하는 일반적인 방법은 다음과 같습니다.

  1. 자동 구성 검증 도구 사용
  2. 일반적인 문제와 알려진 해결책 확인
  3. 문제 범위 좁히기
  4. 관련 로그 및 정보 검토
  5. 진단 로그 수집 및 도움말 탐색

Cloud Service Mesh 진단 도구는 일반적인 구성 문제를 감지할 수 있습니다. 이 안내에 따라 문제 해결 도구를 설치합니다.

시작하기 전에

  1. 클러스터의 kubeconfig 컨텍스트가 kubeconfig 파일에 제공되는지 확인합니다. 그렇지 않으면 다음 명령어를 실행합니다. 

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CLUSTER_LOCATION --project=PROJECT_NAME

    다음을 바꿉니다.

    • CLUSTER_NAME: 클러스터 이름입니다.
    • CLUSTER_LOCATION: 클러스터의 영역 또는 리전입니다.
    • PROJECT_NAME: 프로젝트 이름

  2. 애플리케이션 기본 사용자 인증 정보가 생성되었는지 확인합니다. 그렇지 않은 경우 다음 명령어 중 하나를 실행합니다.

    gcloud auth application-default login --billing-project=PROJECT_NAME

    gcloud auth application-default set-quota-project PROJECT_NAME

    PROJECT_NAME을 프로젝트 이름으로 바꿉니다.

제어 영역 상태 보기

다음 명령어는 Cloud Service Mesh 컨트롤 플레인의 상태를 이해하는 데 도움이 될 수 있습니다.

관리됨

  • Cloud Service Mesh 컨트롤 플레인에 대한 클라이언트 연결 상태 목록을 가져옵니다.

    gcloud beta container fleet mesh debug proxy-status \
    --membership=MEMBERSHIP_NAME \
    --location=MEMBERSHIP_LOCATION \
    --project=PROJECT_NAME

    다음을 바꿉니다.

    • MEMBERSHIP_NAME: 멤버십 이름입니다.
    • MEMBERSHIP_LOCATION: 멤버십의 리전입니다. gcloud container fleet memberships list --project FLEET_PROJECT_ID를 사용하여 멤버십의 위치를 확인할 수 있습니다. 이때 FLEET_PROJECT_ID를 Fleet 프로젝트 ID로 바꿉니다.
    • PROJECT_NAME: 프로젝트 이름

    다음 표에서는 가능한 응답을 설명합니다.

    알 수 없음 (기본값) ⁣상태 정보를 사용할 수 없거나 알 수 없습니다.
    동기화됨 컨트롤 플레인이 클라이언트에 구성을 전송하고 클라이언트로부터 ACK를 수신했습니다.
    오류 컨트롤 플레인이 클라이언트에 구성을 전송하고 클라이언트로부터 NACK를 수신했습니다.
    비활성 컨트롤 플레인이 클라이언트에 구성을 전송했지만 클라이언트로부터 ACK 또는 NACK를 수신하지 못했습니다.
    전송되지 않음 구성이 전송되지 않았습니다.
    해당 사항 없음 해당 없음
    지원되지 않음 문제 해결 API에서는 동기화 상태를 지원하지 않습니다.

클러스터 내

  • kubectl get pods -n istio-system
  • kubectl describe -n istio-system
  • istio-system의 모든 pod에 해당: kubectl logs -n istio-system -l istio --all-containers
  • istioctl version
  • istioctl proxy-status
  • kubectl get configmap istio -o yaml && kubectl get configmap istio-sidecar-injector -o yaml
  • kubectl top pods -n istio-system

다음 명령어를 사용하여 배포 규모를 확인합니다.

  • kubectl get nodes
  • kubectl get services --all-namespaces
  • kubectl get pods --all-namespaces

프록시 구성 보기

다음 명령어는 Cloud Service Mesh 프록시 구성을 이해하는 데 도움이 될 수 있습니다.

관리됨

gcloud beta container fleet mesh debug proxy-config POD_NAME.NAMESPACE \ 
    --type=TYPE \
    --membership=MEMBERSHIP_NAME \
    --location=MEMBERSHIP_LOCATION \
    --project=PROJECT_NAME
  • POD_NAME: 포드의 이름입니다.
  • NAMESPACE: 포드의 네임스페이스입니다.
  • TYPE: 클러스터, 리스너, 경로, 엔드포인트, 부트스트랩, 로그, 보안 비밀, all 중 하나입니다.
  • MEMBERSHIP_NAME: 멤버십 이름입니다.
  • MEMBERSHIP_LOCATION: 멤버십의 리전입니다. gcloud container fleet memberships list --project FLEET_PROJECT_ID를 사용하여 멤버십의 위치를 확인할 수 있습니다. 이때 FLEET_PROJECT_ID를 Fleet 프로젝트 ID로 바꿉니다.
  • PROJECT_NAME: 프로젝트 이름

클러스터 내

클러스터 내 컨트롤 플레인에 대한 프록시 구성을 보려면 istioctl proxy-config를 사용합니다. 자세한 내용은 Envoy 및 istiod 디버깅을 참조하세요.

문제가 지속되면 다음 섹션을 참조하여 이미 알려진 문제인지 확인하세요.

일반적인 문제 및 해결책 확인

다음과 같이 Cloud Service Mesh 기능 영역으로 그룹화한 일반적인 문제 및 해결책 섹션에 나온 문제와 현재 증상이 일치하는지 확인하면 시간을 줄일 수 있습니다.

그래도 문제가 해결되지 않으면 다음 섹션을 참조하세요.

문제 범위 좁히기

Cloud Service Mesh는 여러 연동 기술로 구성되어 있습니다. 따라서 특정 유형의 문제는 특정 기능 영역 또는 구성요소와 관련이 있습니다. 이러한 각 구성요소는 유용한 자체 로그를 생성합니다. 제공되는 정보의 양을 수동으로 분석하기 전에 다음 질문에 답변하는 방식으로 해결할 문제의 범위를 좁힙니다.

  • 문제가 제어 영역 또는 데이터 영역(예: istiod 또는 Envoy 프록시)에서 발생하나요?
  • 어떤 기능 영역에서 네트워킹, 원격 분석, 보안 등의 문제가 발생하나요?
  • 서비스 메시 전체 또는 특정 배포에 트래픽 손실이 있나요?
  • 서비스 메시에 트래픽을 확장하는 기능 부족으로 문제가 발생하거나 악화되나요?
  • 지연 시간이나 다른 성능 문제를 발생시키나요?
  • 요청 시 문제를 재현할 수 있나요?
  • 최근 Istio, GKE 등의 구성을 변경한 후 문제가 시작되었나요?
  • 서비스 메시 내의 트래픽이 증가 또는 급증했나요?
  • 이 클러스터에 눈에 띄는 기능이 사용 설정되어 있거나 일반적이지 않은 배포가 있나요?
  • 높은 CPU 사용률 또는 메모리 사용률이 관찰되나요? 그렇다면 규모에 맞는 예상 사용률은 얼마인가요?
  • 고려할 할당량 제한이 있나요?

관련 로그 및 정보 검토

문제의 범위를 좁힌 후에는 특정 로그와 정보에 보다 효과적으로 집중할 수 있습니다. Cloud Service Mesh가 생성하는 로그 및 로그에 포함된 정보를 해석하는 방법에 대한 자세한 내용은 Cloud Service Mesh 로그 해석을 참조하세요.