Como usar o kube-dns

Padrão

---

Nesta página, descrevemos como o Google Kubernetes Engine (GKE) implementa a descoberta de serviços usando o kube-dns, o provedor de DNS padrão para clusters do GKE.

Para clusters do Autopilot, não é possível modificar a configuração padrão do kube-dns.

Arquitetura

Quando você cria um cluster, o GKE implanta automaticamente os pods do kube-dns no namespace kube-system. Os pods acessam a implantação do kube-dns por um serviço correspondente que agrupa os pods do kube-dns e atribui a eles um único endereço IP (ClusterIP). Por padrão, todos os pods em um cluster usam esse serviço para resolver consultas DNS. O diagrama a seguir mostra a relação entre os pods e o serviço kube-dns.

O kube-dns é escalonado para atender às demandas de DNS do cluster. Esse escalonamento é controlado pelo kube-dns-autoscaler, um pod implantado por padrão em todos os clusters do GKE. O kube-dns-autoscaler ajusta o número de réplicas na implantação do kube-dns com base no número de nós e núcleos no cluster.

O kube-dns é compatível com até 1.000 endpoints por serviço headless.

Como o DNS do pod é configurado

O agente kubelet em execução em cada nó configura o etc/resolv.conf do pod para usar o ClusterIP do serviço kube-dns. A configuração de exemplo a seguir mostra que o endereço IP do serviço kube-dns é 10.0.0.10. Esse endereço IP é diferente em outros clusters.

nameserver 10.0.0.10
search default.svc.cluster.local svc.cluster.local cluster.local c.my-project-id.internal google.internal
options ndots:5

O kube-dns é o servidor de nomes autoritativo do domínio do cluster (cluster.local). Ele resolve nomes externos recursivamente. Os nomes curtos que não são totalmente qualificados, como myservice, são preenchidos primeiro com caminhos de pesquisa local.

Observação: nos clusters do Autopilot do GKE, na versão 1.27 e posterior, o intervalo de IP de serviço padrão é um intervalo gerenciado pelo Google: 34.118.224.0/20 e o serviço kube-dns recebe 34.118.x.10 por padrão (x no intervalo 224-239).

Como adicionar resolvedores personalizados para domínios de stub

É possível modificar o ConfigMap do kube-dns para definir domínios de stub como parte da infraestrutura de DNS nos clusters.

Os domínios de stub permitem configurar resolvedores personalizados por domínio para que o kube-dns encaminhe solicitações DNS para servidores DNS upstream específicos ao resolver esses domínios.

Observação: ao definir um resolvedor personalizado para um domínio de stub, como example.com, o kube-dns encaminha todas as solicitações de resolução de nome para os servidores definidos, incluindo **example.com e *.example.com.

O manifesto do ConfigMap para kube-dns de exemplo a seguir inclui uma configuração stubDomains que define resolvedores personalizados para o domínio example.com.

apiVersion: v1
kind: ConfigMap
metadata:
  labels:
    addonmanager.kubernetes.io/mode: EnsureExists
  name: kube-dns
  namespace: kube-system
data:
  stubDomains: |
    {
      "example.com": [
        "8.8.8.8",
        "8.8.4.4",
        "1.1.1.1",
        "1.0.0.1"
      ]
    }

Execute o seguinte comando para abrir um editor de texto:

kubectl edit configmap kube-dns -n kube-system

Substitua o conteúdo do arquivo pelo manifesto e saia do editor de texto para aplicar o manifesto ao cluster.

Servidores de nomes upstream

Se você modificar o ConfigMap para kube-dns para incluir upstreamNameservers, o kube-dns encaminhará todas as solicitações de DNS, exceto *.cluster.local para esses servidores. Isso inclui metadata.internal e *.google.internal, que não podem ser resolvidos pelo servidor upstream.

Se você ativar a federação de identidade da carga de trabalho do GKE ou qualquer carga de trabalho que dependa da resolução metadata.internal, para manter a resolução de nome *.internal, adicione um stubDomain ao ConfigMap.

data:
  stubDomains: |
    {
      "internal": [
        "169.254.169.254"
      ]
    }
  upstreamNameservers: |
    ["8.8.8.8"]

Problemas conhecidos

Limite do domínio de pesquisa

Há um limite de seis domínios de pesquisa DNS no domínio /etc/resolv.conf. Se você definir mais de seis domínios de pesquisa, o seguinte aviso será exibido quando você executar o comando kubectl describe pod:

Search Line limits were exceeded, some search paths have been omitted, the applied search line is: default.svc.cluster.local svc.cluster.local cluster.local c.<project ID>.internal google.internal

Esse aviso é registrado no Cloud Logging na seção de registros do contêiner.

Para resolver esse problema, remova os caminhos de pesquisa extras da configuração.

Considere o limite de upstreamNameservers

O Kubernetes impõe um limite de até três valores de upstreamNameservers. Se você definir mais de três upstreamNameservers, verá o erro a seguir no Cloud Logging nos registros de implantação do kube-dns:

Invalid configuration: upstreamNameserver cannot have more than three entries (value was &TypeMeta{Kind:,APIVersion:,}), ignoring update

Quando isso acontece, o kube-dns se comporta como se não houvesse upstreamNameservers configurados. Para resolver esse problema, remova os upstreamNameservers extras da configuração.

Limitações de desempenho com o kube-dns

Se você estiver enfrentando alta latência com buscas DNS ou falhas de resolução de DNS com o provedor kube-dns padrão, isso pode ser causado por:

• Como executar buscas DNS frequentes na sua carga de trabalho
• Implantar uma densidade de pods maior por nó.
• Executar o kube-dns em VMs Spot ou preemptivas, o que pode levar a exclusões inesperadas de nós e problemas subsequentes de resolução de DNS.

Para melhorar os tempos de busca DNS, escolha uma das seguintes opções:

• Evite executar componentes críticos do sistema, como kube-dns no VMs Spot ou preemptivas. O uso de VMs Spot ou preemptivas para DNS pode causar falhas e interromper o cluster.
• Como prática recomendada, crie pelo menos um pool de nós composto por VMs padrão (não Spot ou preemptivas) para hospedar componentes críticos do sistema, como o kube-dns. Para garantir que cargas de trabalho críticas sejam programadas apenas no pool de nós confiável que as impede de serem executadas em VMs preemptivas ou do Spot, use taints e tolerâncias para VMs Spot.
• Ative NodeLocal DNSCache.
• Escalone verticalmente o kube-dns.
• Verifique se o aplicativo usa funções baseadas em dns.resolve* em vez de em dns.lookup, porque o segundo é síncrono. As funções dns.resolve* sempre executam uma consulta DNS assíncrona na rede.

Observação: durante upgrades de clusters do GKE, podem ocorrer falhas de resolução de DNS devido a upgrades simultâneos dos componentes do plano de controle, incluindo kube-dns. Isso pode acontecer independentemente de NodeLocal DNSCache estar ativado ou não. Normalmente, apenas uma pequena porcentagem de nós (cerca de 10%) é afetada em um determinado momento. Para minimizar as interrupções, recomendamos que você teste completamente os upgrades de cluster em um ambiente que não seja de produção antes de aplicá-los aos clusters de produção.

Registros DNS de serviço

O kube-dns só cria registros DNS para serviços que têm endpoints{track-name="k8sLink" track-type="concept"}.

TTL grande de servidores upstream de DNS

Se o kube-dns receber uma resposta DNS de um resolvedor de DNS upstream com um TTL grande ou "infinito", ele mantém esse valor de TTL para a entrada DNS no cache. A entrada nunca expira e pode criar uma discrepância entre a entrada e o endereço IP real resolvido para o nome do TTL.

O GKE resolve esse problema nas seguintes versões do plano de controle definindo um valor de TTL máximo como 30 segundos para qualquer resposta DNS que tenha um TTL maior que 30 segundos:

• 1.21.14-gke.9100
• 1.22.15-gke.2100
• 1.23.13-gke.500
• 1.24.7-gke.500
• 1.25.2-gke.500 ou mais recente.

Esse comportamento é semelhante ao NodeLocal DNSCache.

A seguir

• Leia a visão geral do DNS do cluster no GKE.
• Leia DNS para serviços e pods para uma visão geral de como o DNS é usado nos clusters do Kubernetes.