Conheça o NodeLocal DNSCache do GKE

1. Visão geral

O cache DNS melhora a latência da busca DNS enviando primeiro as solicitações DNS do pod para o cache local no mesmo nó. Isso torna os tempos de busca DNS mais consistentes e pode reduzir o número de consultas DNS para kube-dns ou Cloud DNS.

Neste laboratório, você vai testar como o NodeLocal DNSCache processa o tráfego DNS em um cluster do GKE. Você vai validar um cluster do GKE Standard que executa a versão 1.34.1-gke.3720000 e mais recente para confirmar se ele está ativado por padrão. Em seguida, desative para ver como a configuração muda quando você desativa o recurso.

Observação: o NodeLocal DNSCache também é ativado por padrão em clusters do GKE Autopilot, mas não pode ser desativado.

Objetivos

Neste laboratório, você vai aprender a fazer o seguinte:

• Criar uma VPC, uma sub-rede e regras de firewall personalizadas
• Implante um cluster padrão do GKE Standard com o canal de lançamento rápido.
• Execute um teste para verificar se o cache DNS do LocalNode está ativado
• Desativar o cache e verificar o estado sem ele

2. Configuração do laboratório

Configuração de ambiente autoguiada

1. Faça login no Console do Google Cloud e crie um novo projeto ou reutilize um existente. Crie uma conta do Gmail ou do Google Workspace, se ainda não tiver uma.

• O Nome do projeto é o nome de exibição para os participantes do projeto. É uma string de caracteres não usada pelas APIs do Google e pode ser atualizada quando você quiser.
• O ID do projeto precisa ser exclusivo em todos os projetos do Google Cloud e não pode ser mudado após a definição. O console do Cloud gera automaticamente uma string exclusiva. Em geral, não importa o que seja. Na maioria dos codelabs, é necessário fazer referência ao ID do projeto, normalmente identificado como PROJECT_ID. Se você não gostar do ID gerado, crie outro aleatório. Se preferir, teste o seu e confira se ele está disponível. Ele não pode ser mudado após essa etapa e permanece durante o projeto.
• Para sua informação, há um terceiro valor, um Número do projeto, que algumas APIs usam. Saiba mais sobre esses três valores na documentação.

Atenção: o ID do projeto é globalmente exclusivo e não pode ser usado por outras pessoas após a seleção. Você é o único usuário com esse ID. Mesmo que um projeto seja excluído, o ID não poderá ser usado novamente.

Observação: se você usa uma conta do Gmail, defina o local padrão como Sem organização. Se você usa uma conta do Google Workspace, escolha um local adequado para a organização.

2. Em seguida, ative o faturamento no console do Cloud para usar os recursos/APIs do Cloud. A execução deste codelab não vai ser muito cara, se tiver algum custo. Para encerrar os recursos e evitar cobranças além deste tutorial, exclua os recursos criados ou exclua o projeto. Novos usuários do Google Cloud estão qualificados para o programa de US$ 300 de avaliação sem custos.

Inicie o Cloud Shell

Embora o Google Cloud e o Spanner possam ser operados remotamente do seu laptop, neste codelab usaremos o Google Cloud Shell, um ambiente de linha de comando executado no Cloud.

No Console do Google Cloud, clique no ícone do Cloud Shell na barra de ferramentas superior à direita:

O provisionamento e a conexão com o ambiente levarão apenas alguns instantes para serem concluídos: Quando o processamento for concluído, você verá algo como:

Essa máquina virtual contém todas as ferramentas de desenvolvimento necessárias. Ela oferece um diretório principal persistente de 5 GB, além de ser executada no Google Cloud. Isso aprimora o desempenho e a autenticação da rede. Neste codelab, todo o trabalho pode ser feito com um navegador. Você não precisa instalar nada.

3. Configurar o ambiente

Alguns recursos ativados vão ter custos. Confira se você está ciente disso antes de executar. Para reduzir custos, verifique se os recursos foram destruídos após a conclusão do laboratório. Recomendamos que você confira o faturamento e confirme se o exercício é adequado para você.

Vamos criar uma VPC personalizada com regras de firewall. Se você já tiver uma VPC e um projeto, pule esta parte.

Abra o Cloud Shell, localizado na parte superior direita do console. E configure da seguinte forma:

1. Ativar algumas das APIs que vamos usar neste laboratório

gcloud services enable dns.googleapis.com
gcloud services enable servicedirectory.googleapis.com
gcloud services enable container.googleapis.com

2. Defina algumas variáveis. Essas variáveis são o ID do projeto e o nome da VPC (você vai criar a VPC na etapa 3).

export projectid=$(gcloud config get-value project)
export vpc_name=gke-cache-vpc
export subnet_name=mainsubnet
export region=us-east1
export zone=us-east1-b
export cluster_name=cache-gke-cluster
export channel=rapid

export machine_type=e2-standard-4
echo $projectid
echo $vpc_name

3. Agora, crie uma VPC personalizada chamada gke-cache-vpc.

gcloud compute networks create $vpc_name --subnet-mode=custom --project=$projectid \
--subnet-mode=custom \
--mtu=1460 \
--bgp-routing-mode=global

4. Criar a sub-rede na nova VPC

gcloud compute networks subnets create $subnet_name \
    --network=$vpc_name \
    --range=10.0.88.0/24 \
    --region=$region \
    --enable-private-ip-google-access \
    --project=$projectid

5. Adicionar regras de firewall à VPC

gcloud compute firewall-rules create $vpc_name-allow-internal \
    --network=$vpc_name --allow=tcp,udp,icmp --source-ranges=10.0.88.0/24

gcloud compute firewall-rules create $vpc_name-allow-ssh \
    --network=$vpc_name --allow=tcp:22 --source-ranges=35.235.240.0/20

4. Criar gateway NAT para comunicação com a Internet

Precisamos conceder acesso externo de saída à Internet. Portanto, vamos criar e anexar um gateway do Cloud NAT.

No Cloud Shell, use os seguintes comandos

1. Criar o Cloud NAT e o gateway NAT

gcloud compute routers create gke-nat-router --network=$vpc_name --region=$region

gcloud compute routers nats create gke-nat-gw \
    --router=gke-nat-router --region=$region \
    --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges

5. Implantar e verificar o cluster do GKE

1. No Google Cloud Shell, crie o cluster chamado cache-gke-cluster. Nos clusters padrão do GKE que executam a versão 1.34.1-gke.3720000 e mais recentes, o NodeLocal DNSCache está ativado por padrão. O provisionamento do cluster leva de 4 a 10 minutos.

gcloud container clusters create $cluster_name \
--zone=$zone --network=$vpc_name --subnetwork=$subnet_name \
--release-channel=$channel --machine-type=$machine_type \
--enable-ip-alias

2. Depois que o cluster for criado, conecte-se:

gcloud container clusters get-credentials $cluster_name --zone $zone

3. Agora, vamos verificar se o NodeLocal DNSCache está ativado.

Esses comandos confirmam que a versão é 1.34.1-gke.3720000 ou mais recente e que o agente local está em execução e os serviços

kubectl version | grep "Server Version"

kubectl get pods -n kube-system -o wide | grep node-local-dns -w

kubectl get svc,endpoints -n kube-system -l k8s-app=kube-dns

4. Em seguida, execute o seguinte comando: Isso cria um pod privilegiado na rede do host para verificar se as regras de iptables do nó estão interceptando e roteando ativamente o tráfego de DNS para o cache local.

export KUBEDNS_IP=$(kubectl get svc kube-dns -n kube-system -o jsonpath='{.spec.clusterIP}')

kubectl run node-inspector --quiet --rm -it --image=alpine --privileged --restart=Never \
  --overrides='{"spec": {"hostNetwork": true}}' -- \
  sh -c "apk add --no-cache iptables && iptables-save | grep -E '169.254.20.10|$KUBEDNS_IP'"

O que procurar:procure -j NOTRACK.. Isso confirma que o tráfego de DNS está ignorando a tabela de rastreamento de conexão.

6. Desativar e verificar o NodeLocal DNSCache

Agora vamos remover a otimização para ver como ela funciona sem ela.

1. Acesse o Cloud Shell e execute o seguinte. Observação:isso vai acionar uma recriação de nó, que geralmente leva de 3 a 5 minutos por pool de nós, à medida que o GKE faz o ciclo das instâncias.

gcloud container clusters update $cluster_name --zone=$zone --update-addons=NodeLocalDNS=DISABLED --quiet

kubectl get pods -n kube-system -o wide | grep node-local-dns -w

Nenhum desses pods vai aparecer no conjunto de daemons porque eles foram removidos.

2. Executar o teste novamente

kubectl run node-inspector --quiet --rm -it --image=alpine --privileged --restart=Never \
  --overrides='{"spec": {"hostNetwork": true}}' -- \
  sh -c "apk add --no-cache iptables && iptables-save | grep -E '169.254.20.10|$KUBEDNS_IP'"

Depois de desativar o complemento, a saída não vai mais conter as regras -j NOTRACK nem qualquer menção ao endereço IP 169.254.20.10. Isso significa que você não está mais recebendo os benefícios do cache local.

7. Limpar

# 1. Delete the GKE Cluster
# This will remove the node and all system pods (including kube-dns)
gcloud container clusters delete $cluster_name --zone=$zone --quiet

# 2. Delete the Cloud NAT and Router
# It is best practice to remove these before the VPC
gcloud compute routers nats delete gke-nat-gw --router=gke-nat-router --region=$region --quiet
gcloud compute routers delete gke-nat-router --region=$region --quiet

# 3. Delete the Firewall Rules
gcloud compute firewall-rules delete $vpc_name-allow-internal $vpc_name-allow-ssh --quiet

# 4. Delete the Subnet and VPC
gcloud compute networks subnets delete $subnet_name --region=$region --quiet
gcloud compute networks delete $vpc_name --quiet

8. Próximas etapas / Saiba mais

Leia mais sobre a documentação e os casos de uso de rede do GKE.

Codelab: Acessar o chat do Gemini 3 Pro usando o SDK do Python pelo endpoint do Private Service Connect

Codelab: Como criar agentes de IA com o ADK:os fundamentos

Comece o próximo laboratório

Continue sua quest com o Google Cloud e confira estes outros laboratórios do Google Cloud Skills Boost:

• Configuração de redes no Google Kubernetes Engine
• Descobrindo a IA generativa - Vertex AI
• IA agêntica no Google Cloud