Visão geral

Introdução ao CoreDNS

Quando você cria um cluster, o complemento CoreDNS é instalado para resolver nomes de domínio no cluster.

Você pode ver o pod do complemento CoreDNS no namespace de kube-system.

$ kubectl get po --namespace=kube-system
NAME                                      READY   STATUS    RESTARTS   AGE
coredns-7689f8bdf-295rk                   1/1     Running   0          9m11s
coredns-7689f8bdf-h7n68                   1/1     Running   0          11m

Depois que o CoreDNS é instalado, ele se torna um DNS. Depois que o Serviço é criado, o CoreDNS registra o nome do Serviço e o endereço IP. Dessa forma, o pod pode obter o endereço IP do Serviço consultando o nome do Serviço do CoreDNS.

nginx.<namespace>.svc.cluster.local é usado para acessar o Serviço. nginx é o nome do Serviço, <namespace> é o namespace e svc.cluster.local é o sufixo do nome de domínio. Em uso real, você pode omitir <namespace>.svc.cluster.local no mesmo namespace e usar o ServiceName.

Uma vantagem de usar ServiceName é que você pode escrever ServiceName no programa ao desenvolver a aplicação. Desta forma, você não precisa saber o endereço IP de um Serviço específico.

Depois que o CoreDNS é instalado, há também um Serviço no namespace do kube-system, como mostrado abaixo.

$ kubectl get svc -n kube-system
NAME               TYPE           CLUSTER-IP      EXTERNAL-IP                    PORT(S)                      AGE
coredns            ClusterIP      10.247.3.10     <none>                         53/UDP,53/TCP,8080/TCP       13d

Por padrão, depois que outros pods são criados, o endereço do Serviço CoreDNS é gravado como o endereço do servidor de resolução de nome de domínio no arquivo /etc/resolv.conf do pod. Crie um pod e visualize o arquivo /etc/resolv.conf da seguinte maneira:

$ kubectl exec test01-6cbbf97b78-krj6h -it -- /bin/sh
/ # cat /etc/resolv.conf
nameserver 10.247.3.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5 timeout single-request-reopen

Quando um usuário acessa o Service name:Port do pod do Nginx, o endereço IP do Serviço do Nginx é resolvido a partir do CoreDNS e, em seguida, o endereço IP do Serviço do Nginx é acessado. Dessa forma, o usuário pode acessar o pod do Nginx de back-end.

Figura 1 Exemplo de resolução de nome de domínio em um cluster

Como funciona a resolução de nomes de domínio no Kubernetes?

As políticas de DNS podem ser configuradas para cada pod. O Kubernetes é compatível com as políticas de DNS Default, ClusterFirst, ClusterFirstWithHostNet e None. Para obter detalhes, consulte DNS para Serviços e pods. Essas políticas são especificadas no campo dnsPolicy no pod específico.

• Default: os pods herdam a configuração de resolução de nome do nó em que os pods são executados. O servidor DNS upstream personalizado e o domínio de stub não podem ser usados junto com esta política.
• ClusterFirst: qualquer consulta de DNS que não corresponda ao sufixo de domínio de cluster configurado, como www.kubernetes.io, é encaminhada para o servidor de nomes upstream herdado do nó. Os administradores de cluster podem ter domínios de stub extra e servidores DNS upstream configurados.
• ClusterFirstWithHostNet: para pods em execução com hostNetwork, defina a política de DNS ClusterFirstWithHostNet.
• None: ela permite que um pod ignore as configurações de DNS do ambiente do Kubernetes. Todas as configurações de DNS devem ser fornecidas usando o campo dnsPolicy no pod específico.

• Os clusters do Kubernetes v1.10 e posteriores são compatíveis com Default, ClusterFirst, ClusterFirstWithHostNet e None. Os clusters anteriores ao Kubernetes v1.10 suportam apenas Default, ClusterFirst e ClusterFirstWithHostNet.
• Default não é a política de DNS padrão. Se dnsPolicy não for explicitamente especificado, será usado ClusterFirst.

Roteamento

Without stub domain configurations: qualquer consulta que não corresponda ao sufixo de domínio de cluster configurado, como www.kubernetes.io, é encaminhada para o servidor DNS upstream herdado do nó.

With stub domain configurations: se os domínios de stub e servidores DNS upstream estiverem configurados, as consultas de DNS serão roteadas de acordo com o seguinte fluxo:

1. A consulta é enviada primeiro para a camada de cache do DNS no CoreDNS.
2. A partir da camada de cache, o sufixo da solicitação é examinado e, em seguida, a solicitação é encaminhada para o DNS correspondente:
   • Nomes com o sufixo de cluster, por exemplo, .cluster.local: a solicitação é enviada ao CoreDNS.
   • Nomes com o sufixo de domínio de stub, por exemplo, .acme.local: a solicitação é enviada para o resolvedor do DNS personalizado configurado que escuta, por exemplo, em 1.2.3.4.
   • Nomes que não correspondem ao sufixo (por exemplo, widget.com): a solicitação é encaminhada para o DNS upstream.

Figura 2 Roteamento

Operações relacionadas

Você também pode configurar o DNS em uma carga de trabalho. Para mais detalhes, consulte Configuração de DNS.

Você também pode usar o CoreDNS para implementar a resolução de nomes de domínio definida pelo usuário. Para mais detalhes, consulte Uso de CoreDNS para resolução de nome de domínio personalizado.

Você também pode usar o DNSCache para melhorar o desempenho da resolução do DNS. Para mais detalhes, consulte Uso do DNSCache do NodeLocal para melhorar o desempenho do DNS.