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)은 표준 서비스를 정의하고 이러한 규칙을 낮은 우선순위로 따릅니다.
service.istio.io/canonical-name라벨은 이미 명시적으로 설정되어 있습니다. 추가 작업은 발생하지 않습니다.- 그렇지 않으면
service.istio.io/canonical-name라벨이 추가되고 값이app.kubernetes.io/name라벨의 값으로 설정됩니다. - 그렇지 않으면
service.istio.io/canonical-name라벨이 추가되고 값이app라벨의 값으로 설정됩니다. - 그렇지 않으면
service.istio.io/canonical-name라벨이 추가되고 값이 소유 워크로드의name로 설정됩니다. 이 경우 pod가 단독으로 배포되는 경우 '소유 워크로드', 또는 고수준 조정을 사용하는 경우 배포, StatefulSet 등입니다.
Kubernetes 및 Kube Run/Knative의 대부분의 관용적 사용자의 경우 이러한 규칙이 이미 서비스 및 워크로드를 관리하는 방식에 직접 매핑됩니다.
하지만 일부 커스텀 사용 사례나 복잡한 사용 사례에서는 기본 휴리스틱에서 서비스를 적절하게 캡처하지 않으며 결과적으로 Cloud Service Mesh 대시보드에 예상한 콘텐츠가 포함되지 않습니다.
이 문제는 표준 서비스 범위를 수동으로 정의하여 해결할 수 있습니다.
서비스 범위 수동으로 정의
가능한 경우 자동 기본 그룹화 메커니즘을 사용하는 것이 좋습니다. 하지만 이러한 기본 그룹화를 재정의하려면 Kubernetes pod 및 WorkloadEntry 구성에 service.istio.io/canonical-name Kubernetes 라벨을 적용하면 됩니다.
자세한 내용은 표준 서비스 수동으로 정의를 참조하세요.