Kubernetes용 Consul DNS 뷰

Kubernetes용 Consul DNS 뷰 (Consul DNS Views for Kubernetes)

이 페이지는 Kubernetes 파드에서 전용 Consul DNS 프록시를 스케줄링해 Kubernetes의 애플리케이션이 Consul DNS 주소를 해석할 수 있게 하는 방법을 설명해요.

출처: 문서

본문

이 페이지는 Kubernetes 파드에서 전용 Consul DNS 프록시를 스케줄링해 Kubernetes의 애플리케이션이 Consul DNS 주소를 해석할 수 있게 하는 방법을 설명해요. Consul DNS 프록시를 사용하면 Consul 클라이언트 에이전트를 배포할 필요 없이 Kubernetes 배포에서 관리 파티션 간 서비스 디스커버리를 활성화할 수 있어요.

소개 (Introduction)

Kubernetes 운영자는 일반적으로 서비스 디스커버리 작업에 kube-dns나 CoreDNS 같은 네트워킹 도구를 선택하고 Consul DNS를 완전히 우회하기로 선택해요. 이러한 DNS 옵션은 단일 Kubernetes 클러스터 내 서비스 네트워킹 작업에 종종 충분해요.

Kubernetes용 Consul은 Kubernetes가 Consul DNS를 해석하도록 구성하는 것을 지원해요. 그러나 이러한 구성에 의존할 때 두 가지 일반적인 문제가 발생해요:

  • Consul DNS를 활성화하려면 Kubernetes가 에이전트나 데이터플레인과 가십 통신을 사용해야 해요.
  • Consul은 관리 파티션이 DNS 주소에 포함되어야 해요. 그렇지 않으면 DNS 쿼리는 기본적으로 default 파티션을 가정해요.

consul-dns 프록시는 Consul 클라이언트 에이전트나 Consul 데이터플레인의 존재를 요구하지 않으므로 Kubernetes에서 Consul DNS의 요구 사항인 가십 통신을 제거해요. 이 프록시는 외부 서버가 활성화된 Kubernetes 클러스터에 배포하도록 설계되었어요. 클러스터가 기본이 아닌 관리 파티션에서 실행되고 프록시를 사용해 외부 서버를 쿼리할 때 Consul은 요청을 시작한 관리 파티션을 자동으로 인식하고 해당 특정 관리 파티션으로 범위가 지정된 서비스 디스커버리 결과를 반환해요.

Kubernetes에서 서비스 디스커버리에 Consul DNS를 사용하려면 Consul DNS를 해석해야 하는 각 Kubernetes 파드에 dns-proxy 서비스를 배포해요. Kubernetes는 먼저 모든 DNS 요청을 Kubernetes 컨트롤러로 보내요. 컨트롤러는 .consul 도메인에 대한 요청을 dns-proxy 서비스로 전달하고, 프록시는 Consul 카탈로그를 쿼리해 서비스 디스커버리 결과를 반환해요.

워크플로 (Workflows)

Kubernetes 배포에서 서비스 디스커버리를 위해 Consul DNS 뷰를 활성화하는 과정은 다음 단계로 구성돼요:

  1. 외부 Consul 서버를 사용하도록 구성된 클러스터에서 dns.proxy.enabled=true가 되도록 Consul on Kubernetes 배포의 Helm 값을 업데이트해요. 업데이트된 구성을 적용하면 Kubernetes가 Consul DNS 프록시를 배포해요.
  2. Kubernetes 클러스터에서 Consul DNS 프록시의 IP 주소를 조회해요.
  3. .consul 도메인에 대한 요청을 Consul DNS 프록시의 IP 주소로 전달하도록 Kubernetes 클러스터의 ConfigMap 리소스를 업데이트해요.

이 워크플로에 설명된 기본 개념에 대한 자세한 내용은 DNS 전달 개요를 참고해요.

OpenShift 클러스터 (OpenShift clusters)

OpenShift 배포에서 서비스 디스커버리를 위해 Consul DNS 뷰를 활성화하는 과정은 Kubernetes 클러스터의 과정과 유사해요. 다음 단계를 완료해요:

  1. OpenShift 클러스터에서 Consul DNS 프록시의 IP 주소를 조회해요.
  2. .consul 도메인에 대한 요청을 Consul DNS 서비스의 K8s 클러스터 IP 주소로 전달하도록 OpenShift 클러스터의 기본 DNS Operator 구성을 업데이트해요.
  3. 선택적으로 DNS 리졸버를 테스트해 올바르게 구성되었는지 확인해요.

이점 (Benefits)

Kubernetes용 Consul은 현재 기본적으로 Consul 데이터플레인을 사용해요. 이 가벼운 프로세스는 서비스 메시의 사이드카 프록시에 Consul 접근을 제공하지만 대부분의 다른 서비스 디스커버리 및 서비스 메시 작업은 Kubernetes가 담당하게 해요.

  • 단일 배포에서 Kubernetes DNS와 Consul DNS 사용. Consul DNS 프록시는 기본 Kubernetes DNS 기능을 방해하지 않고 파드의 모든 애플리케이션이 Consul DNS를 통해 주소를 해석할 수 있게 해요.
  • 더 적은 리소스로 Consul 서비스 디스커버리. 서비스 디스커버리에 Consul DNS 프록시를 사용하면 Consul 클라이언트 에이전트나 데이터플레인을 사이드카로 스케줄링할 필요가 없어요. 단일 Consul 데이터플레인과 동일한 리소스를 사용하는 하나의 Kubernetes 서비스가 파드에 Consul 서비스 카탈로그 접근을 제공해요.
  • 가십 통신 없는 Consul DNS. Consul DNS 서비스는 가십 통신을 사용해 서비스 디스커버리 결과가 최신 상태인지 확인하는 Consul 서버 및 클라이언트 에이전트 모두에서 실행돼요. Consul DNS 프록시는 에이전트 간 가십의 보안 오버헤드 없이 Consul DNS에 접근을 제공해요.

제약 및 한계 (Constraints and limitations)

Kubernetes용 Consul DNS 프록시를 사용할 때 문제가 발생하면 다음 기술적 제약 및 한계 목록을 참고해요:

  • Consul DNS 프록시를 사용하려면 런타임으로 Kubernetes를 사용해야 해요. 다른 컨테이너 기반 환경에서는 Consul DNS 프록시를 스케줄링할 수 없어요.
  • 다른 관리 파티션에 대한 DNS 조회를 수행하려면 쿼리하기 전에 파티션 간 서비스 내보내기를 먼저 해야 해요.

더 알아보기 (Learn more)