가상 서비스로 트래픽 라우팅

Kubernetes의 Consul이 Envoy 프록시에 대해 투명 프록시 모드가 활성화되었을 때 가상 서비스로 트래픽을 라우팅할 수 있도록 가상 서비스를 정의하는 방법을 설명해 드릴게요.

출처: 문서

본문

이 문서는 투명 프록시 모드가 Envoy 프록시에 대해 활성화된 경우 Kubernetes의 Consul이 가상 서비스로 트래픽을 라우팅할 수 있도록 가상 서비스를 정의하는 방법을 설명해요.

개요

service resolver 구성 엔트리에서 가상 서비스를 정의하여 다운스트림 애플리케이션이 피어링된 클러스터에서 Consul DNS 이름을 사용해 가상 서비스에 요청을 보낼 수 있게 할 수 있어요. 애플리케이션은 KubeDNS를 사용하여 같은 클러스터의 가상 서비스에 요청을 보낼 수 있어요. Service resolver는 서비스 메시 프록시 업스트림 디스커버리 체인의 일부예요. 자세한 내용은 서비스 메시 트래픽 관리를 참고해 주세요.

프록시가 투명 프록시 모드일 때 Kubernetes의 Consul에서 장애 조치 서비스 인스턴스를 구성하려면 다음 단계를 완료해 주세요:

service resolver 구성 엔트리를 만들어요.
다운스트림 서비스가 실제 서비스와 가상 서비스에 접근할 수 있게 하는 의도(intentions)를 만들어요.
Consul DNS 또는 KubeDNS를 사용하여 디스커버리 체인을 호출하도록 애플리케이션을 구성해요.

요구 사항

consul-k8s v1.2.0 이상.
Consul 서비스 메시가 활성화되어야 해요. Kubernetes에서 Consul 서비스 메시가 어떻게 작동하나요를 참고해 주세요.
프록시가 투명 프록시 모드로 실행되도록 구성되어야 해요.
가상 DNS 이름을 쿼리하려면 Consul DNS를 사용해야 해요.
KubeDNS를 사용하여 디스커버리 체인을 쿼리하려면 service resolver가 실행 중인 서비스와 같은 파티션에 있어야 해요.

ACL 요구 사항

Consul Helm 차트가 구성하는 기본 ACL은 대부분의 경우에 적합하지만, Consul API 접근에 대한 더 복잡한 보안 정책이 있다면 자세한 지침은 ACL 문서를 참고해 주세요.

service resolver 구성 엔트리 생성

service resolver 구성 엔트리의 spec.redirect.service 필드에 대상 장애 조치를 지정해 주세요. 다음 예시에서 virtual-api 서비스는 real-api로 리다이렉트하도록 구성돼요:

virtual-api-redirect.yaml

apiversion: consul.hashicorp.com/v1alpha1
kind: ServiceResolver
metadata:
 name: virtual-api
spec:
 redirect:
   service: real-api

모든 service resolver 구성에 대한 정보는 service resolver 구성 엔트리 참조 문서를 참고해 주세요.

kubectl apply 명령으로 구성을 적용할 수 있어요:

$ kubectl apply -f virtual-api-redirect.yaml

서비스 의도 생성

의도가 아직 정의되지 않았다면 적절한 다운스트림이 실제 서비스와 대상 리다이렉트 서비스에 접근할 수 있게 하는 의도를 만들고 적용해 주세요. 다음 예시에서 frontend 서비스는 virtual-api 및 real-api 서비스에 메시지를 보낼 수 있게 허용돼요:

frontend-api-api-beta-allow.yaml

apiversion: consul.hashicorp.com/v1alpha1
kind: ServiceIntentions
metadata:
 name: virtual-api
spec:
 destination:
   name: virtual-api
 sources:
   - name: frontend
     action: allow
---
apiversion: consul.hashicorp.com/v1alpha1
kind: ServiceIntentions
metadata:
 name: real-api
spec:
 destination:
   name: real-api
 sources:
   - name: frontend
     action: allow

서비스 의도 구성에 대한 자세한 내용은 service intentions 구성 엔트리 참조를 참고해 주세요.

kubectl apply 명령으로 구성을 적용할 수 있어요:

$ kubectl apply -f frontend-api-api-beta-allow.yaml

DNS 호출을 위한 애플리케이션 구성

Consul DNS 또는 KubeDNS에서 디스커버리 체인에 연결하도록 애플리케이션을 구성해 주세요.

Consul DNS

<service>.virtual.consul 조회 형식을 사용하여 Consul DNS를 쿼리할 수 있어요. Consul Enterprise의 경우 쿼리 문자열에 네임스페이스, 파티션 또는 둘 다 포함해야 할 수 있어요. 가상 서비스 조회를 구성하는 방법에 대한 자세한 내용은 DNS 문서를 참고해 주세요.

다음 예시에서 애플리케이션은 HTTP를 통해 virtual-api에 대해 Consul 카탈로그를 쿼리해요. 기본적으로 조회는 Consul Enterprise가 네트워크 인프라를 관리한다면 default 파티션과 default 네임스페이스를 쿼리해요:

http://virtual-api.virtual.consul/

KubeDNS

실제 서비스와 가상 서비스가 동일한 Kubernetes 클러스터에 있다면 서비스 이름을 지정하여 KubeDNS를 쿼리할 수 있어요. 다음 예시에서 애플리케이션은 HTTP를 통해 virtual-api에 대해 KubeDNS를 쿼리해요:

http://virtual-api.<namespace>.svc.cluster.local

해당 Kubernetes 서비스와 pod가 존재하지 않으면 KubeDNS를 사용할 수 없다는 점에 유의해 주세요.

가상 서비스로 트래픽 라우팅