Cloud Service Mesh와 Traffic Director가 이제 Cloud Service Mesh로 통합되었습니다. 자세한 내용은 Cloud Service Mesh 개요를 참조하세요.

Envoy 배포 문제 해결

이 가이드에서는 Google API를 사용하여 Cloud Service Mesh를 실행할 때 Envoy 클라이언트 구성 문제를 해결하는 데 도움이 되는 정보를 제공합니다. Client State Discovery Service(CSDS) API를 사용하여 Cloud Service Mesh 문제를 조사하는 방법은 Cloud Service Mesh 클라이언트 상태 이해를 참조하세요.

VM에 설치된 Envoy 버전 확인

다음 안내에 따라 가상 머신(VM) 인스턴스에서 실행 중인 Envoy 버전을 확인합니다.

Envoy 버전을 확인하거나 검사하려면 다음 중 하나를 수행하면 됩니다.

gce-service-proxy/proxy-version 경로에서 VM의 게스트 속성을 확인합니다.

gcloud compute --project cloud-vm-mesh-monitoring instances get-guest-attributes INSTANCE_NAME
--zone ZONEc --query-path=gce-service-proxy/proxy-version

NAMESPACE KEY VALUE gce-service-proxy proxy-version dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

다음과 같은 쿼리를 사용하여 Google Cloud Console의 VM 인스턴스 세부정보 Logging 페이지에서 Cloud Logging 인스턴스 로그를 확인합니다.

  resource.type="gce_instance"
  resource.labels.instance_id="3633122484352464042"
  jsonPayload.message:"Envoy version"

다음과 같은 응답이 수신됩니다.

  {
    "insertId": "9zy0btf94961a",
    "jsonPayload": {
      "message": "Envoy Version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
      "localTimestamp": "2021-01-12T11:39:14.3991Z"
    },
    "resource": {
      "type": "gce_instance",
      "labels": {
        "zone": "asia-southeast1-b",
        "instance_id": "3633122484352464042",
        "project_id": "cloud-vm-mesh-monitoring"
      }
    },
    "timestamp": "2021-01-12T11:39:14.399200504Z",
    "severity": "INFO",
    "logName": "projects/cloud-vm-mesh-monitoring/logs/service-proxy-agent",
    "receiveTimestamp": "2021-01-12T11:39:15.407023427Z"
  }

SSH를 사용하여 VM에 연결하고 바이너리 버전을 확인합니다.

YOUR_USER_NAME@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~$ /usr/local/bin/envoy --version

/usr/local/bin/envoy version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

SSH를 사용하여 VM 및 관리 인터페이스에 루트로 연결합니다.

  root@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~# curl localhost:15000/server_info
  {
   "version": "dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
   "state": "LIVE",
   "hot_restart_version": "disabled",
   ...
  }

Envoy 로그 위치

일부 문제를 해결하려면 Envoy 프록시 로그를 조사해야 합니다.

SSH를 사용하여 VM 인스턴스에 연결해 로그 파일을 가져올 수 있습니다. 경로는 다음과 같을 수 있습니다.

  /var/log/envoy/envoy.err.log

프록시가 Cloud Service Mesh에 연결되지 않음

프록시가 Cloud Service Mesh에 연결되지 않으면 다음을 수행합니다.

Envoy 프록시 로그에 trafficdirector.googleapis.com 연결 관련 오류가 있는지 확인합니다.
모든 트래픽을 Envoy 프록시로 리디렉션하도록 iptables를 사용하여 netfilter를 설정한 경우 프록시를 실행하는 사용자(UID)가 리디렉션에서 제외되는지 확인합니다. 그렇지 않으면 트래픽이 지속적으로 프록시로 되돌아갑니다.
프로젝트에 Cloud Service Mesh API를 사용 설정했는지 확인합니다. 프로젝트의 API 및 서비스에서 Cloud Service Mesh API 오류를 찾습니다.
VM을 만들 때 다음을 지정하여 VM의 API 액세스 범위가Google Cloud API에 대한 전체 액세스를 허용하도록 설정되어 있는지 확인합니다.
```
--scopes=https://www.googleapis.com/auth/cloud-platform
```
서비스 계정에 올바른 권한이 있는지 확인합니다. 자세한 내용은 Traffic Director API에 액세스하도록 서비스 계정 사용 설정을 참조하세요.
VM에서 trafficdirector.googleapis.com:443에 액세스할 수 있는지 확인합니다. 이 액세스에 문제가 있는 경우 방화벽 포트가 TCP 포트 443을 통해 trafficdirector.googleapis.com에 액세스하지 못하도록 하거나 trafficdirector.googleapis.com 호스트 이름의 DNS 확인 문제일 수 있습니다.
사이드카 프록시에 Envoy를 사용하는 경우 Envoy 출시 버전이 1.24.9 이상인지 확인합니다.

Cloud Service Mesh로 구성된 서비스에 연결할 수 없음

Cloud Service Mesh로 구성된 서비스에 연결할 수 없으면 사이드카 프록시가 실행 중이고 Cloud Service Mesh에 연결할 수 있는지 확인합니다.

Envoy를 사이드카 프록시로 사용하는 경우 다음 명령어를 실행하여 이를 확인할 수 있습니다.

명령줄에서 Envoy 프로세스가 실행 중인지 확인합니다.
```
ps aux | grep envoy
```
Envoy의 런타임 구성을 검사하여 Cloud Service Mesh에서 동적 리소스를 구성했는지 확인합니다. 구성을 보려면 다음 명령어를 실행합니다.
```
curl http://localhost:15000/config_dump
```
사이드카 프록시에 대한 트래픽 가로채기가 올바르게 설정되었는지 확인합니다. iptables로 리디렉션을 설정하려면 iptables 명령어를 실행한 후 출력을 grep하여 규칙이 있는지 확인합니다.
```
sudo iptables -t nat -S | grep ISTIO
```
다음은 가상 IP 주소(VIP) 10.0.0.1/32를 가로채서 포트 15001에 UID 1006으로 전달하는 iptables의 출력 예시입니다.
```
-N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-N ISTIO_REDIRECT
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15001
-A ISTIO_OUTPUT -m owner --uid-owner 1006 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -d 10.0.0.1/32 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -j RETURN
```

Google Cloud Console을 통해 VM 인스턴스를 만든 경우 일부 IPv6 관련 모듈은 다시 시작하기 전에 설치 및 제공되지 않습니다. 이로 인해 종속 항목이 누락되어 iptables가 실패합니다. 이 경우 VM을 다시 시작하고 설정 프로세스를 다시 실행하면 문제가 해결됩니다. Google Cloud CLI를 사용하여 만든 Compute Engine VM에서는 이러한 문제가 발생하지 않습니다.

Envoy 액세스 로깅이 구성된 경우 서비스에 연결할 수 없습니다.

Cloud Service Mesh용 Envoy 부트스트랩 속성 구성의 설명대로 TRAFFICDIRECTOR_ACCESS_LOG_PATH를 사용하여 Envoy 액세스 로그를 구성한 경우 Envoy 프록시를 실행하는 시스템 사용자에게 지정된 액세스 로그 위치에 작성할 수 있는 권한이 있는지 확인합니다.

필요한 권한을 제공하지 않으면 리스너가 프록시에서 프로그래밍되지 않으며 Envoy 프록시 로그에서 다음 오류 메시지를 확인하여 감지할 수 있습니다.

gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected:
Error adding/updating listener(s) TRAFFICDIRECTOR_INTERCEPTION_PORT:
unable to open file '/var/log/envoy.log': Permission denied

문제를 해결하기 위해 Envoy 사용자가 액세스 로그에 작성할 수 있도록 선택한 파일의 권한을 변경합니다.

구성 문제를 표시하는 Envoy 로그의 오류 메시지

이 섹션은 부하 분산 API를 사용하는 배포에 적용됩니다.

Cloud Service Mesh 구성에 문제가 있으면 Envoy 로그에 다음과 같은 오류 메시지가 표시될 수 있습니다.

warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".

warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Cloud Service Mesh configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".

warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Requested entity was not found.

warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Requested entity was not found.

Cloud Service Mesh configuration was not found.

마지막 오류 메시지(Traffic Director configuration was not found)는 일반적으로 Envoy가 Cloud Service Mesh에서 구성을 요청하지만 일치하는 구성을 찾을 수 없음을 나타냅니다. Envoy가 Cloud Service Mesh에 연결하면 VPC 네트워크 이름(예: my-network)이 표시됩니다. 그런 다음 Cloud Service Mesh에서 INTERNAL_SELF_MANAGED 부하 분산 스킴이 있고 같은 VPC 네트워크 이름을 참조하는 전달 규칙을 찾습니다.

이 오류를 고치려면 다음 안내를 따르세요.

네트워크에 부하 분산 스킴 INTERNAL_SELF_MANAGED가 있는 전달 규칙이 있는지 확인합니다. 전달 규칙의 VPC 네트워크 이름을 기록합니다.
Compute Engine에서 자동화된 Envoy 배포와 함께 Cloud Service Mesh를 사용하는 경우 --service-proxy:network 플래그에 제공된 값이 전달 규칙의 VPC 네트워크 이름과 일치하는지 확인합니다.
Compute Engine에서 수동 Envoy 배포와 함께 Cloud Service Mesh를 사용하는 경우 다음과 같이 Envoy 부트스트랩 파일을 확인합니다.
1. TRAFFICDIRECTOR_NETWORK_NAME 변수 값이 전달 규칙의 VPC 네트워크 이름과 일치하는지 확인합니다.
2. 프로젝트 번호가 TRAFFICDIRECTOR_GCP_PROJECT_NUMBER 변수에 설정되어 있는지 확인합니다.
GKE에 배포하고 자동 인젝터를 사용하고 있는 경우 프로젝트 번호와 VPC 네트워크 이름이 자동 Envoy 삽입으로 GKE 포드용 Cloud Service Mesh 설정의 안내에 따라 올바르게 구성되었는지 확인합니다.

Compute Engine 문제 해결

이 섹션에서는 Compute Engine의 Envoy 배포 문제를 해결하기 위한 안내를 제공합니다.

Envoy 및 VM 부트스트랩 프로세스 및 추가 수명 주기 관리 작업은 일시적인 연결 문제, 저장소 손상, 부트스트랩 스크립트 및 VM 기반 에이전트의 버그, 예기치 않은 사용자 작업 등 여러 가지 이유로 실패할 수 있습니다.

문제 해결을 위한 커뮤니케이션 채널

Google Cloud 는 부트스트랩 프로세스 및 VM에 있는 구성요소의 현재 상태를 이해하는 데 사용할 수 있는 통신 채널을 제공합니다.

가상 직렬 포트 출력 로깅

VM의 운영체제, BIOS, 기타 시스템 수준 항목은 일반적으로 직렬 포트에 출력을 작성합니다. 이 출력 결과는 시스템 장애, 부팅 실패, 시작 문제, 종료 문제를 해결하는데 유용합니다

Compute Engine 부트스트랩 에이전트는 수행된 모든 작업을 시스템 포트 1에 기록합니다. 여기에는 인스턴스의 메타데이터 서버, iptables 구성, Envoy 설치 상태로부터 데이터를 가져와 기본 패키지 설치부터 시작하는 시스템 이벤트가 포함됩니다.

VM 기반 에이전트는 Envoy 프로세스 상태, 새로 발견된 Cloud Service Mesh 서비스, VM 문제를 조사할 때 유용할 수 있는 기타 모든 정보를 로깅합니다.

Cloud Monitoring 로깅

직렬 포트 출력에 노출된 데이터는 Monitoring에 로깅됩니다. 이는 Golang 라이브러리를 사용하고 로그를 별도의 로그로 내보내 노이즈를 줄입니다. 이 로그는 인스턴스 수준 로그이므로, 다른 인스턴스 로그와 같이 동일한 페이지에서 서비스 프록시 로그를 찾을 수 있습니다.

VM 게스트 속성

게스트 속성은 애플리케이션이 인스턴스에서 실행되는 동안 쓸 수 있는 특정 유형의 커스텀 메타데이터입니다. 인스턴스의 모든 애플리케이션 또는 사용자는 이러한 게스트 속성 메타데이터 값을 읽고 여기에 데이터를 쓸 수 있습니다.

Compute Engine Envoy 부트스트랩 스크립트와 VM 에이전트는 부트스트랩 처리 및 Envoy의 현재 상태에 대한 정보와 함께 속성을 노출합니다. 모든 게스트 속성은 gce-service-proxy 네임스페이스에 노출됩니다.

gcloud compute instances get-guest-attributes INSTANCE_NAME  \
    --query-path=gce-service-proxy/ \
    --zone=ZONE

문제가 발견되면 게스트 속성 bootstrap-status 및 bootstrap-last-failure의 값을 확인하는 것이 좋습니다. FINISHED 이외의 모든 bootstrap-status 값은 Envoy 환경이 아직 구성되지 않았음을 나타냅니다. bookstrap-last-failure 값은 문제가 무엇인지 나타낼 수 있습니다.

서비스 프록시가 사용 설정된 인스턴스 템플릿을 사용하여 만든 VM에서 Cloud Service Mesh 서비스에 연결할 수 없음

이 문제를 해결하려면 다음 단계를 수행합니다.

VM에 서비스 프록시 구성요소 설치가 완료되지 않았거나 실패했을 수 있습니다. 다음 명령어를 사용하여 모든 구성요소가 제대로 설치되었는지 확인합니다.
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE
```
bootstrap-status 게스트 속성은 다음 중 하나로 설정됩니다.
- [none]은 설치가 아직 시작되지 않았음을 나타냅니다. VM이 아직 부팅 중일 수도 있습니다. 잠시 후 상태를 다시 확인해 보세요.
- IN PROGRESS는 서비스 프록시 구성요소의 설치 및 구성이 아직 완료되지 않았음을 나타냅니다. 프로세스 업데이트에 대한 상태 확인을 반복합니다.
- FAILED는 구성요소 설치 또는 구성이 실패했음을 나타냅니다. gce-service-proxy/bootstrap-last-failure1 속성을 쿼리하여 오류 메시지를 확인합니다.
- FINISHED는 설치 및 구성 프로세스가 오류 없이 완료되었음을 나타냅니다. 다음 안내에 따라 트래픽 가로채기와 Envoy 프록시가 올바르게 구성되었는지 확인합니다.
VM의 트래픽 가로채기가 Cloud Service Mesh 기반 서비스에 올바르게 구성되지 않았습니다. VM에 로그인하고 iptables 구성을 확인합니다.
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat
```
다음과 같은 SERVICE_PROXY_REDIRECT 항목의 SERVICE_PROXY_SERVICE_CIDRS 체인을 살펴봅니다.
```
Chain SERVICE_PROXY_SERVICE_CIDRS (1 references)
target                   prot opt source         destination ...
SERVICE_PROXY_REDIRECT   all  --  anywhere       10.7.240.0/20
```
각 서비스는 destination 열에 일치하는 IP 주소나 CIDR이 있어야 합니다. 가상 IP 주소(VIP)에 대한 항목이 없는 경우 이는 Cloud Service Mesh에서 Envoy 프록시 구성을 채우는 데 문제가 있거나 VM 기반 에이전트가 실패한 것입니다.
Envoy 프록시가 아직 Cloud Service Mesh에서 구성을 받지 못했습니다. VM에 로그인하여 Envoy 프록시 구성을 확인합니다.
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump
```
Cloud Service Mesh에서 받은 리스너 구성을 검사합니다. 예를 들면 다음과 같습니다.
```
"dynamic_active_listeners": [
  ...
  "filter_chains": [{
    "filter_chain_match": {
      "prefix_ranges": [{
        "address_prefix": "10.7.240.20",
        "prefix_len": 32
      }],
      "destination_port": 80
    },
  ...
    "route_config_name": "URL_MAP/PROJECT_NUMBER.td-routing-rule-1"
  ...
]
```
address_prefix는 Cloud Service Mesh 서비스의 가상 IP 주소(VIP)입니다. td-routing-rule-1이라는 URL 맵을 가리킵니다. 연결하려는 서비스가 리스너 구성에 이미 포함되어 있는지 확인합니다.
VM 기반 에이전트가 실행되고 있지 않습니다. VM 기반 에이전트는 새 Cloud Service Mesh 서비스가 생성될 때 트래픽 가로채기를 자동으로 구성합니다. 에이전트가 실행되고 있지 않으면 새 서비스에 대한 모든 트래픽이 Envoy 프록시와 타임아웃을 우회하여 VIP로 바로 전달됩니다.
1. 다음 명령어를 실행하여 VM의 에이전트 상태를 확인합니다.
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
   --query-path=gce-service-proxy/ \
   --zone=ZONE
```
2. VM 기반 에이전트 속성을 검사합니다. agent-heartbeat 속성의 값에는 에이전트가 마지막으로 작업 또는 확인을 수행한 시간이 있습니다. 이 값이 5분을 초과하면 에이전트가 중단됩니다. 그러면 다음 명령어를 사용하여 VM을 다시 만들어야 합니다.
```
gcloud compute instance-groups managed recreate-instance
```
3. agent-last-failure 속성은 에이전트에서 마지막으로 발생한 오류를 노출합니다. 이는 다음 번에 에이전트가 해당 오류가 Cannot reach the Cloud Service Mesh API server인지 혹은 영구적인 오류인지 확인할 때 해결되는 일시적인 문제일 수 있습니다. 몇 분 기다린 후에 오류를 다시 확인합니다.

워크로드 포트에 인바운드 트래픽 가로채기가 구성되어 있지만 VM 외부에서는 포트에 연결할 수 없음

이 문제를 해결하려면 다음 단계를 수행합니다.

VM에 서비스 프록시 구성요소 설치가 완료되지 않았거나 실패했을 수 있습니다. 다음 명령어를 사용하여 모든 구성요소가 제대로 설치되었는지 확인합니다.
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE
```
bootstrap-status 게스트 속성은 다음 중 하나로 설정됩니다.
- [none]은 설치가 아직 시작되지 않았음을 나타냅니다. VM이 아직 부팅 중일 수도 있습니다. 잠시 후 상태를 다시 확인해 보세요.
- IN PROGRESS는 서비스 프록시 구성요소의 설치 및 구성이 아직 완료되지 않았음을 나타냅니다. 프로세스 업데이트에 대한 상태 확인을 반복합니다.
- FAILED는 구성요소 설치 또는 구성이 실패했음을 나타냅니다. gce-service-proxy/bootstrap-last-failure1 속성을 쿼리하여 오류 메시지를 확인합니다.
- FINISHED는 설치 및 구성 프로세스가 오류 없이 완료되었음을 나타냅니다. 다음 안내에 따라 트래픽 가로채기와 Envoy 프록시가 올바르게 구성되었는지 확인합니다.
VM의 트래픽 가로채기가 인바운드 트래픽에 맞게 올바르게 구성되지 않았습니다. VM에 로그인하고 iptables 구성을 확인합니다.
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat
```
다음과 같은 SERVICE_PROXY_IN_REDIRECT 항목의 SERVICE_PROXY_INBOUND 체인을 살펴봅니다.
```
Chain SERVICE_PROXY_INBOUND (1 references)
target                      prot opt source       destination ...
SERVICE_PROXY_IN_REDIRECT   tcp  --  anywhere     anywhere  tcp dpt:mysql
```
service-proxy:serving-ports에 정의된 각 포트에 대해 destination 열에 일치하는 포트가 있어야 합니다. 포트 항목이 없는 경우 모든 인바운드 트래픽은 Envoy 프록시를 우회하여 이 포트로 직접 이동합니다.

이 포트 또는 특정 포트를 제외한 모든 포트로 트래픽을 삭제하는 다른 규칙이 없는지 확인합니다.
Envoy 프록시가 아직 Cloud Service Mesh에서 인바운드 포트 구성을 받지 못했습니다. VM에 로그인하여 Envoy 프록시 구성을 확인합니다.
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump
```
Cloud Service Mesh에서 받은 인바운드 리스너 구성을 찾습니다.
```
"dynamic_active_listeners": [
  ...
  "filter_chains": [{
    "filter_chain_match": {
      "prefix_ranges": [{
        "address_prefix": "10.0.0.1",
        "prefix_len": 32
      }],
      "destination_port": 80
    },
  ...
    "route_config_name": "inbound|default_inbound_config-80"
  ...
]
```
inbound로 시작하는 route_config_name는 인바운드 트래픽 가로채기용으로 생성된 특수 서비스를 나타냅니다. 연결하려는 포트가 destination_port의 리스너 구성에 이미 포함되어 있는지 확인합니다.

연결에서 서버 우선 프로토콜을 사용할 때 발생하는 문제

MySQL과 같은 일부 애플리케이션은 서버가 첫 번째 패킷을 전송하는 프로토콜을 사용합니다. 즉, 최초 연결 시에 서버는 첫 번째 바이트를 보냅니다. 이러한 프로토콜과 애플리케이션은 Cloud Service Mesh에서 지원되지 않습니다.

서비스 메시 상태 문제 해결

이 가이드에서는 Cloud Service Mesh 구성 문제를 해결하는 데 도움이 되는 정보를 제공합니다.

대부분의 엔드포인트가 비정상인 경우의 Cloud Service Mesh 동작

엔드포인트의 99%가 비정상이면 신뢰성을 높이기 위해 Cloud Service Mesh에서 데이터 영역을 구성하여 엔드포인트의 정상 상태를 무시합니다. 대신 데이터 영역은 모든 엔드포인트 간에 트래픽을 분산하며 이는 서빙 포트가 계속 작동할 수 있기 때문입니다.

비정상 백엔드로 인해 트래픽 분산이 최적화되지 않음

Cloud Service Mesh는 백엔드 서비스에 연결된 HealthCheck 리소스의 정보를 사용하여 백엔드 상태를 평가합니다. Cloud Service Mesh는 이 정상 상태를 사용하여 트래픽을 가장 가까운 정상 백엔드로 라우팅합니다. 일부 백엔드가 비정상이면 트래픽이 계속 처리되더라도 분포가 최적이 아닐 수 있습니다. 예를 들어 트래픽이 정상 백엔드가 계속 있는 리전에 전달될 수 있지만 클라이언트에서 멀리 떨어져 있어 지연 시간이 발생할 수 있습니다. 백엔드 정상 상태를 식별하고 모니터링하려면 다음 단계를 수행합니다.

Google Cloud Console에서 백엔드 서비스 상태를 점검합니다.
Cloud Service Mesh 서비스로 이동
HealthCheck 리소스에 로깅이 사용 설정되어 있는지 확인합니다.
상태 점검이 최근에 실패하기 시작했으면 Cloud 감사 로그를 검사하여 HealthCheck 구성이 최근에 변경되었는지 확인합니다.

다음 단계

프록시리스 gRPC 서비스를 배포할 때 구성 문제를 해결하려면 프록시리스 gRPC를 사용하는 배포 문제 해결을 참조하세요.
Cloud Service Mesh 사용에 대한 추가 지원은 지원 받기를 참조하세요.