Automatizando DNS multicluster com o NGINX Ingress Controller

Os aplicativos não podem servir ao seu propósito se os usuários não os encontrarem. O Sistema de Nomes de Domínio (DNS) é a tecnologia da Internet que “encontra” aplicativos e sites traduzindo 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 aplicativos modernos, especialmente em arquiteturas de microsserviços, onde os serviços estão constantemente alternando entre si.

Em uma postagem anterior , falamos sobre a definição de registros DNS para dois subdomínios que correspondem a aplicativos em execução no mesmo cluster ( unit-demo.marketing.net para o aplicativo de marketing e unit-demo.engineering.net para o aplicativo de engenharia ) e resolvem para o mesmo ponto de entrada do cluster, ou seja, o endereço IP externo do controlador de entrada NGINX do cluster. O roteamento Server Name Indication (SNI) é configurado no NGINX Ingress Controller para autenticar e rotear conexões para o aplicativo apropriado com base no nome de domínio solicitado pelos usuários.

Mas muitas organizações precisam estender esse caso de uso e implantar aplicativos em vários clusters do Kubernetes, que podem estar espalhados por regiões de provedores de nuvem. Para que o tráfego externo alcance novas regiões de cluster, você precisa 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 adequadamente. Agora, o projeto ExternalDNS 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 A de forma que os nomes DNS sejam derivados de nomes de host declarados em um recurso Ingress padrão do Kubernetes ou em um recurso personalizado do NGINX VirtualServer . Desenvolvedores e equipes de DevOps podem aproveitar essa integração em seus pipelines de CI/CD para descobrir aplicativos automaticamente em diferentes clusters, sem envolver a equipe de NetOps (que normalmente é dona do DNS).

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

A Arquitetura Base

Para implementar o ExternalDNS com o NGINX Ingress Controller, começamos com o caso base em que os desenvolvedores configuram um controlador Ingress para expor externamente aplicativos Kubernetes. Os clientes não podem se conectar aos aplicativos 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 Kubernetes, permitindo a descoberta automática de aplicativos Kubernetes usando registros DNS externos. No diagrama, as linhas pretas representam o caminho de dados pelo qual usuários externos acessam aplicativos no cluster do Kubernetes. As linhas roxas representam o caminho de controle sobre o qual os proprietários de aplicativos gerenciam registros DNS externos com recursos do VirtualServer na configuração do NGINX Ingress Controller e o DNS externo acessa o provedor DNS.

Integrando ExternalDNS e NGINX Ingress Controller

Execute as etapas 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 controlador de entrada NGINX

Pré-requisitos

1. Crie pelo menos um domínio registrado. Substitua seu nome por <meu‑domínio> 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 gráficos Helm . Adicione o equivalente a esses argumentos de linha de comando na especificação de implantação:

   • -enable-external-dns – Habilita a integração com ExternalDNS.
   • -external-service=nginx-ingress – Informa ao NGINX Ingress Controller para anunciar seu ponto de entrada público para gravação 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 no local, 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 . Alternativamente, você pode usar F5 BIG‑IP ou MetalLB .

4. Se necessário, crie uma zona DNS em um provedor suportado pelo ExternalDNS . Este comando é para o provedor usado na implantação de exemplo, o Google Cloud DNS.

   $ gcloud dns managed-zones cria "external-dns-<meu-domínio>" --dns-name "dns-externo.<meu-domínio>." --description "Zona gerenciada automaticamente pelo ExternalDNS"
   

Implantar o NGINX Ingress Controller e o ExternalDNS

1. Clone o repositório 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
   

2. Atualize os seguintes argumentos na especificação de implantação do ExternalDNS (nas linhas 59–62 em external-dns-gcloud.yaml para a implantação de exemplo):

   • --filtro-de-domínio – O nome do domínio criado em Passo 4 da seção anterior (na implantação de amostra, dns externo.<meu-domínio>). Remova todos os valores existentes para que somente este domínio seja usado.
   • --provider – O provedor de DNS (na implantação de exemplo, google para 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 amostra).

   Observação:  Os argumentos que você precisa incluir na especificação de implantação do ExternalDNS podem variar dependendo do 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 .

3. Implante o ExternalDNS no cluster e verifique se a implantação é executada com sucesso (a saída é distribuída em duas linhas para legibilidade).

   $ kubectl apply -f external-dns-gcloud.yaml $ kubectl get pods -o wide NOME PRONTO STATUS ... external-dns-4hrytf7f98f-ffuffjbf7 1/1 Executando ... ... RECOMEÇA IDADE ... 0 1m
   

Configurar o controlador de entrada NGINX

Em seguida, configuramos um recurso VirtualServer com uma regra de balanceamento de carga do Ingress que roteia conexões externas para nossos aplicativos Kubernetes.

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

    6 host: ingress.external-dns.<meu-domínio>
   

   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 app-virtual-server.yaml e verifique se o VirtualServer está configurado corretamente.

   $ kubectl aplicar -f aplicativo-secreto.yaml && kubectl aplicar -f aplicativo-servidor-virtual.yaml
   $ kubectl obter vs 
   NOME ESTADO HOST IP 
   cafe Ingress.external-dns válido.<meu-domínio>  34.168.X.E
   

3. Verifique se um registro DNS tipo A foi adicionado à zona DNS. Em particular, o endereço IP no campo DATA deve corresponder ao campo IP na saída do comando kubectl get vs na 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).

   $ lista de conjuntos de registros DNS do gcloud --zone external-dns-<meu-domínio> -nome ingress.external-dns.<meu-domínio> --tipo ANOME TIPO TTL DADOS
   ingress.external-dns.<meu-domínio>.  Um 300 34.168. X . Y
   

4. 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 ).

   $ lista de conjuntos de registros dns do gcloud --zone external-dns.<meu-domínio> --nome dns-externo.<meu-domínio>. --tipo NSNOME TIPO TTL DADOS
   external-dns.<meu-domínio>.   NS 21600 meus-ns-domínios
   
   $ dig +short @meus-domínios-ns ingress.dns-externo.<meu-domínio>
   34.168.X.E
   

5. Use os registros DNS recuperados na etapa anterior como servidores de nomes dedicados para seu domínio registrado. Isso define seu domínio registrado como a zona pai da zona DNS criada na Etapa 4 dos Pré-requisitos .

6. Verifique se você pode acessar o nome do host do VirtualServer agora que ele está exposto à Internet global.

   $ curl -i --insecure https://ingress.external-dns.<meu-domínio>/cháHTTP/1.1 200 OK
   Servidor: nginx/1.23.0
   Data: Dia , DD MM AAAA hh : mm : ss TZ Tipo de conteúdo: texto/sem formatação Comprimento do conteúdo: 160 Conexão: keep-alive Expira: Dia , DD MM AAAA hh : mm : ss TZ Controle de cache: no-cache
   

Escalando vários clusters do Kubernetes

Você pode dimensionar 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 ( Kubernetes Cluster 1 e Kubernetes Cluster 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 gerar e expor novos clusters 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 DNS, dependendo de como a descoberta está habilitada.

Conclusão

Equilibrar produtividade com medidas de segurança que mitiguem violações pode ser difícil. Impor restrições às equipes de DevOps geralmente causa atrito entre elas e as equipes de NetOps/SecOps. O equilíbrio ideal difere em cada organização, e o NGINX oferece a flexibilidade para estabelecer um equilíbrio que atenda às suas prioridades e requisitos.

No passado, os proprietários de aplicativos dependiam de equipes de NetOps para conectar seus aplicativos a sistemas externos. Ao usar a integração do ExternalDNS com o NGINX, os desenvolvedores e as equipes de DevOps podem implantar aplicativos detectáveis por conta própria, ajudando a acelerar o tempo de lançamento de inovação no mercado.

Para um guia completo e abrangente sobre como começar a usar o NGINX no Kubernetes, baixe nosso e-book gratuito Managing Kubernetes Traffic with F5 NGINX: Um guia prático .

Você também pode começar hoje mesmo solicitando um teste gratuito de 30 dias do NGINX Ingress Controller com NGINX App Protect WAF e DoS ou entre em contato conosco para discutir seus casos de uso .