Automatizando o DNS multicluster com o NGINX Ingress Controller

Amir RawdatEngenheiro de Soluções

Os aplicativos não conseguem cumprir sua finalidade se os usuários não puderem encontrá-los. O Sistema de Nomes de Domínio (DNS) é a tecnologia da Internet que “encontra” aplicativos e sites ao traduzir nomes de domínio em endereços IP. O DNS é tão onipresente e confiável que, na maioria dos dias, você nem pensa nele. Mas, quando há problemas de DNS, tudo para. Garantir que o DNS funcione é crucial para os aplicativos modernos, especialmente em arquiteturas de microsserviços, nas quais os serviços são constantemente iniciados e encerrados.

Em uma publicação anterior, falamos sobre a definição de registros DNS para dois subdomínios que correspondem a aplicações executadas no mesmo cluster (unit-demo.marketing.net para a aplicação de Marketing e unit-demo.engineering.net para a aplicação de Engenharia) e que são resolvidos para o mesmo ponto de entrada do cluster — ou seja, o endereço IP externo do NGINX Ingress Controller do cluster. O roteamento por Server Name Indication (SNI) é configurado no NGINX Ingress Controller para autenticar e encaminhar as conexões à aplicação apropriada com base no nome de domínio solicitado pelos usuários.

No entanto, muitas organizações precisam ampliar esse caso de uso e implantar aplicações em vários clusters do Kubernetes, que podem estar distribuídos entre diferentes regiões do provedor de nuvem. Para que o tráfego externo chegue às novas regiões dos clusters, é necessário criar zonas DNS que sejam resolvidas para essas regiões.

No passado, esse processo exigia o uso de um provedor terceirizado (como GoDaddy ou DNSExit) para criar manualmente um registro de domínio e atualizar os registros de host de forma adequada. Agora, o projeto ExternalDNS do Kubernetes automatiza o processo, tornando os recursos do Kubernetes detectáveis por meio de servidores DNS públicos. Isso significa que você usa a API do Kubernetes para configurar uma lista de provedores de DNS.

Com uma integração entre o ExternalDNS e o NGINX Ingress Controller, você pode gerenciar registros DNS do tipo A de modo que os nomes DNS sejam derivados dos nomes de host declarados em um recurso Ingress padrão do Kubernetes ou em um recurso personalizado VirtualServer do NGINX. Desenvolvedores e equipes de DevOps podem aproveitar essa integração em seus pipelines de CI/CD para descobrir automaticamente aplicações em diferentes clusters, sem envolver a equipe de NetOps (que normalmente é responsável pelo DNS).

Neste post, mostramos como usar arquivos de configuração de exemplo do nosso repositório do GitHub para integrar o ExternalDNS ao NGINX Ingress Controller.

A arquitetura básica

Para implementar o ExternalDNS com o NGINX Ingress Controller, começamos pelo cenário básico, no qual os desenvolvedores configuram um controlador Ingress para expor externamente as aplicações do Kubernetes. Os clientes não conseguem se conectar às aplicações até que o nome de domínio configurado seja resolvido para o ponto de entrada público do cluster do Kubernetes.

O NGINX Ingress Controller interage com o provedor de DNS por meio da implantação intermediária do ExternalDNS no Kubernetes, permitindo a descoberta automática de aplicações Kubernetes usando registros DNS externos. No diagrama, as linhas pretas representam o caminho de dados pelo qual os usuários externos acessam as aplicações no cluster Kubernetes. As linhas roxas representam o caminho de controle pelo qual os proprietários das aplicações gerenciam registros DNS externos com recursos VirtualServer na configuração do NGINX Ingress Controller e o ExternalDNS acessa o provedor de DNS.

Integração do ExternalDNS com o NGINX Ingress Controller

Siga as etapas descritas nas seções a seguir para integrar o ExternalDNS e o NGINX Ingress Controller.

• Pré-requisitos
• Implantar o NGINX Ingress Controller e o ExternalDNS
• Configurar o NGINX Ingress Controller

Pré-requisitos

1. Crie pelo menos um domínio registrado. Substitua o nome dele por <my‑domain> nas etapas abaixo. (Há muitos artigos disponíveis sobre como registrar um domínio, incluindo este guia da PCMag.)
2. Implante o NGINX Ingress Controller usando manifestos ou charts do Helm. Adicione o equivalente a estes argumentos de linha de comando na especificação da implantação:
   • -enable-external-dns – Habilita a integração com o ExternalDNS.
   • -external-service=nginx-ingress – Instrui o NGINX Ingress Controller a anunciar seu ponto de entrada público para registro em registros A gerenciados pelo provedor de DNS. O nome do host do ponto de entrada público é resolvido para o serviço externo nginx-ingress.
3. Se você estiver implantando o cluster Kubernetes localmente, provisione um balanceador de carga externo. Fornecemos instruções para implantar o NGINX como balanceador de carga externo com BGP em nosso e-book gratuito Get Me to the Cluster. Como alternativa, você pode usar o F5 BIG‑IP ou o MetalLB.
4. Se necessário, crie uma zona DNS em um provedor compatível com o ExternalDNS. Este comando se destina ao provedor usado na implantação de exemplo, o Google Cloud DNS.

$ gcloud dns managed-zones create "external-dns-<my-domain>" --dns-name "external-dns.<my-domain>." --description "Zone automatically managed by ExternalDNS"

Implante o NGINX Ingress Controller e o ExternalDNS

1. Clone o repositório do GitHub para a implantação de exemplo e implante o 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

1. Atualize os seguintes argumentos na especificação de implantação do ExternalDNS (nas linhas 59–62 de external-dns-gcloud.yaml para a implantação de exemplo): Observação: Os argumentos que você precisa incluir na especificação de implantação do ExternalDNS podem variar de acordo com o provedor de DNS escolhido. Para obter uma lista de tutoriais sobre como implantar o ExternalDNS no cluster com diferentes provedores de DNS, consulte a documentação do ExternalDNS.
   • --domain-filter – O nome do domínio criado na Etapa 4 da seção anterior (na implantação de exemplo, external-dns.<my-domain>). Remova todos os valores existentes para que somente esse domínio seja usado.
   • --provider – O provedor de DNS (na implantação de exemplo, google para o Google DNS).
   • --google-project – O nome do projeto do Google que você está usando para a implantação de exemplo (obrigatório somente se você tiver mais de um projeto do Google).
   • --txt-owner-id – O ID que você escolher (exclusivo para a implantação de exemplo).
2. Implante o ExternalDNS no cluster e verifique se a implantação é executada com sucesso (a saída está distribuída em duas linhas para facilitar a leitura).

$ kubectl apply -f external-dns-gcloud.yaml$ kubectl get pods -o wide
NAME                                READY  STATUS    ...
external-dns-4hrytf7f98f-ffuffjbf7  1/1    Running   ...
    ... RESTARTS   AGE
    ... 0          1m

Configurar o NGINX Ingress Controller

Em seguida, configuramos um recurso VirtualServer com uma regra de balanceamento de carga do Ingress que direciona conexões externas para nossas aplicações do Kubernetes.

1. No arquivo app-virtual-server.yaml, defina o campo host (linha 6):

 6    host: ingress.external-dns.<my-domain>

1. O mapeamento entre esse valor e o valor de domain-filter na linha 59 de external-dns-gcloud.yaml (definido na Etapa 2 da seção anterior) é o que permite a atualização automática dos registros DNS.
2. Aplique o arquivo app-virtual-server.yaml e verifique se o VirtualServer está configurado corretamente.

$ kubectl apply -f app-secret.yaml && kubectl apply -f app-virtual-server.yaml
$ kubectl get vs 
NAME   STATE   HOST                              IP            
cafe   Valid   ingress.external-dns.<my-domain>  34.168.X.Y

1. Verifique se um registro DNS do tipo A foi adicionado à zona DNS. Especificamente, o endereço IP no campo DATA deve corresponder ao campo IP na saída do comando kubectl get vs da etapa anterior (o endereço IP externo do serviço do tipo LoadBalancer que expõe o NGINX Ingress Controller ou o equivalente em uma implantação local).

$ gcloud dns record-sets list --zone external-dns-<my-domain> -name ingress.external-dns.<my-domain> --type ANAME                               TYPE     TTL     DATA
ingress.external-dns.<my-domain>.  A        300     34.168.X.Y

1. Para validar se o nome do host do VirtualServer pode ser resolvido na máquina local, obtenha os servidores de nomes atribuídos à zona DNS (neste caso, my-ns-domains).

$ gcloud dns record-sets list --zone external-dns.<my-domain> --name external-dns.<my-domain>. --type NSNAME                        TYPE      TTL     DATA
external-dns.<my-domain>.   NS        21600   my-ns-domains

$ dig +short @my-ns-domains ingress.external-dns.<my-domain>
34.168.X.Y

1. Use os registros DNS recuperados na etapa anterior como servidores de nomes dedicados para o domínio registrado. Isso define o domínio registrado como a zona pai da zona DNS criada na Etapa 4 de Pré-requisitos.
2. Verifique se você consegue acessar o nome do host do VirtualServer agora que ele está exposto à Internet global.

$ curl -i --insecure https://ingress.external-dns.<my-domain>/teaHTTP/1.1 200 OK
Server: nginx/1.23.0
Date: Day, DD MM YYYY hh:mm:ss TZ
Content-Type: text/plain
Content-Length: 160
Connection: keep-alive
Expires: Day, DD MM YYYY hh:mm:ss TZ
Cache-Control: no-cache

Escalando vários clusters Kubernetes

Você pode escalar rapidamente a arquitetura e descobrir automaticamente vários clusters automatizando a criação de registros DNS externos e resolvendo-os para novos pontos de entrada de cluster (Cluster Kubernetes 1 e Cluster Kubernetes 2) no diagrama. Repita as instruções em Implantar o NGINX Ingress Controller e o ExternalDNS e Configurar o NGINX Ingress Controller.

Você também pode usar ferramentas de infraestrutura como código no seu pipeline de CI/CD para criar novos clusters e expô-los ao tráfego externo usando o ExternalDNS e o NGINX Ingress Controller. Além disso, você pode gerenciar várias zonas DNS ou até mesmo vários provedores de DNS, dependendo de como a descoberta estiver habilitada.

Conclusão

Equilibrar a produtividade com medidas de segurança que reduzam o risco de violações pode ser difícil. A imposição de restrições às equipes de DevOps costuma gerar atritos entre elas e as equipes de NetOps/SecOps. O equilíbrio ideal varia de uma organização para outra, e o NGINX oferece a flexibilidade necessária para estabelecer um equilíbrio alinhado às suas prioridades e aos seus requisitos.

No passado, os responsáveis pelos aplicativos dependiam das equipes de NetOps para conectar seus aplicativos a sistemas externos. Com a integração do ExternalDNS ao NGINX, desenvolvedores e equipes de DevOps podem implantar aplicativos detectáveis por conta própria, ajudando a acelerar o lançamento de inovações no mercado.

Para conferir um guia completo sobre como começar a usar o NGINX no Kubernetes, baixe gratuitamente nosso eBook Gerenciamento de tráfego do Kubernetes com o F5 NGINX: um guia prático.

Você também pode começar hoje mesmo solicitando uma avaliação gratuita de 30 dias do NGINX Ingress Controller com NGINX App Protect WAF e proteção contra DoS ou entrar em contato conosco para discutir seus casos de uso.

Sobre o autor

Amir RawdatEngenheiro de Soluções

Mais publicações de Amir Rawdat