Personalizando o Serviço DNS

Essa página explica como configurar os seus Pod(s) de DNS e personalizar o processo de resolução de DNS no seu cluster.

Antes de você começar

Você precisa ter um cluster do Kubernetes e a ferramenta de linha de comando kubectl deve estar configurada para se comunicar com seu cluster. É recomendado executar esse tutorial em um cluster com pelo menos dois nós que não estejam atuando como hosts de camada de gerenciamento. Se você ainda não possui um cluster, pode criar um usando o minikube ou pode usar um dos seguintes ambientes:

Seu cluster deve estar executando o complemento CoreDNS.

O seu servidor Kubernetes deve estar numa versão igual ou superior a v1.12. Para verificar a versão, digite kubectl version.

Introdução

DNS é um serviço integrado do Kubernetes que é iniciado automaticamente usando o gerenciador de complementos cluster add-on.

Se você estiver executando o CoreDNS como um Deployment, ele geralmente será exposto como um service do Kubernetes com o endereço de IP estático. O kubelet passa informações de resolução de DNS para cada contêiner com a flag --cluster-dns=<dns-service-ip>.

Os nomes DNS também precisam de domínios. Você configura o domínio local no kubelet com a flag --cluster-domain=<default-local-domain>.

O servidor DNS suporta pesquisas de encaminhamento (registros A e AAAA), pesquisas de porta (registros SRV), pesquisas de endereço de IP reverso (registros PTR) e muito mais. Para mais informações, veja DNS para Serviços e Pods.

Se a dnsPolicy de um Pod estiver definida como default, ele herda a configuração de resolução de nome do nó em que o Pod é executado. A resolução de DNS do Pod deve se comportar da mesma forma que o nó. Veja Problemas conhecidos.

Se você não quiser isso, ou se quiser uma configuração de DNS diferente para os pods, pode usar a flag --resolv-conf do kubelet. Defina essa flag como "" para impedir que os Pods herdem a configuração do DNS. Defina-a como um caminho de arquivo válido para especificar um arquivo diferente de /etc/resolv.conf para a herança de DNS.

CoreDNS

CoreDNS é um servidor oficial de DNS de propósito geral que pode atuar como DNS do cluster, cumprindo com as especificações DNS.

Opções CoreDNS ConfigMap options

CoreDNS é um servidor DNS que é modular e plugável, com plugins que adicionam novas funcionalidades. O servidor CoreDNS pode ser configurado por um Corefile, que é o arquivo de configuração do CoreDNS. Como administrador de cluster, você pode modificar o ConfigMap que contém o arquivo Corefile do CoreDNS para mudar como o descoberta de serviços DNS se comporta para esse cluster.

No Kubernetes, o CoreDNS é instalado com a seguinte configuração padrão do Corefile:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health {
            lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }    

A configuração do Corefile inclui os seguintes plugins do CoreDNS:

  • errors: Erros são enviados para stdout.
  • health: A integridade do CoreDNS é reportada para http://localhost:8080/health. Nesta sintaxe estendida, lameduck marcará o processo como não-íntegro, esperando por 5 segundos antes que o processo seja encerrado.
  • ready: Um endpoint HTTP na porta 8181 retornará 200 OK, quando todos os plugins que são capazes de sinalizar prontidão tiverem feito isso.
  • kubernetes: O CoreDNS responderá a consultas DNS baseado no IP dos Serviços e Pods. Você pode encontrar mais detalhes sobre este plugin no site do CoreDNS.
    • ttl permite que você defina um TTL personalizado para as respostas. O padrão é 5 segundos. O TTL mínimo permitido é de 0 segundos e o máximo é de 3600 segundos. Definir o TTL como 0 impedirá que os registros sejam armazenados em cache.
    • A opção pods insecure é fornecida para retrocompatibilidade com o kube-dns.
    • Você pode usar a opção pods verified, que retorna um registro A somente se houver um Pod no mesmo namespace com um IP correspondente.
    • A opção pods disabled pode ser usada se você não usar registros de Pod.
  • prometheus: As métricas do CoreDNS ficam disponíveis em http://localhost:9153/metrics seguindo o formato Prometheus, também conhecido como OpenMetrics.
  • forward: Qualquer consulta que não esteja no domínio do cluster do Kubernetes é encaminhada para resolutores predefinidos (/etc/resolv.conf).
  • cache: Habilita um cache de frontend.
  • loop: Detecta loops de encaminhamento simples e interrompe o processo do CoreDNS se um loop for encontrado.
  • reload: Permite a recarga automática de um Corefile que foi alterado. Depois de editar a configuração do ConfigMap, é necessario dois minutos para que as alterações entrem em vigor.
  • loadbalance: Este é um balanceador de carga DNS round-robin que randomiza a ordem dos registros A, AAAA e MX na resposta.

Você pode modificar o comportamento padrão do CoreDNS modificando o ConfigMap.

Configuração de domínio Stub e upstream nameserver usando o CoreDNS

O CoreDNS tem a capacidade de configurar domínios Stub e upstream nameservers usando o plugin forward.

Exemplo

Se um operador de cluster possui um servidor de domínio Consul localizado em "10.150.0.1" e todos os nomes Consul possuem o sufixo ".consul.local". Para configurá-lo no CoreDNS, o administrador do cluster cria a seguinte entrada no ConfigMap do CoreDNS.

consul.local:53 {
    errors
    cache 30
    forward . 10.150.0.1
}

Para forçar explicitamente que todas as pesquisas de DNS fora do cluster passem por um nameserver específico em 172.16.0.1, aponte o forward para o nameserver em vez de /etc/resolv.conf.

forward .  172.16.0.1

O ConfigMap final, juntamente com a configuração padrão do Corefile, é:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        forward . 172.16.0.1
        cache 30
        loop
        reload
        loadbalance
    }
    consul.local:53 {
        errors
        cache 30
        forward . 10.150.0.1
    }    

Próximos passos

Última modificação December 15, 2024 at 6:24 PM PST: Merge pull request #49087 from Arhell/es-link (2c4497f)