서비스 간 통신 문제 해결
서비스 간 통신 문제 해결 (Troubleshoot service-to-service communication)
이 문서는 consul troubleshoot CLI 명령으로 서비스 메시의 서비스 간 통신 문제를 진단하는 방법을 알려드릴게요. 업스트림 식별자 찾기부터 검증까지 단계별로 따라 할 수 있어요.
출처: 문서
본문
이 페이지는 consul troubleshoot CLI 명령을 사용하여 서비스 메시에서 서비스 간 통신 문제를 해결하는 과정을 설명합니다.
자세한 내용은 consul troubleshoot CLI 문서 [/consul/commands/troubleshoot] 또는 consul-k8s troubleshoot CLI 참조 [/consul/docs/reference/cli/consul-k8s#troubleshoot]를 참조하세요.
소개 (Introduction)
서비스 메시에서 업스트림과 다운스트림 서비스 간 통신이 실패하면 헬스 체크 쿼리 [/consul/docs/register/health-check/vm], UI 토폴로지 보기 [/consul/docs/observe/telemetry/vm], 에이전트 텔레메트리 메트릭 [/consul/docs/reference/agent/telemetry]을 포함한 Consul 내장 기능 중 하나 이상을 사용하여 원인을 수동으로 진단할 수 있습니다.
consul troubleshoot 명령은 서비스 간 통신을 방해하는 문제를 발견할 수 있도록 여러 검사를 순서대로 수행합니다. 이 과정은 Envoy 관리 인터페이스 API [https://www.envoyproxy.io/docs/envoy/latest/operations/admin]와 Consul API를 체계적으로 쿼리하여 통신 실패의 원인을 파악합니다.
트러블슈팅 명령은 다음 일반적인 문제를 확인하여 서비스 간 통신을 검증합니다:
- 업스트림 서비스가 존재하지 않음
- 두 호스트 중 하나 또는 둘 다 비정상(unhealthy)임
- 필터가 업스트림 서비스에 영향을 줌
- CA가 만료된 mTLS 인증서를 가짐
- 서비스가 만료된 mTLS 인증서를 가짐
Consul은 이러한 검증 결과를 제안된 조치와 함께 터미널에 출력하여 서비스 통신 실패를 해결하도록 돕습니다. 거부된 구성이나 연결 실패를 감지하면 Consul은 서비스에 대한 Envoy 메트릭도 출력합니다.
서비스 메시의 Envoy 프록시 (Envoy proxies in a service mesh)
Consul은 업스트림 및 다운스트림 서비스의 사이드카로 배포된 Envoy 프록시를 확인하여 서비스 메시의 통신을 검증합니다. 따라서 트러블슈팅을 위해서는 Consul의 서비스 메시 기능이 활성화 [/consul/docs/fundamentals/config-entry]되어 있어야 합니다.
Consul과 함께 Envoy 프록시를 사용하는 방법에 대한 자세한 내용은 서비스 메시용 Envoy 프록시 구성 [/consul/docs/reference/proxy/envoy]을 참조하세요.
요구 사항 (Requirements)
- Consul v1.15 이상.
- Kubernetes의 경우
consul-k8sCLI가 설치되어 있어야 합니다.
기술적 제약 (Technical constraints)
서비스 간 통신 문제를 해결할 때 다음 제약 사항을 인지하세요:
- 트러블슈팅 도구는 서비스 인텐션(intention)을 확인하지 않습니다. 우선 순위와 매칭 순서를 포함한 인텐션에 대한 자세한 내용은 서비스 메시 인텐션 [/consul/docs/secure-mesh/intention]을 참조하세요.
- 트러블슈팅 도구는 다운스트림 서비스와 업스트림 서비스 간의 하나의 직접 연결만 검증합니다. 개별 업스트림 서비스에 대한 Envoy ID로
consul troubleshoot명령을 실행해야 합니다. 여러 연결을 동시에 검증하는 것은 지원하지 않습니다. - 트러블슈팅 도구는 사이드카 프록시에 대한 Envoy 구성만 검증합니다. 결과적으로 메시 게이트웨이나 종료 게이트웨이 같은 업스트림 프록시의 Envoy 구성은 검증하지 않습니다.
사용법 (Usage)
서비스 간 트러블슈팅 도구를 사용하는 것은 두 단계로 이루어집니다:
- 업스트림 서비스의 식별자를 찾습니다.
- 업스트림의 식별자를 사용하여 통신을 검증합니다.
투명 프록시가 없는 배포에서 식별자는 업스트림 서비스 사이드카 프록시의 Envoy ID입니다. 투명 프록시를 사용하는 경우 식별자는 업스트림 서비스의 IP 주소입니다. 투명 프록시 사용에 대한 자세한 내용은 투명 프록시 모드 활성화 [/consul/docs/k8s/connect/transparent-proxy]를 참조하세요.
요구 사항 (Requirements)
- Consul v1.15 이상.
- Kubernetes의 경우
consul-k8sCLI가 설치되어 있어야 합니다.
VM에서 문제 해결 (Troubleshoot on VMs)
VM 또는 베어메탈 서버를 사용하는 배포에서 서비스 간 통신 문제를 해결하려면 다음을 수행합니다:
- 통신 실패가 발생하는 서비스에 대한 업스트림 정보를 검색하려면
consul troubleshoot upstreams명령을 실행합니다. 네트워크 구성에 따라 업스트림 정보는 Envoy ID 또는 IP 주소입니다.
$ consul troubleshoot upstreams
==> Upstreams (explicit upstreams only) (0)
==> Upstreams IPs (transparent proxy only) (1)
[10.4.6.160 240.0.0.3] true map[backend.default.dc1.internal.e08fa6d6-e91e-dfe0-f6e1-ba097a828e31.consul backend2.default.dc1.internal.e08fa6d6-e91e-dfe0-f6e1-ba097a828e31.consul]
If you cannot find the upstream address or cluster for a transparent proxy upstream:
- Check intentions: Tproxy upstreams are configured based on intentions. Make sure you have configured intentions to allow traffic to your upstream.
- To check that the right cluster is being dialed, run a DNS lookup for the upstream you are dialing. For example, run `dig backend.svc.consul` to return the IP address for the `backend` service. If the address you get from that is missing from the upstream IPs, it means that your proxy may be misconfigured.
- 트러블슈팅 프로세스를 수행할 프록시를 식별하기 위해
-upstream-ip플래그와 함께 Envoy ID 또는 IP 주소를 지정하여consul troubleshoot proxy명령을 실행합니다. 다음 예시는 업스트림 IP를 사용하여 업스트림 서비스backend와의 통신을 검증합니다:
$ consul troubleshoot proxy -upstream-ip 10.4.6.160
==> Validation
✓ Certificates are valid
✓ Envoy has 0 rejected configurations
✓ Envoy has detected 0 connection failure(s)
✓ Listener for upstream "backend" found
✓ Route for upstream "backend" found
✓ Cluster "backend.default.dc1.internal.e08fa6d6-e91e-dfe0-f6e1-ba097a828e31.consul" for upstream "backend" found
✓ Healthy endpoints for cluster "backend.default.dc1.internal.e08fa6d6-e91e-dfe0-f6e1-ba097a828e31.consul" for upstream "backend" found
✓ Cluster "backend2.default.dc1.internal.e08fa6d6-e91e-dfe0-f6e1-ba097a828e31.consul" for upstream "backend" found
! No healthy endpoints for cluster "backend2.default.dc1.internal.e08fa6d6-e91e-dfe0-f6e1-ba097a828e31.consul" for upstream "backend" found
-> Check that your upstream service is healthy and running
-> Check that your upstream service is registered with Consul
-> Check that the upstream proxy is healthy and running
-> If you are explicitly configuring upstreams, ensure the name of the upstream is correct
예시 출력에서 업스트림 통신 문제를 해결하면 backend 서비스가 데이터센터 dc1에 두 개의 서비스 인스턴스를 실행하고 있음을 알 수 있습니다. 한 서비스는 정상이지만 Consul은 두 번째 서비스 인스턴스에 대한 정상 엔드포인트를 감지할 수 없습니다. 이 정보는 예시의 다음 줄에 나타납니다:
✓ Cluster "backend.default.dc1.internal.e08fa6d6-e91e-dfe0-f6e1-ba097a828e31.consul" for upstream "backend" found
✓ Healthy endpoints for cluster "backend.default.dc1.internal.e08fa6d6-e91e-dfe0-f6e1-ba097a828e31.consul" for upstream "backend" found
✓ Cluster "backend2.default.dc1.internal.e08fa6d6-e91e-dfe0-f6e1-ba097a828e31.consul" for upstream "backend" found
! No healthy endpoints for cluster "backend2.default.dc1.internal.e08fa6d6-e91e-dfe0-f6e1-ba097a828e31.consul" for upstream "backend" found
트러블슈팅 프로세스의 출력은 서비스 인스턴스를 Consul DNS 주소 [/consul/docs/services/discovery/dns-static-lookups#standard-lookup]에 따라 식별합니다. 실패하는 서비스의 DNS 정보를 사용하여 해당 서비스 인스턴스에 영향을 주는 특정 문제를 진단하세요.
자세한 내용은 consul troubleshoot CLI 문서 [/consul/commands/troubleshoot]를 참조하세요.
Kubernetes에서 문제 해결 (Troubleshoot on Kubernetes)
Kubernetes를 사용하는 배포에서 서비스 간 통신 문제를 해결하려면 통신 실패가 발생하는 포드(pod)에 대한 업스트림 정보를 검색하고 그 업스트림 정보를 사용하여 트러블슈팅 프로세스를 수행할 프록시를 식별합니다.
-pod플래그와 함께 포드 ID를 지정하여consul-k8s troubleshoot upstreams명령을 실행하여 업스트림 정보를 검색합니다. 네트워크 구성에 따라 업스트림 정보는 Envoy ID 또는 IP 주소입니다. 다음 예시는 주어진 포드에서 Consul 서비스 메시의 모든 투명 프록시 업스트림을 표시합니다.
$ consul-k8s troubleshoot upstreams -pod frontend-767ccfc8f9-6f6gx
==> Upstreams (explicit upstreams only) (0)
==> Upstreams IPs (transparent proxy only) (1)
[10.4.6.160 240.0.0.3] true map[backend.default.dc1.internal.e08fa6d6-e91e-dfe0-f6e1-ba097a828e31.consul backend2.default.dc1.internal.e08fa6d6-e91e-dfe0-f6e1-ba097a828e31.consul]
If you cannot find the upstream address or cluster for a transparent proxy upstream:
- Check intentions: Tproxy upstreams are configured based on intentions. Make sure you have configured intentions to allow traffic to your upstream.
- To check that the right cluster is being dialed, run a DNS lookup for the upstream you are dialing. For example, run `dig backend.svc.consul` to return the IP address for the `backend` service. If the address you get from that is missing from the upstream IPs, it means that your proxy may be misconfigured.
- 트러블슈팅할 프록시를 식별하려면 포드 ID와 업스트림 IP 주소를 지정하여
consul-k8s troubleshoot proxy명령을 실행합니다. 다음 예시는 업스트림 IP를 사용하여 업스트림 서비스backend와의 통신을 검증합니다:
$ consul-k8s troubleshoot proxy -pod frontend-767ccfc8f9-6f6gx -upstream-ip 10.4.6.160
==> Validation
✓ certificates are valid
✓ Envoy has 0 rejected configurations
✓ Envoy has detected 0 connection failure(s)
✓ listener for upstream "backend" found
✓ route for upstream "backend" found
✓ cluster "backend.default.dc1.internal..consul" for upstream "backend" found
✓ healthy endpoints for cluster "backend.default.dc1.internal.e08fa6d6-e91e-dfe0-f6e1-ba097a828e31.consul" for upstream "backend" found
✓ cluster "backend2.default.dc1.internal..consul" for upstream "backend" found
! no healthy endpoints for cluster "backend2.default.dc1.internal.e08fa6d6-e91e-dfe0-f6e1-ba097a828e31.consul" for upstream "backend" found
예시 출력에서 업스트림 통신 문제를 해결하면 backend 서비스가 데이터센터 dc1에 두 개의 클러스터를 가지고 있음을 알 수 있습니다. 한 클러스터는 정상 엔드포인트를 반환하지만 Consul은 두 번째 클러스터에 대한 정상 엔드포인트를 감지할 수 없습니다. 이 정보는 예시의 다음 줄에 나타납니다:
✓ cluster "backend.default.dc1.internal..consul" for upstream "backend" found
✓ healthy endpoints for cluster "backend.default.dc1.internal.e08fa6d6-e91e-dfe0-f6e1-ba097a828e31.consul" for upstream "backend" found
✓ cluster "backend2.default.dc1.internal..consul" for upstream "backend" found
! no healthy endpoints for cluster "backend2.default.dc1.internal.e08fa6d6-e91e-dfe0-f6e1-ba097a828e31.consul" for upstream "backend" found
트러블슈팅 프로세스의 출력은 서비스 인스턴스를 Consul DNS 주소 [/consul/docs/k8s/dns/enable]에 따라 식별합니다. 실패하는 서비스의 DNS 정보를 사용하여 해당 서비스 인스턴스에 영향을 주는 특정 문제를 진단하세요.
자세한 내용은 consul-k8s troubleshoot CLI 참조 [/consul/docs/reference/cli/consul-k8s#troubleshoot]를 참조하세요.