이 섹션에서는 일반적인 Anthos Service Mesh 문제와 해결 방법을 설명합니다. 추가 지원이 필요하면 지원 받기를 참조하세요.
Anthos Service Mesh 원격 분석에서 Envoy 프록시는 주기적으로 Google Cloud Observability API를 호출하여 원격 분석 데이터를 보고합니다. API 호출 유형에 따라 실행 빈도가 결정됩니다.
- 로깅: 약 10초 간격
- 측정항목: 약 1분 간격
- 에지(Context API/토폴로지 뷰): 증분 보고서는 약 1분 간격, 전체 보고서는 약 10분 간격
- Trace: 구성한 샘플링 빈도에 따라 결정(일반적으로 100개의 요청 중 1개)
원격 분석 대시보드는 Confluence 및 Google Cloud Observability에서 데이터를 수집하여 다양한 서비스 중심 대시보드를 표시합니다.
서비스 대시보드에 서비스가 없음
대시보드에 HTTP(S)/gRPC 서비스만 표시됩니다. 서비스가 목록에 있다면 Anthos Service Mesh 원격 분석에서 이를 HTTP 서비스로 식별하는지 확인합니다.
서비스가 누락된 경우 클러스터에 Kubernetes 서비스 구성이 있는지 확인합니다.
모든 Kubernetes 서비스 목록을 검토합니다.
kubectl get services --all-namespaces
특정 네임스페이스의 Kubernetes 서비스 목록을 검토합니다.
kubectl get services -n YOUR_NAMESPACE
서비스에 대한 측정항목이 누락되거나 잘못됨
서비스 대시보드에 서비스에 대한 측정항목이 누락되거나 잘못된 경우 다음 섹션에서 가능한 해결 방법을 참조하세요.
사이드카 프록시가 있으며 제대로 삽입되었는지 확인
네임스페이스에 자동 삽입 라벨이 없거나 수동 삽입에 실패한 경우일 수 있습니다. 네임스페이스의 포드에 컨테이너가 2개 이상 있고 이 중 1개가 istio-proxy 컨테이너인지 확인합니다.
kubectl -n YOUR_NAMESPACE get pods
원격 분석 구성이 있는지 확인하기
istio-system 네임스페이스에서 EnvoyFilter를 사용하여 원격 분석을 구성할 수 있습니다.
이 구성이 없으면 Anthos Service Mesh는 Google Cloud Observability에 데이터를 보고하지 않습니다.
Google Cloud Observability 구성(및 메타데이터 교환 구성)이 있는지 확인합니다.
kubectl -n istio-system get envoyfilter
예상 출력은 다음과 비슷합니다.
NAME AGE metadata-exchange-1.4 13d metadata-exchange-1.5 13d stackdriver-filter-1.4 13d stackdriver-filter-1.5 13d ...
Google Cloud Observability 필터가 올바르게 구성되어 있는지 추가로 확인하려면 각 프록시에서 구성 덤프를 수집하고 Google Cloud Observability 필터가 있는지 확인합니다.
kubectl exec YOUR_POD_NAME -n YOUR_NAMESPACE -c istio-proxy curl localhost:15000/config_dump
이전 명령어 출력에서 다음과 같은 Google Cloud Observability 필터를 찾습니다.
"config": {
"root_id": "stackdriver_inbound",
"vm_config": {
"vm_id": "stackdriver_inbound",
"runtime": "envoy.wasm.runtime.null",
"code": {
"local": {
"inline_string": "envoy.wasm.null.stackdriver"
}
}
},
"configuration": "{....}"
}Anthos Service Mesh가 HTTP 서비스를 식별하는지 확인
Kubernetes 서비스의 서비스 포트 이름에 http 프리픽스가 없으면 사용자 인터페이스에 측정항목이 표시되지 않습니다. 서비스의 포트 이름이 올바른지 확인합니다.
프로젝트에 Cloud Monitoring API가 사용 설정되었는지 확인
Google Cloud 콘솔의 API 및 서비스 대시보드에서 Cloud Monitoring API가 기본으로 사용 설정되어 있는지 확인합니다.
Cloud Monitoring API에 대한 오류 보고가 없는지 확인
Google Cloud 콘솔 API 및 서비스 대시보드에서 응답 코드별 트래픽 그래프 URL을 엽니다.
https://console.cloud.google.com/apis/api/monitoring.googleapis.com/metrics?folder=&organizationId=&project=YOUR_PROJECT_ID
오류 메시지가 표시되는 경우 추가 조사가 필요할 수 있습니다. 특히 잠재적인 할당량 문제를 나타내는 다수의 429 오류 메시지를 찾습니다. 문제 해결 단계는 다음 섹션을 참조하세요.
Cloud Monitoring API의 올바른 할당량 확인
Google Cloud 콘솔에서 IAM & Admin 메뉴를 열고 할당량 옵션이 있는지 확인합니다. URL을 사용하여 이 페이지에 직접 액세스할 수 있습니다.
https://console.cloud.google.com/iam-admin/quotas?project=YOUR_PROJECT_ID
이 페이지는 프로젝트의 전체 할당량 집합을 보여주며, 여기서 Cloud Monitoring API를 검색할 수 있습니다.
Envoy 프록시에 오류 로그가 없는지 확인
해당 프록시의 로그를 검토하여 오류 메시지 인스턴스를 검색합니다.
kubectl -n YOUR_NAMESPACE logs YOUR_POD_NAME -c istio-proxy
그러나 다음과 같은 경고 메시지는 정상이므로 무시해도 됩니다.
[warning][filter] [src/envoy/http/authn/http_filter_factory.cc:83] mTLS PERMISSIVE mode is used, connection can be either plaintext or TLS, and client cert can be omitted. Please consider to upgrade to mTLS STRICT mode for more secure configuration that only allows TLS connection with client cert. See https://istio.io/docs/tasks/security/mtls-migration/ [warning][config] [bazel-out/k8-opt/bin/external/envoy/source/common/config/_virtual_includes/grpc_stream_lib/common/config/grpc_stream.h:91] gRPC config stream closed: 13
서비스에 대한 원격 분석 데이터가 누락되거나 잘못됨
기본적으로 Anthos Service Mesh를 설치할 때 Google Cloud 프로젝트에서 Cloud Monitoring 및 Cloud Logging이 사용 설정됩니다. 원격 분석 데이터를 보고하기 위해 서비스 pod에 삽입되는 각 사이드카 프록시가 Cloud Monitoring API 및 Cloud Logging API를 호출합니다. 워크로드를 배포한 후 Google Cloud Console에 원격 분석 데이터가 표시되는 데 1~2분 정도 걸립니다. Anthos Service Mesh는 서비스 대시보드를 자동으로 최신 상태로 유지합니다.
- 측정항목의 경우 사이드카 프록시는 약 1분 간격으로 Cloud Monitoring API를 호출합니다.
- 토폴로지 그래프를 업데이트하기 위해 사이드카 프록시는 약 1분 간격으로 증분 보고서를, 약 10분 간격으로 전체 보고서를 전송합니다.
- 로깅의 경우 사이드카 프록시는 약 10초 간격으로 Cloud Logging API를 호출합니다.
- 추적의 경우 Cloud Trace를 사용 설정해야 합니다. Trace는 구성한 샘플링 빈도(일반적으로 100개의 요청 중 1개)에 따라 보고됩니다.
측정항목은 Anthos Service Mesh 측정항목 페이지에 있는 HTTP 서비스에만 표시됩니다. 측정항목이 표시되지 않으면 애플리케이션 서비스의 네임스페이스에 있는 모든 포드에 사이드카 프록시가 삽입되어 있는지 확인합니다.
kubectl get pod -n YOUR_NAMESPACE --all
출력의 READY 열에서 각 워크로드마다 컨테이너가 2개(기본 컨테이너와 사이드카 프록시 컨테이너)가 있다는 것을 확인할 수 있습니다.
또한 서비스 대시보드에는 클라이언트 측정항목만 표시되므로 클라이언트가 메시에 있지 않으면 원격 분석 데이터가 표시되지 않을 수 있습니다.