Cloud Service Mesh에서 표준 서비스 문제 해결

참고: Cloud Service Mesh 버전 1.6.8 이상에서는 표준 서비스가 자동으로 지원됩니다.

이 섹션에서는 일반적인 Cloud Service Mesh 문제와 해결 방법을 설명합니다. 추가 지원이 필요하면 지원 받기를 참조하세요.

메시의 클러스터에서 이전 버전의 Cloud Service Mesh가 실행 중임

클러스터에 이전 버전의 Cloud Service Mesh(1.6.8 미만) 또는 표준 서비스 컨트롤러가 사용 중지된 상태로 Cloud Service Mesh가 실행되는 경우 해당 클러스터(및 여기에서 실행되는 서비스)가 Service Mesh UI에 표시되지 않습니다. 표준 서비스를 사용하려면 각 클러스터를 Cloud Service Mesh 1.6.8 이상으로 업그레이드하고 표준 서비스 컨트롤러가 포함된 기본 설치 옵션을 사용해야 합니다. 자세한 내용은 Cloud Service Mesh를 최신 버전으로 업그레이드(클러스터가 GKE에 있는 경우) 또는 온프레미스에서 Cloud Service Mesh 업그레이드를 참조하세요.

또는 클러스터에 컨트롤러를 설치하지 않으려면 메시에 대해 관리형 표준 서비스 컨트롤러(현재 미리보기 상태)를 사용 설정할 수 있습니다.

표준 서비스 컨트롤러 사용 설정에 대한 자세한 내용은 표준 서비스 컨트롤러 사용 설정을 참조하세요.

Cloud Service Mesh가 클러스터에 설치되지 않음

Cloud Service Mesh가 클러스터에 설치되지 않으면 Service Mesh UI에 클러스터가 표시되지 않습니다. Cloud Service Mesh 설치 방법에 대한 자세한 내용은 Cloud Service Mesh 문서를 참조하세요.

온프레미스 클러스터에 로그인되지 않음

메시에 온프레미스 클러스터가 있고 클러스터에 로그인되어 있지 않으면 해당 클러스터에 해당하는 서비스를 볼 수 없습니다. 대시보드에서 이러한 서비스를 보려면 클러스터에 로그인해야 합니다. 클러스터에 로그인하는 방법에 대한 자세한 내용은 Cloud 콘솔에서 클러스터에 로그인을 참조하세요.

온프레미스 클러스터에 연결할 수 없음

메시에 온프레미스 클러스터가 있고 연결 에이전트를 통해 연결할 수 없으면 해당 클러스터에 해당하는 서비스를 볼 수 없습니다. 대시보드에서 이러한 서비스를 보려면 클러스터가 실행 중이고 Google Cloud에 연결되어 있는지 확인하세요. 클러스터를 Google Cloud에 연결하는 방법에 관한 자세한 내용은 연결 개요를 참조하세요.

정의된 SLO가 있는 서비스가 표준 서비스와 1:1로 매핑되지 않음

표준 서비스로 전환하기 전에 Cloud Service Mesh에 Kubernetes 서비스용 대시보드가 표시되었습니다. Kubernetes 서비스와 기본 표준 서비스가 일치하는 경우도 있지만 Kubernetes 서비스가 해당 표준 서비스와 자동으로 일치되지 않거나, 기본 표준 서비스 경계가 바람직하지 않을 수 있습니다.

기본 서비스에서 기본 표준 서비스와 자동으로 일치될 수 없는 서비스 수준 목표(SLO)가 설정되어 있으면 마이그레이션할 수 없습니다. 표준 서비스를 사용하려면 문제가 있는 서비스의 SLO를 삭제해야 합니다. 원하는 경우 이전 SLO를 삭제하기 전에 해당 서비스와 가장 일치하는 표준 서비스의 새 SLO를 생성할 수 있습니다.

내 대시보드에 예상한 콘텐츠가 없음

Service Mesh 서비스 대시보드는 각각 서비스 메시의 표준 서비스로 범위가 지정되며, 여기서 표준 서비스는 모든 관련 워크로드, 리전 등을 포함하는 고수준 논리적 서비스 개념입니다.

기본적으로 각 워크로드 인스턴스의 기존 라벨(pod 또는 WorkloadEntry)은 표준 서비스를 정의하고 이러한 규칙을 낮은 우선순위로 따릅니다.

1. service.istio.io/canonical-name 라벨은 이미 명시적으로 설정되어 있습니다. 추가 작업은 발생하지 않습니다.
2. 그렇지 않으면 service.istio.io/canonical-name 라벨이 추가되고 값이 app.kubernetes.io/name 라벨의 값으로 설정됩니다.
3. 그렇지 않으면 service.istio.io/canonical-name 라벨이 추가되고 값이 app 라벨의 값으로 설정됩니다.
4. 그렇지 않으면 service.istio.io/canonical-name 라벨이 추가되고 값이 소유 워크로드의 name로 설정됩니다. 이 경우 pod가 단독으로 배포되는 경우 '소유 워크로드', 또는 고수준 조정을 사용하는 경우 배포, StatefulSet 등입니다.

Kubernetes 및 Kube Run/Knative의 대부분의 관용적 사용자의 경우 이러한 규칙이 이미 서비스 및 워크로드를 관리하는 방식에 직접 매핑됩니다.

하지만 일부 커스텀 사용 사례나 복잡한 사용 사례에서는 기본 휴리스틱에서 서비스를 적절하게 캡처하지 않으며 결과적으로 Cloud Service Mesh 대시보드에 예상한 콘텐츠가 포함되지 않습니다.

이 문제는 표준 서비스 범위를 수동으로 정의하여 해결할 수 있습니다.

서비스 범위 수동으로 정의

가능한 경우 자동 기본 그룹화 메커니즘을 사용하는 것이 좋습니다. 하지만 이러한 기본 그룹화를 재정의하려면 Kubernetes pod 및 WorkloadEntry 구성에 service.istio.io/canonical-name Kubernetes 라벨을 적용하면 됩니다.

자세한 내용은 표준 서비스 수동으로 정의를 참조하세요.

관리형 표준 컨트롤러 문제 해결

1. 기능 상태 확인: 다음 명령어를 실행합니다. 여기서 FLEET_PROJECT_ID는 Fleet 호스트 프로젝트의 ID입니다. 일반적으로 FLEET_PROJECT_ID는 기본 생성되며 프로젝트와 이름이 동일합니다.

  gcloud container fleet mesh describe --project FLEET_PROJECT_ID
  

출력 예시:

      membershipStates:
        projects/<project-number>/locations/<location>/memberships/<membership-name>:
          state:
            code: OK
            description: 
              Revision(s) ready for use: istiod-asm-183-2.
              All Canonical Services have been reconciled successfully.

2. state.code에 따라 조치를 취합니다.

기능 상태 출력에서 클러스터의 상태를 확인합니다. state.code 값을 검사하면 관리형 CSC의 현재 상태를 파악하는 데 도움이 됩니다. state.code의 값에 따라 해당 작업을 구현합니다.

• MISSING:

  1. 초기화 지연이 발생할 수 있으므로 1시간 정도 기다립니다.
  2. gcloud container fleet mesh describe --project <FLEET_PROJECT_ID> 명령어를 다시 실행합니다. state.code가 여전히 표시되지 않으면 Google Cloud 지원팀에 문의하세요.

• WARNING/ERROR:

  1. servicemesh.conditions에서 자세한 오류 정보를 확인하세요.
  2. CANONICAL_SERVICE_ERROR 조건이 발견되면 관리형 표준 서비스 컨트롤러에 문제가 있는 것입니다. 그렇지 않으면 표준 서비스 컨트롤러 외부의 문제일 수 있습니다.
  3. 두 경우 모두 추가 문제 해결을 위해 Google Cloud 지원팀에 문의하세요.

• OK: state.description 텍스트에 따른 작업은 다음 표를 참고하세요.