Envoy 배포 문제 해결
이 가이드에서는 Traffic Director 구성 문제를 해결하는 데 도움이 되는 정보를 제공합니다. Client State Discovery Service(CSDS) API를 사용하여 Traffic Director 문제를 조사하는 데 대한 자세한 내용은 Traffic Director 클라이언트 상태 이해를 참조하세요.
VM에 설치된 Envoy 버전 확인
다음 안내에 따라 가상 머신(VM) 인스턴스에서 실행 중인 Envoy 버전을 확인합니다.
자동 Envoy 배포를 사용하여 버전 확인
자동 배포로 Envoy 버전을 확인하거나 검토하려면 다음 안내를 따르세요.
gce-service-proxy/proxy-version경로에서 VM의 게스트 속성을 확인합니다.gcloud compute --project cloud-vm-mesh-monitoring instances get-guest-attributes INSTANCE_NAME \ --zone ZONE --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에 연결하고 바이너리 버전을 확인합니다.
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 프록시 로그를 조사해야 합니다.
Google Kubernetes Engine(GKE)에서 Envoy 프록시는 애플리케이션 포드와 함께 실행됩니다.
envoy 컨테이너로 필터링된 애플리케이션 포드 로그에 오류가 표시됩니다.
클러스터에 워크로드 로깅이 사용 설정된 경우 Cloud Logging에 오류가 표시될 수 있습니다. 가능한 필터는 다음과 같습니다.
resource.type="K8S_CONTAINER" resource.labels.project_id="PROJECT_NAME" resource.labels.location="CLUSTER_ZONE" resource.labels.cluster_name="CLUSTER_NAME" resource.labels.namespace_name="WORKLOAD_NAMESPACE" labels.k8s-pod/app="WORKLOAD_NAME" resource.labels.container_name="envoy"
클러스터에서 워크로드 로깅이 사용 설정되지 않은 경우 다음과 같은 명령어를 사용하여 오류를 볼 수 있습니다.
kubectl logs $(kubectl get po -l app=WORKLOAD_NAME -o=jsonpath='{.items[0].metadata.name}') -c envoy --tail 50 #NOTE: This assumes the default namespace.또한 다음 필터를 사용하여 모든 클러스터와 모든 워크로드에서 실행 중인 모든 Envoy의 로그를 볼 수 있습니다.
resource.type="K8S_CONTAINER" resource.labels.container_name="envoy"
Compute Engine 및 수동 배포의 경우 설정 가이드에서 run.sh 스크립트를 실행하기 전에 LOG_DIR을 정의합니다.
예를 들면 다음과 같습니다.
LOG_DIR='/var/log/envoy/'
기본적으로 오류는 다음 로그에 표시됩니다.
/var/log/envoy/envoy.err.log
사용자가 Logging으로 내보내기 위한 추가 구성을 수행하지 않으면 SSH를 사용하여 인스턴스에 연결하고 이 파일을 가져오는 경우에만 오류가 표시됩니다.
자동 Envoy 배포를 사용하는 경우 로그 파일을 가져오도록 SSH를 사용하여 인스턴스에 연결할 수 있습니다. 이 경로는 앞에서 언급한 경로와 동일할 가능성이 높습니다.
프록시가 Traffic Director로 연결하지 않음
프록시가 Traffic Director로 연결하지 않는 경우 다음을 수행하세요.
Envoy 프록시 로그에
trafficdirector.googleapis.com연결 관련 오류가 있는지 확인합니다.모든 트래픽을 Envoy 프록시로 리디렉션하도록
iptables를 사용하여netfilter를 설정한 경우 프록시를 실행하는 사용자(UID)가 리디렉션에서 제외되는지 확인합니다. 그렇지 않으면 트래픽이 지속적으로 프록시로 되돌아갑니다.프로젝트에서 Traffic Director API를 사용 설정했는지 확인합니다. 프로젝트의 API 및 서비스에서 Traffic Director 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.9.1 이상인지 확인합니다.
Traffic Director로 구성된 서비스에 연결할 수 없습니다.
Traffic Director로 구성된 서비스에 연결할 수 없는 경우 사이드카 프록시가 실행 중이며 Traffic Director에 연결할 수 있는지 확인합니다.
Envoy를 사이드카 프록시로 사용하는 경우 다음 명령어를 실행하여 이를 확인할 수 있습니다.
명령줄에서 Envoy 프로세스가 실행 중인지 확인합니다.
ps aux | grep envoy
Envoy의 런타임 구성을 검사하여 Traffic Director에서 동적 리소스를 구성했는지 확인합니다. 구성을 보려면 다음 명령어를 실행합니다.
curl http://localhost:15000/config_dump
사이드카 프록시에 대한 트래픽 가로채기가 올바르게 설정되었는지 확인합니다.
iptables로 리디렉션을 설정하려면iptables명령어를 실행한 후 출력을grep하여 규칙이 있는지 확인합니다.sudo iptables -t nat -S | grep ISTIO
다음은 가상 IP 주소(VIP)
10.0.0.1/32를 가로채서 포트15001에 UID1006으로 전달하는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 액세스 로깅이 구성된 경우 서비스에 연결할 수 없습니다.
Traffic Director용 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 사용자가 액세스 로그에 작성할 수 있도록 선택한 파일의 권한을 변경합니다.
Traffic Director에 구성되지 않은 서비스에 애플리케이션을 연결할 수 없음
Traffic Director에 구성된 서비스의 IP 주소에 대해서만 트래픽 가로채기를 설정했는지 확인합니다. 모든 트래픽이 가로채기를 당하면 Traffic Director에서 구성하지 않은 서비스에 대한 연결이 사이드카 프록시에 의해 자동으로 삭제됩니다.
노드 내에서 트래픽이 루프하거나 노드가 비정상 종료됨
netfilter(iptables)가 모든 트래픽을 가로채도록 설정되어 있으면 사이드카 프록시를 실행하는 데 사용되는 사용자(UID)가 트래픽 가로채기에서 제외되어 있는지 확인합니다. 그렇지 않으면 사이드카 프록시에서 보낸 트래픽이 프록시에 무기한 루프됩니다. 따라서 사이드카 프록시 프로세스가 비정상 종료될 수 있습니다. 참조 구성에서 netfilter 규칙은 프록시 사용자의 트래픽을 가로채지 않습니다.
구성 문제를 표시하는 Envoy 로그의 오류 메시지
Traffic Director 구성에 문제가 있으면 Envoy 로그에 다음과 같은 오류 메시지가 표시될 수 있습니다.
warning envoy config StreamAggregatedResources gRPC config stream closed: 5, Traffic Director configuration was not found for network "VPC_NAME" in project "PROJECT_NUMBER".
warning envoy upstream StreamLoadStats gRPC config stream closed: 5, Traffic Director 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.
Traffic Director configuration was not found.
마지막 오류 메시지(Traffic Director configuration was not found)는 일반적으로 Envoy가 Traffic Director에서 구성을 요청하지만 일치하는 구성을 찾을 수 없음을 나타냅니다. Envoy가 Traffic Director에 연결하면 VPC 네트워크 이름(예: my-network)이 표시됩니다. 그런 다음 Traffic Director는 INTERNAL_SELF_MANAGED 부하 분산 스키마가 있고 동일한 VPC 네트워크 이름을 참조하는 전달 규칙을 찾습니다.
이 오류를 고치려면 다음 안내를 따르세요.
네트워크에 부하 분산 스킴
INTERNAL_SELF_MANAGED가 있는 전달 규칙이 있는지 확인합니다. 전달 규칙의 VPC 네트워크 이름을 기록합니다.Compute Engine에서 자동화된 Envoy 배포와 함께 Traffic Director를 사용하는 경우
--service-proxy:network플래그에 제공된 값이 전달 규칙의 VPC 네트워크 이름과 일치하는지 확인합니다.Compute Engine에서 수동 Envoy 배포와 함께 Traffic Director를 사용하는 경우 다음과 같이 Envoy 부트스트랩 파일을 확인합니다.
TRAFFICDIRECTOR_NETWORK_NAME변수 값이 전달 규칙의 VPC 네트워크 이름과 일치하는지 확인합니다.- 프로젝트 번호가
TRAFFICDIRECTOR_GCP_PROJECT_NUMBER변수에 설정되어 있는지 확인합니다.
GKE에 배포하고 자동 인젝터를 사용 중인 경우, 프로젝트 번호와 VPC 네트워크 이름이 자동 Envoy 삽입으로 GKE 포드에 대한 Traffic Director 설정의 안내에 따라 올바르게 구성되었는지 확인합니다.
Compute Engine 자동 배포 문제 해결
이 섹션에서는 Compute Engine의 자동 Envoy 배포 문제를 해결하기 위한 지침을 제공합니다.
Envoy 및 VM 부트스트랩 프로세스 및 추가 수명 주기 관리 작업은 일시적인 연결 문제, 저장소 손상, 부트스트랩 스크립트 및 VM 기반 에이전트의 버그, 예기치 않은 사용자 작업 등 여러 가지 이유로 실패할 수 있습니다.
문제 해결을 위한 커뮤니케이션 채널
Google Cloud는 부트스트랩 프로세스 및 VM에 있는 구성요소의 현재 상태를 이해하는 데 사용할 수 있는 통신 채널을 제공합니다.
가상 직렬 포트 출력 로깅
VM의 운영체제, BIOS, 기타 시스템 수준 항목은 일반적으로 직렬 포트에 출력을 작성합니다. 이 출력 결과는 시스템 장애, 부팅 실패, 시작 문제, 종료 문제를 해결하는데 유용합니다
Compute Engine 부트스트랩 에이전트는 수행된 모든 작업을 시스템 포트 1에 기록합니다. 여기에는 인스턴스의 메타데이터 서버, iptables 구성, Envoy 설치 상태로부터 데이터를 가져와 기본 패키지 설치부터 시작하는 시스템 이벤트가 포함됩니다.
VM 기반 에이전트는 Envoy 프로세스 상태 상태를 기록하며, 새로 발견된 Traffic Director 서비스와 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에서 Traffic Director 서비스에 연결할 수 없음
이 문제를 해결하려면 다음 단계를 수행합니다.
VM에 서비스 프록시 구성요소 설치가 완료되지 않았거나 실패했을 수 있습니다. 다음 명령어를 사용하여 모든 구성요소가 제대로 설치되었는지 확인합니다.
gcloud compute instances get-guest-attributes INSTANCE_NAME \ --query-path=gce-service-proxy/ \ --zone=ZONEbootstrap-status게스트 속성은 다음 중 하나로 설정됩니다.[none]은 설치가 아직 시작되지 않았음을 나타냅니다. VM이 아직 부팅 중일 수도 있습니다. 잠시 후 상태를 다시 확인해 보세요.IN PROGRESS는 서비스 프록시 구성요소의 설치 및 구성이 아직 완료되지 않았음을 나타냅니다. 프로세스 업데이트에 대한 상태 확인을 반복합니다.FAILED는 구성요소 설치 또는 구성이 실패했음을 나타냅니다.gce-service-proxy/bootstrap-last-failure속성을 쿼리하여 오류 메시지를 확인합니다.FINISHED는 설치 및 구성 프로세스가 오류 없이 완료되었음을 나타냅니다. 다음 안내에 따라 트래픽 가로채기와 Envoy 프록시가 올바르게 구성되었는지 확인합니다.
VM의 트래픽 가로채기가 Traffic Director 기반 서비스에 올바르게 구성되지 않았습니다. 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)에 대한 항목이 없으면 Traffic Director의 Envoy 프록시 구성을 채우는 데 문제가 있거나 VM 기반 에이전트가 실패한 것입니다.Envoy 프록시가 아직 Traffic Director로부터 구성을 받지 못했습니다. VM에 로그인하여 Envoy 프록시 구성을 확인합니다.
gcloud compute ssh INSTANCE_NAME \ --zone=ZONE \ sudo curl localhost:15000/config_dumpTraffic Director에서 수신된 리스너 구성을 살펴봅니다. 예를 들면 다음과 같습니다.
"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는 Traffic Director 서비스의 가상 IP 주소(VIP)입니다.td-routing-rule-1이라는 URL 맵을 가리킵니다. 연결하려는 서비스가 리스너 구성에 이미 포함되어 있는지 확인합니다.VM 기반 에이전트가 실행되고 있지 않습니다. VM 기반 에이전트는 새 Traffic Director 서비스가 생성될 때 트래픽 가로채기를 자동으로 구성합니다. 에이전트가 실행되고 있지 않으면 새 서비스에 대한 모든 트래픽이 Envoy 프록시와 타임아웃을 우회하여 VIP로 바로 전달됩니다.
다음 명령어를 실행하여 VM의 에이전트 상태를 확인합니다.
gcloud compute instances get-guest-attributes INSTANCE_NAME \ --query-path=gce-service-proxy/ \ --zone=ZONE
VM 기반 에이전트 속성을 검사합니다.
agent-heartbeat속성의 값에는 에이전트가 마지막으로 작업 또는 확인을 수행한 시간이 있습니다. 이 값이 5분을 초과하면 에이전트가 중단됩니다. 그러면 다음 명령어를 사용하여 VM을 다시 만들어야 합니다.gcloud compute instance-groups managed recreate-instance
agent-last-failure속성은 에이전트에서 마지막으로 발생한 오류를 노출합니다. 이는 다음 번에 에이전트가 해당 오류가Cannot reach the Traffic Director API server인지 혹은 영구적인 오류인지 확인할 때 해결되는 일시적인 문제일 수 있습니다. 몇 분 기다린 후에 오류를 다시 확인합니다.
워크로드 포트에 인바운드 트래픽 가로채기가 구성되어 있지만 VM 외부에서는 포트에 연결할 수 없음
이 문제를 해결하려면 다음 단계를 수행합니다.
VM에 서비스 프록시 구성요소 설치가 완료되지 않았거나 실패했을 수 있습니다. 다음 명령어를 사용하여 모든 구성요소가 제대로 설치되었는지 확인합니다.
gcloud compute instances get-guest-attributes INSTANCE_NAME \ --query-path=gce-service-proxy/ \ --zone=ZONEbootstrap-status게스트 속성은 다음 중 하나로 설정됩니다.[none]은 설치가 아직 시작되지 않았음을 나타냅니다. VM이 아직 부팅 중일 수도 있습니다. 잠시 후 상태를 다시 확인해 보세요.IN PROGRESS는 서비스 프록시 구성요소의 설치 및 구성이 아직 완료되지 않았음을 나타냅니다. 프로세스 업데이트에 대한 상태 확인을 반복합니다.FAILED는 구성요소 설치 또는 구성이 실패했음을 나타냅니다.gce-service-proxy/bootstrap-last-failure속성을 쿼리하여 오류 메시지를 확인합니다.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 프록시가 Traffic Director에서 인바운드 포트에 대한 구성을 아직 받지 못했습니다. VM에 로그인하여 Envoy 프록시 구성을 확인합니다.
gcloud compute ssh INSTANCE_NAME \ --zone=ZONE \ sudo curl localhost:15000/config_dumpTraffic Director에서받은 인바운드 리스너 구성을 찾습니다.
"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의 리스너 구성에 이미 포함되어 있는지 확인합니다.
GKE 포드의 자동 배포 문제 해결
이 섹션에서는 GKE 포드의 자동 Envoy 배포 문제를 해결하는 방법을 설명합니다.
자동 Envoy 삽입을 사용 설정한 후 포드가 시작되지 않음
애플리케이션 포드가 올바르게 시작되지 않는 경우도 있습니다. 이러한 경우는 방화벽 규칙이 제한된 비공개 GKE 클러스터를 사용할 때 발생할 수 있습니다.
비공개 GKE 클러스터와 함께 Traffic Director를 사용하려면 사이드카 인젝터 웹훅에 대한 추가 방화벽 규칙을 만들어야 합니다. GKE 제어 영역이 TCP 포트 9443의 포드에 도달하도록 허용하는 방화벽 규칙을 만들려면 특정 사용 사례를 위한 방화벽 규칙 추가를 참조하세요.
독립형 포드를 만들 때나 배포에서 포드를 만들 때 발생하는 문제를 확인할 수 있습니다.
독립형 포드를 만들 때(예: kubectl apply 또는 kubectl run 사용) kubectl 명령줄이 다음과 같은 오류 메시지를 반환할 수 있습니다.
Error from server (InternalError): Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-control.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
배포에서 포드를 만들 때 다음과 같은 증상이 나타날 수 있습니다.
kubectl get pods가 배포와 연결된 포드를 반환하지 않습니다.kubectl get events --all-namespaces가 다음과 같은 오류 메시지를 반환합니다.Warning FailedCreate 15s replicaset-controller Error creating: Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-control.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
설정 가이드를 따르면 먼저 샘플 클라이언트 배포 및 삽입 확인 단계에서 이 문제가 발생할 수 있습니다. kubectl create -f demo/client_sample.yaml를 실행한 후 kubectl get deploy busybox를 실행하여 0/1 READY 포드를 확인합니다. kubectl describe rs -l run=client 명령어를 실행하여 배포와 연결된 replicaset를 설명하여 오류를 찾을 수도 있습니다.
구성 확인 후 연결 거부
자동 Envoy 삽입으로 Traffic Director를 설정할 때 구성을 확인하려고 시도하면 연결 거부 오류가 표시될 수 있습니다. 원인은 다음 중 하나일 수 있습니다.
specs/01-configmap.yaml파일에서discoveryAddress의 값이 올바르지 않습니다. 값은trafficdirector.googleapis.com:443이어야 합니다.specs/01-configmap.yaml에서 VPC 네트워크의 값이 올바르지 않습니다.specs/01-configmap.yaml파일에서 Traffic Director 프로젝트의 값이 올바르지 않습니다.discoveryAddress의 값이 포드에서 잘못되었습니다.- Traffic Director 사이드카 인젝터 대신 Istio 사이드카 인젝터가 실행되고 있습니다.
specs/01-configmap.yaml 파일의 샘플은 사이드카 인젝터 구성에서 확인할 수 있습니다.
specs/01-configmap.yaml 파일에 올바른 값이 포함되지 않았으면 Envoy가 Traffic Director에서 수정 구성을 가져올 수 없습니다. 이 문제를 해결하려면 specs/01-configmap.yaml 파일을 검사하고 값이 올바른지 확인한 다음 자동 인젝터를 다시 만듭니다.
specs/01-configmap.yaml 파일 및 포드에서 discoveryAddress 값을 확인합니다. 포드에서 사이드카 인젝터가 값을 설정합니다. 포드에서 discoveryAddress의 값을 확인하려면 다음 명령어를 실행합니다.
kubectl get po $BUSYBOX_POD -o yaml|grep -Po '\"discoveryAddress\":\"[^,]*\"'
다음과 비슷한 출력이 표시됩니다.
"discoveryAddress":"trafficdirector.googleapis.com:443"
수동 Envoy 삽입 및 GKE 포드로 연결이 거부됨
연결 거부 메시지를 받으면 busybox 로그를 참조하여 Traffic Director API가 사용 설정되었는지 또는 Envoy 로그에서 권한이 올바르지 않은지 확인합니다.
수동 Envoy 삽입 및 GKE 포드 연결 시간 초과
연결 제한 시간 메시지가 수신되면 배포의 URL 맵, 전달 규칙 또는 백엔드 서비스가 잘못 구성되어 있을 가능성이 높습니다. 해당 리소스를 확인하여 리소스가 올바르게 구성되어 있는지 확인합니다.
연결에서 서버 우선 프로토콜을 사용할 때 발생하는 문제
MySQL과 같은 일부 애플리케이션은 서버가 첫 번째 패킷을 전송하는 프로토콜을 사용합니다. 즉, 최초 연결 시에 서버는 첫 번째 바이트를 보냅니다. 이러한 프로토콜 및 애플리케이션은 Traffic Director에서 지원되지 않습니다.
서비스 메시 상태 문제 해결
이 가이드에서는 Traffic Director 구성 문제를 해결하는 데 도움이 되는 정보를 제공합니다.
대부분의 엔드포인트가 비정상적인 경우 Traffic Director 동작
엔드포인트의 99%가 비정상이면 안정성을 높이기 위해 Traffic Director는 엔드포인트의 상태를 무시하도록 데이터 영역을 구성합니다. 대신 데이터 영역은 모든 엔드포인트 간에 트래픽을 분산하는데, 이는 제공된 포트가 계속 작동할 수 있기 때문입니다.
비정상 백엔드로 인해 트래픽 분산이 최적화되지 않음
Traffic Director는 백엔드 서비스에 연결된 HealthCheck 리소스의 정보를 사용하여 백엔드 상태를 평가합니다.
Traffic Director는 이 상태를 사용하여 트래픽을 가장 가까운 정상 백엔드로 라우팅합니다. 일부 백엔드가 비정상이면 트래픽이 계속 처리되더라도 분포가 최적이 아닐 수 있습니다. 예를 들어 트래픽이 정상 백엔드가 계속 있는 리전으로 전달될 수 있지만 클라이언트에서 멀리 떨어져 있어 지연 시간이 발생할 수 있습니다. 백엔드 상태를 식별하고 모니터링하려면 다음 단계를 수행합니다.
- Google Cloud Console에서 백엔드 서비스 상태를 점검합니다.
Traffic Director 서비스로 이동 HealthCheck리소스에 로깅이 사용 설정되어 있는지 확인합니다.- 상태 점검이 최근에 실패하기 시작했다면 Cloud 감사 로그를 검사하여
HealthCheck구성이 최근에 변경되었는지 확인합니다.
백엔드의 예기치 않은 트래픽 거부
Traffic Director 서비스 보안을 구성했으면 EndpointPolicy 리소스를 사용하여 보안 정책을 백엔드에 적용합니다.
EndpointPolicy 구성이 잘못되면 백엔드에서 트래픽이 거부될 수 있습니다.
이 시나리오 문제를 해결하려면 다음 로그를 사용합니다.
- Traffic Director에서 보고한 엔드포인트 정책 충돌이 있는지 확인합니다.
- Cloud 감사 로그를 검사하여 사용자 구성(특히
EndpointPolicy,ServerTlsPolicy또는AuthorizationPolicy)이 최근에 변경되었는지 확인합니다.
다음 단계
- Traffic Director의 작동 방식은 Traffic Director 개요를 참조하세요.
- 프록시리스 gRPC 서비스를 배포할 때 구성 문제를 해결하려면 프록시리스 gRPC를 사용하는 배포 문제 해결을 참조하세요.
- Traffic Director 사용에 대한 추가 지원을 확인하려면 지원 받기를 참조하세요.