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
Ao criar 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.
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.
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.
Registros DNS de serviço
O kube-dns só cria registros DNS para serviços que têm Endpoints.
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.