Google PCNE: GKE, Contêineres e Rede de Aplicações — Guia de estudos

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Faz parte do Google Professional Cloud Network Engineer — Guia de estudos. Pratique com respostas verificadas no centro de exames da Google, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

O Google Kubernetes Engine (GKE) se integra profundamente com a rede do Google Cloud. Projetar para confiabilidade e segurança exige a compreensão do endereçamento IP nativo da VPC, planos de controle privados, tráfego de saída (egress), tráfego norte-sul e leste-oeste, aplicação de políticas e construções multi-cluster. Esta seção fornece orientações de design, raciocínio operacional e modos de falha comuns para contêineres e redes de aplicações no Google Cloud.

Arquitetura de IP do GKE e clusters privados

Clusters nativos da VPC

• Usam IPs de alias com dois intervalos secundários em uma sub-rede VPC: um para Pods (PodCIDR) e outro para Services (ServiceCIDR). Isso evita o SNAT baseado em iptables nos nós, permite o balanceamento de carga nativo de contêiner com NEGs e escala melhor do que clusters baseados em rotas.
• Diretrizes de dimensionamento:
  • Pods: aloque PodsPerNode × MaxNodes, mais uma margem de segurança (20–30%). Por exemplo, os 10 nós atuais × 20 Pods + crescimento para 100 × 200 sugerem um intervalo de Pods /17; os Services geralmente cabem em um /21 para mais de 2 mil serviços.
  • Services: cada ClusterIP consome um IP; considere uma margem de segurança para migrações de headless para ClusterIP e para add-ons.
• Modos de falha:
  • Esgotamento de IPs de Pods: os Pods permanecem no estado Pending ou erros de CNI/IPAM aparecem; expanda o intervalo secundário de Pods ou reduza o número máximo de pods por nó e, em seguida, recrie os nós.
  • Esgotamento de IPs de Services: novos Services falham ao alocar um ClusterIP; expanda o intervalo secundário de Services.
  • Sobreposição de intervalos de alias: a criação do cluster falha ou ocorrem blackholes de roteamento; valide que não há sobreposição com outras sub-redes ou VPCs em peering.

Clusters privados, acesso ao plano de controle e saída dos nós

• Clusters privados restringem o endpoint do plano de controle a um endereço privado RFC1918, alcançável apenas a partir da sua VPC via peering de produtor. Os nós não exigem IPs externos.
• Para os operadores, escolha:
  • Apenas endpoint privado: o plano de controle é alcançável a partir das sub-redes da VPC e redes conectadas. Use um bastion ou o Cloud Shell com Private Service Connect para alcançá-lo.
  • Endpoint público com Authorized Networks: expõe o plano de controle em um IP público protegido por CIDRs de origem específicos. Isso é conveniente, mas aumenta a exposição; use apenas com um escopo de CIDR restrito e controles de identidade de administrador robustos.
• Saída (egress) dos nós:
  • Para nós sem IPs externos, forneça saída para a internet via Cloud NAT. Isso permite atualizações do SO, download de imagens de contêiner de registros externos e acesso a APIs de parceiros, mantendo os nós privados.
  • Para acesso às APIs do Google e ao Artifact/Container Registry sem IPs externos, habilite o Private Google Access (PGA) nas sub-redes dos nós. O PGA resolve e roteia o tráfego das APIs/registros do Google para a borda do Google sem IPs de origem públicos. O PGA é preferível para o download de imagens; combine-o com o Cloud NAT se a saída para serviços fora do Google também for necessária.
  • Se estiver enviando 0.0.0.0/0 através de um firewall de terceiros, ainda assim habilite o PGA e adicione rotas estáticas para os intervalos de VIPs das APIs do Google para o gateway de internet padrão, a fim de contornar o firewall para os serviços do Google.

Escalabilidade e solução de problemas de IP

• Monitore o consumo de IPs de alias no nível do intervalo secundário da sub-rede. Se a pressão por IPs aumentar:
  • Aumente os tamanhos dos intervalos secundários (adicione intervalos maiores, recrie o cluster ou migre as cargas de trabalho quando necessário).
  • Ajuste o max-pods-per-node para equilibrar o uso de IP por nó versus a fragmentação do agendamento.
  • Remova Services abandonados; Services do tipo headless não alocam ClusterIPs, mas a conversão para ClusterIP consumirá IPs.
• Planeje o crescimento multirregional com intervalos secundários que não se sobreponham para evitar a necessidade de refazer o endereçamento IP (re-IP) ao usar Shared VPCs, VPC Peering ou serviços multi-cluster.

Ingress, Gateway API, Services e políticas

Services e load balancers

• Tipos de Service:
  • ClusterIP: acesso apenas dentro do cluster; o tráfego leste-oeste usa o kube-proxy ou o dataplane v2.
  • NodePort: aloca uma porta em cada nó; usado por muitos LBs como backend, mas evite expô-lo diretamente na internet.
  • LoadBalancer: provisiona um load balancer na nuvem. Load balancers L4 externos ou internos suportam TCP/UDP; a afinidade de sessão ClientIP fornece “stickiness” (aderência) entre múltiplos protocolos quando necessário.
• O balanceamento de carga nativo de contêiner usa Network Endpoint Groups (NEGs) para que o load balancer direcione o tráfego diretamente para os IP:porta dos Pods, melhorando a sinalização de saúde (health signaling) e reduzindo os saltos entre nós. Para o GKE, use GKE Pod NEGs (GCE_POD). Outros tipos de NEG incluem VM_IP_PORT, Internet FQDN e PSC.
• GKE Ingress e Gateway API:
  • O Ingress é estável para tráfego norte-sul HTTP(S) com o balanceador de carga HTTP(S) externo global do Google ou o balanceador de carga HTTP(S) interno regional. O controller programa as verificações de saúde (health checks) e as regras de firewall automaticamente para padrões comuns.
  • A Gateway API oferece um modelo mais expressivo com Gateways e HTTPRoutes/TCPRoutes. Ela suporta configurações multi-tenant, roteamento avançado e uma especificação consistente entre ambientes. Escolha a Gateway API para garantir compatibilidade futura (future-proofing); use o Ingress onde a simplicidade e a compatibilidade são mais importantes.

Restrição de clientes e verificações de saúde (health checks)

• A restrição de clientes a faixas de origem específicas pode ser feita em L4 com regras de firewall da VPC direcionadas às instâncias de backend, ou em L7 com políticas do Cloud Armor nos balanceadores de carga HTTP(S).
• Sempre permita as faixas de origem do verificador de saúde (health checker) do Google para os alvos de backend ou Pods para que as verificações de saúde passem. Em algumas implantações, o GKE cria regras k8s-fw automaticamente; se você adicionar regras restritivas, mantenha permissões explícitas para as faixas do verificador de saúde.
• Abordagem de exemplo para backends L4: marque os nós com a tag “application” e crie uma regra de firewall de permissão (allow) para tcp:NodePort a partir dos CIDRs de clientes permitidos e das faixas de verificação de saúde do Google, e uma regra de negação (deny) de prioridade mais alta para todas as outras origens com logging ativado para observar os pacotes descartados (drops).

Políticas de rede (Network Policies) e dataplane v2

• Habilite a NetworkPolicy do Kubernetes e use o GKE Dataplane V2 para aplicação de regras baseada em eBPF, melhorando o desempenho e a fidelidade em comparação com os mecanismos baseados em iptables.
• Postura de base:
  • Negar por padrão (default deny) o tráfego de saída (egress) e entrada (ingress) para os namespaces; permita explicitamente os fluxos de Pod para Pod e de Pod para Service.
  • Use seletores de namespace (namespaceSelectors) e de pod (podSelectors) para criar camadas de serviço (frontend, backend, dados) e permita apenas as direções e portas mínimas necessárias.
• Comunicação segura entre serviços:
  • Para uma abordagem zero trust dentro do cluster, o mTLS é melhor implementado por uma service mesh; a NetworkPolicy lida com L3/L4 e não pode autenticar identidades.
  • Para o tráfego norte-sul, anexe o Cloud Armor aos LBs HTTP(S) para WAF, limitação de taxa (rate limiting) e modo de pré-visualização (preview) para testar uma regra de negação (deny) em atacantes suspeitos sem interromper os usuários.

Modos de falha e trade-offs

• Muitas NetworkPolicies ou políticas excessivamente amplas podem causar quedas inesperadas de pacotes (drops); valide com implantações graduais (staged rollouts), logging e ferramentas de explicação de políticas.
• Depender de NodePort mais regras de firewall externas é uma abordagem frágil; prefira load balancers gerenciados e Pod NEGs.
• A Gateway API traz recursos mais ricos, mas exige maturidade do controller e familiaridade da equipe; valide recursos como roteamento baseado em cabeçalho ou mTLS passthrough por canal de lançamento (release channel).

Multicluster, service mesh e identidade

Serviços multicluster e rede de frotas (fleet)

• Registre clusters em uma frota (fleet) para usar o Multi-Cluster Services (MCS) para descoberta de serviços e balanceamento de carga entre clusters. Exporte serviços de cada cluster; os clientes resolvem um único nome DNS que aponta para endpoints em todos os clusters.
• Padrões de tráfego entre clusters:
  • Mesma VPC, sub-redes diferentes: o tráfego flui por endereçamento privado RFC1918 com custo e latência otimizados.
  • VPCs diferentes: conecte com VPC Peering para conectividade privada e simples sem transitividade, ou use Cloud VPN/Cloud Router se as organizações forem diferentes ou se for necessária criptografia pela internet. Para administração centralizada, a Shared VPC expõe apenas as sub-redes necessárias para os projetos de serviço.
• Modos de falha:
  • CIDRs sobrepostos bloqueiam o roteamento; garanta que não haja sobreposição entre PodCIDR e ServiceCIDR antes de configurar peering ou VPN.
  • Problemas de DNS split-horizon podem quebrar a resolução entre clusters; valide os caminhos de busca (search paths) e os stub domains.

Service mesh, tráfego leste-oeste e observabilidade

• Implante uma service mesh como o Anthos Service Mesh para:
  • mTLS com identidade de carga de trabalho (workload) forte, política de tráfego (tentativas, timeouts, detecção de outliers) e divisão de tráfego.
  • Política leste-oeste consistente entre clusters com federação de malha (mesh) ou topologias multi-primary.
  • Telemetria rica: golden signals por carga de trabalho, traces de requisições e auditorias de políticas.
• Trade-offs:
  • Sidecars aumentam o consumo de recursos; modos ambient ou sidecarless podem reduzir o custo, mas valide a paridade de funcionalidades.
  • A malha (mesh) adiciona dependências de control plane; projete para control planes de alta disponibilidade (HA) e degradação gradual.

Identidade da carga de trabalho (workload), secrets e privilégio mínimo

• Use o Workload Identity para mapear Kubernetes Service Accounts (KSAs) para Google Service Accounts (GSAs), eliminando chaves de longa duração. Anote a KSA com o e-mail da GSA e conceda papéis (roles) de IAM mínimos à GSA.
• Gerenciamento de secrets:
  • Prefira o Secret Manager com o driver CSI para montar secrets em tempo de execução; remova Kubernetes Secrets em texto plano para dados sensíveis ou criptografe-os em repouso com CMEK se forem mantidos.
  • Conceda acesso de privilégio mínimo a secrets e buckets na GSA. Evite papéis (roles) no nível do projeto; restrinja o escopo a papéis no nível do recurso, como storage.objectViewer, quando aplicável.

Considerações de design para resiliência e segurança da plataforma

• Clusters regionais para alta disponibilidade; distribua os nós entre as zonas.
• Para o tráfego norte-sul, use o balanceamento de carga HTTP(S) global para a menor latência para usuários globais.
• Conectividade do control plane: escolha control planes privados; evite a exposição pública, a menos que seja estritamente necessário com Authorized Networks.
• Egress (saída): nós sem IPs externos, combinados com Cloud NAT e PGA, equilibram segurança e funcionalidade.
• Observabilidade: habilite logs de firewall, VPC Flow Logs e telemetria da malha (mesh) para diagnosticar rapidamente quedas de pacotes por política ou picos de latência.

Cenário de Problema Prático

A Contoso Retail opera dois clusters regionais privados do GKE em us-east1 e europe-west1. Requisitos: nós sem IPs externos, ingresso (ingress) seguro limitado a CIDRs corporativos, disponibilidade global para um serviço de vitrine (storefront), download de imagens sem exposição à internet e failover entre clusters para a camada de API. Eles já enfrentaram esgotamento de IPs de Pods durante um pico de tráfego.

Abordagem

1. Projete sub-redes VPC-native com intervalos secundários generosos.

   • Justificativa: Aloque um intervalo /17 para Pods e um intervalo /21 para Services por região para cobrir 100 nós × 200 Pods/nó e 1.500 serviços com uma margem de 20–30%. Isso evita a recorrência do esgotamento de IPs de Pods e a necessidade de realocação de IPs (re-IP) durante o crescimento.

2. Crie clusters privados com endpoints de control plane privados.

   • Justificativa: Limita a exposição do control plane à VPC. Os operadores se conectam por meio de um bastion host em uma sub-rede de gerenciamento. Isso reduz a superfície de ataque em comparação com endpoints públicos com Authorized Networks.

3. Habilite o Cloud NAT e o Private Google Access nas sub-redes dos nós.

   • Justificativa: Os nós não têm IPs externos, mas ainda precisam baixar imagens do Artifact Registry e acessar espelhos (mirrors) de SO/pacotes. O PGA garante o acesso às APIs do Google sem IPs de origem públicos; o Cloud NAT lida com o tráfego de saída (egress) para destinos fora do Google, conforme necessário.

4. Implemente um ingress HTTP(S) global usando a Gateway API com Pod NEGs.

   • Justificativa: Um único VIP anycast global reduz a latência para usuários em todo o mundo. Os Pod NEGs do GKE enviam health checks diretamente para os Pods e melhoram a detecção de falhas. A Gateway API fornece uma separação clara entre os Gateways de infraestrutura e as Routes pertencentes às aplicações.

5. Restrinja o acesso de clientes e permita os health checks.

   • Justificativa: Anexe uma política do Cloud Armor para permitir apenas os CIDRs corporativos, com uma negação padrão (default deny) e modo de pré-visualização (preview) para avaliar novos bloqueios com segurança. Além disso, garanta que as regras de firewall da VPC permitam os intervalos de origem dos health checks do Google para os NEGs de backend, para que os health checks permaneçam íntegros (green).

6. Aplique NetworkPolicy com o GKE Dataplane V2.

   • Justificativa: Negue por padrão o tráfego de entrada (ingress) e saída (egress) por namespace; permita apenas as portas do frontend para o backend e do backend para o banco de dados. O Dataplane V2 aplica as políticas de forma eficiente com eBPF, diminuindo o raio de alcance (blast radius) de um Pod comprometido.

7. Habilite o Multi-Cluster Services em toda a frota (fleet).

   • Justificativa: Exporte o serviço de API em ambas as regiões e publique um único DNS. Os clientes realizam failover automaticamente para endpoints saudáveis nos outros clusters. Como ambos os clusters estão na mesma VPC com sub-redes regionais, o tráfego entre regiões permanece privado e incorre em sobrecarga mínima.

8. Adote uma service mesh para segurança e observabilidade do tráfego leste-oeste.

   • Justificativa: Imponha mTLS entre os serviços, adicione orçamentos de tentativa/timeout e obtenha métricas e traces por rota. A política no nível da malha (mesh) complementa a NetworkPolicy: a NetworkPolicy controla a alcançabilidade em L3/L4; a malha autentica e autoriza identidades de serviço em L7.

9. Fortaleça as identidades de carga de trabalho (workload) e os secrets.

   • Justificativa: Mapeie KSAs para GSAs com escopo restrito via Workload Identity; conceda apenas os papéis (roles) necessários, como storage.objectViewer para os serviços que buscam relatórios. Entregue as credenciais através do CSI do Secret Manager para evitar secrets estáticos em manifestos.

10. Implemente proteções (guardrails) de capacidade e logging.

    • Justificativa: Defina o max-pods-per-node cuidadosamente para equilibrar o uso de IPs. Monitore a utilização do intervalo secundário e os VPC Flow Logs. Crie uma regra de firewall explícita de alta prioridade para negar tudo (deny-all) com logging na tag da aplicação para expor tráfego de cliente não intencional, preservando os caminhos permitidos.

Este design resulta em clusters privados por padrão (private-by-default) com acesso norte-sul controlado, failover multicluster resiliente, identidade com princípio de privilégio mínimo e um dataplane que escala sem esgotamento recorrente de IPs.

← Roteamento · Todos os domínios · Observabilidade de Rede →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Google →