서비스 간 통신 문제 해결

서비스 간 통신 문제 해결

이 주제는 Consul의 내장 서비스 간 문제 해결 기능에 대한 개요를 설명해요. 서비스 메시에서 업스트림 서비스와 다운스트림 서비스 사이의 통신이 실패하면 consul troubleshoot 명령으로 일련의 자동화된 검증 테스트를 시작할 수 있어요.

출처: 문서

본문

이 주제는 Consul의 내장 서비스 간 문제 해결 기능에 대한 개요를 설명합니다. 서비스 메시에서 업스트림 서비스와 다운스트림 서비스 사이의 통신이 실패하면 consul troubleshoot 명령을 실행해 일련의 자동화된 검증 테스트를 시작할 수 있습니다.

자세한 내용은 consul troubleshoot CLI documentation 또는 consul-k8s troubleshoot CLI reference을 참조하세요.

소개 (Introduction)

서비스 메시에서 업스트림 서비스와 다운스트림 서비스 사이의 통신이 실패하면 헬스 체크 쿼리, UI 토폴로지 보기, 에이전트 텔레메트리 메트릭을 포함한 하나 이상의 Consul 내장 기능으로 원인을 수동으로 진단할 수 있습니다.

consul troubleshoot 명령은 순서대로 몇 가지 검사를 수행하여 서비스 간 통신을 방해하는 문제를 발견할 수 있게 해줍니다. 이 과정은 Envoy 관리 인터페이스 API와 Consul API를 체계적으로 쿼리하여 통신 실패의 원인을 결정합니다.

문제 해결 명령은 다음 일반적인 문제를 확인하여 서비스 간 통신을 검증합니다.

• 업스트림 서비스가 존재하지 않음
• 두 호스트 중 하나 또는 둘 다 비정상(unhealthy)
• 필터가 업스트림 서비스에 영향을 줌
• CA에 만료된 mTLS 인증서가 있음
• 서비스에 만료된 mTLS 인증서가 있음

Consul은 이러한 검증 검사의 결과를 서비스 통신 실패를 해결하기 위한 제안된 작업과 함께 터미널에 출력합니다. 거부된 구성이나 연결 실패를 감지하면 Consul은 서비스에 대한 Envoy 메트릭도 출력합니다.

서비스 메시의 Envoy 프록시

Consul은 업스트림 및 다운스트림 서비스의 사이드카로 배포된 Envoy 프록시를 확인하여 서비스 메시의 통신을 검증합니다. 결과적으로 문제 해결에는 Consul의 서비스 메시 기능이 활성화되어 있어야 합니다.

Consul과 함께 Envoy 프록시를 사용하는 방법에 대한 자세한 내용은 Envoy proxy configuration for service mesh을 참조하세요.

요구 사항 (Requirements)

• Consul v1.15 이상.
• Kubernetes의 경우 consul-k8s CLI가 설치되어 있어야 합니다.

기술적 제약 (Technical constraints)

서비스 간 통신 문제를 해결할 때 다음 제약 조건에 유의하세요.

• 문제 해결 도구는 서비스 의도(intentions)를 확인하지 않습니다. 우선순위와 일치 순서를 포함한 의도에 대한 자세한 내용은 service mesh intentions을 참조하세요.
• 문제 해결 도구는 다운스트림 서비스와 업스트림 서비스 사이의 하나의 직접 연결을 검증합니다. 각 개별 업스트림 서비스의 Envoy ID로 consul troubleshoot 명령을 실행해야 합니다. 여러 연결을 동시에 검증하는 것은 지원하지 않습니다.
• 문제 해결 도구는 사이드카 프록시에 대한 Envoy 구성만 검증합니다. 결과적으로 메시 게이트웨이와 종료 게이트웨이 같은 업스트림 프록시의 Envoy 구성은 검증하지 않습니다.

사용법 (Usage)

서비스 간 문제 해결 도구를 사용하는 것은 두 단계 과정입니다.

1. 업스트림 서비스의 식별자를 찾습니다.
2. 업스트림 ID를 사용해 통신을 검증합니다.

투명 프록시가 없는 배포에서 식별자는 업스트림 서비스의 사이드카 프록시에 대한 Envoy ID입니다. 투명 프록시를 사용하면 식별자는 업스트림 서비스의 IP 주소입니다. 투명 프록시 사용에 대한 자세한 내용은 Enable transparent proxy mode을 참조하세요.

VM에서 문제 해결

VM이나 베어메탈 서버를 사용하는 배포에서 서비스 간 통신 문제를 해결하려면:

1. 통신 실패를 겪고 있는 서비스에 대한 업스트림 정보를 검색하려면 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.
   

2. consul troubleshoot proxy 명령을 실행하고 -upstream-ip 플래그로 Envoy ID 또는 IP 주소를 지정해 문제 해결 과정을 수행할 프록시를 식별하세요. 다음 예시는 업스트림 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 주소에 따라 서비스 인스턴스를 식별합니다. 실패하는 서비스의 DNS 정보를 사용해 서비스 인스턴스에 영향을 주는 특정 문제를 진단하세요.

자세한 내용은 consul troubleshoot CLI documentation을 참조하세요.

Kubernetes에서 문제 해결

Kubernetes를 사용하는 배포에서 서비스 간 통신 문제를 해결하려면 통신 실패를 겪고 있는 pod에 대한 업스트림 정보를 검색하고 업스트림 정보를 사용해 문제 해결 과정을 수행할 프록시를 식별하세요.

1. consul-k8s troubleshoot upstreams 명령을 실행하고 -pod 플래그로 pod ID를 지정해 업스트림 정보를 검색하세요. 네트워크 구성에 따라 업스트림 정보는 Envoy ID 또는 IP 주소입니다. 다음 예시는 주어진 pod에서 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.
   

2. consul-k8s troubleshoot proxy 명령을 실행하고 pod ID와 업스트림 IP 주소를 지정해 문제 해결할 프록시를 식별하세요. 다음 예시는 업스트림 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 주소에 따라 서비스 인스턴스를 식별합니다. 실패하는 서비스의 DNS 정보를 사용해 서비스 인스턴스에 영향을 주는 특정 문제를 진단하세요.

자세한 내용은 consul-k8s troubleshoot CLI reference을 참조하세요.

더 알아보기 (Learn more)

• consul troubleshoot CLI 문서
• Consul 서비스 메시