NGINX Ingress Controller를 사용한 다중 클러스터 DNS 자동화

사용자가 애플리케이션을 찾을 수 없다면 해당 애플리케이션은 본래 목적을 달성할 수 없습니다. 도메인 이름 시스템(DNS)은 도메인 이름을 IP 주소로 변환하여 앱과 웹사이트를 "찾는" 인터넷 기술입니다. DNS는 너무나 널리 퍼져 있고 안정적이어서 대부분의 날에는 그것에 대해 생각조차 하지 않습니다. 하지만 DNS 문제가 발생하면 모든 것이 중단됩니다. 최신 애플리케이션의 경우 DNS가 제대로 작동하는지 확인하는 것이 매우 중요하며, 특히 서비스가 지속적으로 작동하거나 중단되는 마이크로서비스 아키텍처의 경우 더욱 그렇습니다.

이전 게시물 에서는 동일한 클러스터에서 실행되는 애플리케이션( 마케팅 앱의 경우 unit-demo.marketing.net , 엔지니어링 앱의 경우 unit-demo.engineering.net )에 해당하는 두 개의 하위 도메인에 대한 DNS 레코드를 정의하는 방법에 대해 설명했습니다. 이 레코드는 동일한 클러스터 진입점(즉, 클러스터의 NGINX Ingress Controller의 외부 IP 주소)으로 확인됩니다. SNI(서버 이름 표시) 라우팅은 NGINX Ingress Controller에 구성되어 사용자가 요청한 도메인 이름에 따라 적절한 애플리케이션으로 연결을 인증하고 라우팅합니다.

그러나 많은 조직에서는 해당 사용 사례를 확장하여 여러 클라우드 공급업체 지역에 분산되어 있을 수 있는 여러 Kubernetes 클러스터에 애플리케이션을 배포해야 합니다. 외부 트래픽이 새로운 클러스터 지역에 도달하려면 해당 지역을 확인하는 DNS 영역을 만들어야 합니다.

이전에는 이 프로세스를 위해 타사 공급자(예: GoDaddy 또는 DNSExit)를 사용하여 수동으로 도메인 레지스트리를 만들고 호스트 레코드를 적절히 업데이트해야 했습니다. 이제 ExternalDNS Kubernetes 프로젝트는 Kubernetes 리소스를 공개 DNS 서버를 통해 검색할 수 있게 하여 프로세스를 자동화합니다. 즉, Kubernetes API를 사용하여 DNS 공급자 목록을 구성한다는 의미입니다.

ExternalDNS와 NGINX Ingress Controller를 통합하면 DNS 이름이 표준 Kubernetes Ingress 리소스 또는 NGINX VirtualServer 사용자 정의 리소스에 선언된 호스트 이름에서 파생되도록 DNS A 레코드를 관리할 수 있습니다. 개발자와 DevOps 팀은 CI/CD 파이프라인에서 이러한 통합을 활용하여 NetOps 팀(일반적으로 DNS를 소유)의 도움 없이 여러 클러스터에서 애플리케이션을 자동으로 검색할 수 있습니다.

이 게시물에서는 GitHub 저장소 의 샘플 구성 파일을 사용하여 ExternalDNS를 NGINX Ingress Controller와 통합하는 방법을 보여드립니다.

기본 아키텍처

NGINX Ingress Controller로 ExternalDNS를 구현하려면 먼저 개발자가 Kubernetes 앱을 외부에 노출하도록 Ingress 컨트롤러를 구성하는 기본 사례부터 시작합니다. 구성된 도메인 이름이 Kubernetes 클러스터의 공개 진입점으로 확인될 때까지 클라이언트는 앱에 연결할 수 없습니다.

NGINX Ingress Controller는 중개자 ExternalDNS Kubernetes 배포를 통해 DNS 공급자와 상호 작용하여 외부 DNS 레코드를 사용하여 Kubernetes 애플리케이션을 자동으로 검색할 수 있습니다. 다이어그램에서 검은색 선은 외부 사용자가 Kubernetes 클러스터의 애플리케이션에 액세스하는 데이터 경로를 나타냅니다. 보라색 선은 앱 소유자가 NGINX Ingress Controller 구성에서 VirtualServer 리소스를 사용하여 외부 DNS 레코드를 관리하고 외부 DNS가 DNS 공급자에 액세스하는 제어 경로를 나타냅니다.

ExternalDNS와 NGINX Ingress Controller 통합

ExternalDNS와 NGINX Ingress Controller를 통합하려면 다음 섹션의 단계를 수행하세요.

• 필수 조건
• NGINX Ingress Controller 및 ExternalDNS 배포
• NGINX Ingress 컨트롤러 구성

필수 조건

1. 최소한 하나 이상의 등록된 도메인을 만드세요. 이름을 다음으로 대체합니다. <내 도메인> 아래 단계를 따르세요. ( PCMag의 가이드를 포함하여 도메인을 등록하는 방법에 대한 기사가 많이 있습니다.)

2. 매니페스트 나 Helm 차트를 사용하여 NGINX Ingress Controller를 배포합니다. 배포 사양에 다음 명령줄 인수 와 동일한 인수를 추가합니다.

   • -enable-external-dns – ExternalDNS와의 통합을 활성화합니다.
   • -external-service=nginx-ingress – NGINX Ingress Controller에 DNS 공급자가 관리하는 A 레코드에 기록할 공개 진입점을 광고하라고 지시합니다. 공개 진입점의 호스트 이름은 외부 서비스 nginx-ingress 로 확인됩니다.
3. 온프레미스에 Kubernetes 클러스터를 배포하는 경우 외부 로드 밸런서를 프로비저닝합니다. 무료 전자책 ' Get Me to the Cluster' 에서는 BGP를 사용하여 외부 로드 밸런서로 NGINX를 배포하는 방법에 대한 지침을 제공합니다. 또는 F5 BIG‑IP 또는 MetalLB를 사용할 수 있습니다.

4. 필요한 경우 ExternalDNS가 지원하는 공급자 에서 DNS 영역을 만듭니다. 이 명령은 샘플 배포에 사용된 공급자인 Google Cloud DNS를 위한 것입니다.

   $ gcloud dns 관리 영역 "외부 DNS" 생성<나의 도메인>"--dns-name "외부-dns.<나의 도메인>." --description "외부 DNS에 의해 자동으로 관리되는 영역"
   

NGINX Ingress Controller 및 ExternalDNS 배포

1. 샘플 배포를 위해 GitHub 저장소를 복제하고 NGINX Ingress Controller를 배포합니다.

   $ git clone https://github.com/nginxinc/NGINX-Demos.git && cd NGINX-Demos/external-dns-nginx-ingress/ $ kubectl apply -f nginx-ingress.yaml && kubectl apply -f loadbalancer.yaml
   

2. ExternalDNS 배포 사양에서 다음 인수를 업데이트합니다(샘플 배포의 경우 external-dns-gcloud.yaml 의 59~62행):

   • --도메인 필터 – 생성된 도메인의 이름 4단계 이전 섹션(샘플 배포에서) 외부 DNS.<나의 도메인>). 기존 값을 제거하여 이 도메인만 사용합니다.
   • --provider – DNS 공급자(샘플 배포에서는 Google DNS를 의미하는 google )
   • --google-project – 샘플 배포에 사용하는 Google 프로젝트 의 이름입니다(Google 프로젝트가 두 개 이상인 경우에만 필수).
   • --txt-owner-id – 선택한 ID(샘플 배포에 고유함).

   메모: ExternalDNS 배포 사양에 포함해야 하는 인수는 선택한 DNS 공급자에 따라 달라질 수 있습니다. 다양한 DNS 공급자가 있는 클러스터에 ExternalDNS를 배포하는 방법에 대한 자습서 목록은 ExternalDNS 설명서를 참조하세요.

3. 클러스터에 ExternalDNS를 배포하고 배포가 성공적으로 실행되는지 확인합니다(출력은 읽기 쉽도록 두 줄로 나누어 표시했습니다).

   $ kubectl apply -f external-dns-gcloud.yaml $ kubectl get pods -o wide 이름 준비 상태 ... external-dns-4hrytf7f98f-ffuffjbf7 1/1 실행 중 ... ... RESTARTS AGE ... 0 1분
   

NGINX Ingress 컨트롤러 구성

다음으로, 외부 연결을 Kubernetes 애플리케이션으로 라우팅하는 Ingress 부하 분산 규칙으로 VirtualServer 리소스를 구성합니다.

1. app-virtual-server.yaml 에서 호스트 필드를 설정합니다(라인 6):

    6 호스트: ingress.external-dns. <내 도메인>
   

   이 값과 external-dns-gcloud.yaml 의 59번째 줄에 있는 domain-filter 값(이전 섹션의 2단계 에서 설정) 간의 매핑은 DNS 레코드의 자동 업데이트를 가능하게 합니다.

2. app-virtual-server.yaml을 적용하고 VirtualServer가 올바르게 구성되었는지 확인합니다.

   $ kubectl apply -f app-secret.yaml && kubectl apply -f app-virtual-server.yaml $ kubectl get vs 이름 상태 호스트 IP cafe 유효한 ingress.external-dns. <내 도메인>  34.168. 엑스 . 와이
   

3. DNS 영역에 DNS 유형 A 레코드가 추가되었는지 확인합니다. 특히, DATA 필드의 IP 주소는 이전 단계의 kubectl get vs 명령 출력의 IP 필드(NGINX Ingress Controller를 노출하는 LoadBalancer 유형의 서비스의 외부 IP 주소 또는 온-프레미스 배포의 동등한 주소)와 일치해야 합니다.

   $ gcloud dns record-sets list --zone external-dns- <내 도메인> -name ingress.external-dns. <내 도메인> --type A 이름 유형 TTL 데이터 ingress.external-dns. <내 도메인> .  A 300 34.168. X . Y
   

4. VirtualServer 호스트 이름을 로컬 머신에서 확인할 수 있는지 확인하려면 DNS 영역(이 경우 my-ns-domains )에 할당된 이름 서버를 가져옵니다.

   $ gcloud dns 레코드 세트 목록 --zone 외부 DNS. <내 도메인> --name 외부 DNS. <내 도메인> . --type NS 이름 유형 TTL 데이터 외부 DNS. <내 도메인> .   NS 21600 my-ns-도메인
   
   $ dig +short @my-ns-domains ingress.external-dns.<나의 도메인>
   34.168.엑스.와이
   

5. 이전 단계에서 검색한 DNS 레코드를 등록된 도메인의 전용 네임 서버로 사용합니다. 이렇게 하면 등록된 도메인이 필수 구성 요소 의 4단계 에서 생성된 DNS 영역의 부모 영역으로 설정됩니다.

6. 이제 글로벌 인터넷에 노출되었으므로 VirtualServer 호스트 이름에 액세스할 수 있는지 확인하세요.

   $ curl -i --insecure https://ingress.external-dns. <내 도메인> /tea HTTP/1.1 200 OK 서버: nginx/1.23.0 날짜: 일 , DD MM YYYY hh : mm : ss TZ 콘텐츠 유형: text/plain 콘텐츠 길이: 160 연결: keep-alive 만료: 일 , DD MM YYYY hh : mm : ss TZ 캐시 제어: no-cache
   

여러 Kubernetes 클러스터 확장

다이어그램에서 외부 DNS 레코드 생성을 자동화하고 이를 새 클러스터 진입점( Kubernetes Cluster 1 및 Kubernetes Cluster 2 )으로 확인하여 아키텍처를 빠르게 확장하고 여러 클러스터를 자동으로 검색할 수 있습니다. NGINX Ingress Controller 및 ExternalDNS 배포 및 NGINX Ingress Controller 구성 의 지침을 반복합니다.

CI/CD 파이프라인에서 Infrastructure-as-Code 도구를 사용하여 ExternalDNS 및 NGINX Ingress Controller를 사용하여 새로운 클러스터를 생성하고 외부 트래픽에 노출할 수도 있습니다. 또한, 검색이 활성화된 방식에 따라 여러 DNS 영역 또는 여러 DNS 공급자를 관리할 수도 있습니다.

결론

침해를 완화하는 보안 조치와 생산성 간의 균형을 맞추는 것은 어려울 수 있습니다. DevOps 팀에 제한을 가하면 DevOps 팀과 NetOps/SecOps 팀 간에 마찰이 생기는 경우가 많습니다. 각 조직마다 이상적인 균형이 다르며, NGINX는 조직의 우선순위와 요구 사항에 맞춰 균형을 유지할 수 있는 유연성을 제공합니다.

과거에는 앱 소유자가 NetOps 팀에 의존하여 애플리케이션을 외부 시스템에 연결했습니다. NGINX와 ExternalDNS 통합을 사용하면 개발자와 DevOps 팀은 검색 가능한 애플리케이션을 직접 배포할 수 있으며, 혁신을 위한 출시 시간을 단축하는 데 도움이 됩니다.

Kubernetes에서 NGINX를 시작하는 방법에 대한 포괄적인 전체 가이드를 보려면 무료 전자책 F5 NGINX로 Kubernetes 트래픽 관리를 다운로드하세요. 실용 가이드

NGINX App Protect WAF 및 DoS가 포함된 NGINX Ingress Controller의 30일 무료 체험판을 요청하여 오늘 시작하거나, 사용 사례에 대해 논의하기 위해 당사에 문의하세요 .