Por que o GKE se diferencia dos outros Kubernetes gerenciados
O Google Kubernetes Engine (GKE) é o serviço de Kubernetes gerenciado do Google Cloud, competindo diretamente com o AWS EKS e o Azure AKS no mercado de nuvem pública. O que diferencia o GKE vai além da técnica: o Google criou o projeto Kubernetes, e o GKE é o serviço que acumula mais tempo de experiência operacional real sobre essa plataforma.
No GKE, o Google cuida do plano de controle — o servidor de API, o etcd e o agendador. Em um cluster Regional, o plano de controle é distribuído entre três zonas, portanto a API do Kubernetes continua respondendo mesmo quando uma zona inteira falha. O GKE Autopilot vai além: o Google gerencia também os nós, reduzindo drasticamente a carga operacional da equipe de engenharia. O exame GCP-ACE enfatiza fortemente as diferenças entre esses modelos operacionais, as estratégias de escalamento e os padrões de integração de segurança.
---
GKE Standard vs GKE Autopilot: como escolher
A primeira decisão importante que qualquer equipe enfrenta ao adotar o GKE é se usar GKE Standard ou GKE Autopilot. Ambos os modos expõem a mesma API do Kubernetes, mas diferem fundamentalmente em quem é responsável pela infraestrutura de nós.
| Característica | GKE Standard | GKE Autopilot | |---------------|-------------|---------------| | Provisionamento de nós | Gerenciado pelo operador | Gerenciado pelo Google | | Patch do SO do nó | Responsabilidade do operador (atualização automática disponível) | Responsabilidade do Google | | Configuração do Node Pool | Totalmente personalizável | Não disponível (usar resource requests por Pod) | | Base de cobrança | Tempo de VM do nó | CPU/memória solicitada por Pod | | Contêineres privilegiados | Permitidos | Proibidos | | DaemonSets personalizados | Permitidos | Restritos (somente DaemonSets do sistema) | | Carga operacional | Alta | Baixa | | Nós Spot | Configurados por Node Pool | Configurados via anotações do Pod |
O GKE Autopilot é ideal para equipes com pouca experiência em operações de Kubernetes e para startups em estágio inicial onde a velocidade de entrega tem prioridade sobre o controle de infraestrutura. Se suas cargas de trabalho exigem contêineres privilegiados ou DaemonSets personalizados, o GKE Standard é a única opção viável. Uma armadilha recorrente no exame: o GKE Autopilot exige que cada Pod declare resource requests explícitos. Sem esses requests, o GKE Autopilot recusa o agendamento do Pod.
!GKE Standard vs Autopilot
Topologia do cluster: Zonal vs Regional, Público vs Privado
Os clusters do GKE são classificados ao longo de dois eixos independentes: escopo de disponibilidade (Zonal vs Regional) e nível de exposição de rede (Público vs Privado).
| Tipo de cluster | Localização do plano de controle | Localização dos nós | Característica principal | |----------------|----------------------------------|---------------------|-------------------------| | Zonal | Zona única | Zona única | Custo menor; falha total se a zona cair | | Regional | Distribuído em 3 zonas | Distribuído em 3 zonas | Alta disponibilidade; SLA do plano de controle 99,95% | | Público (padrão) | Endpoint público | IP público atribuído | Acesso à internet permitido | | Privado | Endpoint interno à VPC | Sem IP externo | Isolado da internet; requer Cloud NAT |
Com um cluster Regional, o plano de controle está distribuído em três zonas. Uma falha em uma única zona não interrompe o kubectl nem o agendamento de Pods. O plano de controle de um cluster Zonal para de responder quando sua zona falha, causando uma interrupção operacional completa. Para cargas de trabalho produtivas, os clusters Regionais são o padrão recomendado.
Os clusters Privados isolam os nós e o plano de controle dentro de uma VPC. Contêineres que precisam de conectividade de saída para a internet requerem Cloud NAT. Para restringir o acesso ao plano de controle apenas ao tráfego interno da VPC, ative o Endpoint Privado e use Authorized Networks para limitar quais intervalos CIDR podem acessar o servidor de API.
Clusters VPC-native com Alias IP também aparecem no exame. No modo VPC-native, os IPs dos Pods são atribuídos diretamente de um intervalo de IP secundário da sub-rede da VPC, permitindo roteamento direto entre IPs de Pods e outros recursos da VPC. Ao contrário do modelo legado baseado em rotas, as regras de firewall no nível da VPC podem ser aplicadas diretamente aos IPs dos Pods, proporcionando controle de rede mais granular.
---
Node Pools e estratégias de isolamento de cargas de trabalho
Um Node Pool é um grupo de nós dentro de um cluster que compartilham a mesma configuração. Executar múltiplos Node Pools em um único cluster do GKE é um padrão comum em produção para isolar diferentes tipos de cargas de trabalho.
| Padrão de uso | Exemplo de configuração do Node Pool | Propósito | |--------------|--------------------------------------|----------| | Isolamento de cargas GPU | Node Pool separado com nós n1-standard equipados com GPU | Fixar Pods de treinamento de ML exclusivamente em nós GPU | | Redução de custos com Spot | Node Pool Spot junto a Node Pool On-demand | Usar Spot para jobs em lote que toleram interrupções | | Cargas de trabalho de alta memória | Node Pool separado com instâncias otimizadas para memória | Isolar bancos de dados em memória e servidores de cache | | Contêineres Windows | Adicionar Node Pool com Windows Server | Suporte a aplicações baseadas em Windows | | Isolamento de componentes do sistema | Node Pool dedicado de tamanho reduzido | Executar apenas componentes do kube-system |
Para fixar um Pod a um Node Pool específico, use nodeSelector ou nodeAffinity. Combinações de Taints e Tolerations são outro mecanismo comum. Ao aplicar um Taint a um Node Pool de GPU, Pods regulares sem a Toleration correspondente não conseguem consumir recursos de GPU.
Uma característica crítica dos Node Pools que você precisa internalizar: os Node Pools do GKE são imutáveis. Não é possível alterar o tipo de máquina de um Node Pool existente diretamente. O procedimento padrão é criar um novo Node Pool com a configuração desejada, fazer cordon do Node Pool antigo para bloquear o agendamento de novos Pods, fazer drain para despejar e reagendar os Pods existentes, e então excluir o pool antigo. Configurar um PodDisruptionBudget durante esse processo garante um número mínimo de réplicas disponíveis durante toda a migração.
---
O trio de escalamento: HPA, VPA e Cluster Autoscaler
O escalamento no GKE opera em três camadas independentes, cada uma endereçando uma dimensão diferente do problema.
| Escalador | O que ajusta | Métrica principal | Caso de uso principal | |----------|-------------|-----------------|---------------------| | HPA (Horizontal Pod Autoscaler) | Número de réplicas de Pod | CPU, memória, métricas personalizadas | Gerenciar picos de tráfego | | VPA (Vertical Pod Autoscaler) | CPU/memória requests e limits do Pod | Dados históricos de uso | Ajuste automático de resource requests | | Cluster Autoscaler | Número de nós | Pods não agendáveis / nós ociosos | Reduzir custos fora do horário de pico |
O HPA escala o número de réplicas de Pods em execução para cima ou para baixo. A métrica padrão é a utilização de CPU, mas você também pode acionar o HPA a partir de métricas personalizadas baseadas no Stackdriver ou métricas externas. O número mínimo de réplicas do HPA é 1 — escalar para zero requer KEDA (Kubernetes Event-driven Autoscaling).
O VPA analisa os padrões de consumo real de CPU e memória de um Pod e recomenda ou aplica automaticamente valores de request atualizados. Existem três modos: Off (somente recomendações), Auto (aplica atualizações reiniciando Pods) e Initial (aplica apenas no primeiro agendamento). Evite executar VPA e HPA no mesmo Pod quando o HPA escala por CPU: os dois controladores entram em conflito. Reserve o VPA para cargas de trabalho onde o HPA não usa CPU como sinal de escalamento.
O Cluster Autoscaler opera no nível do Node Pool, com contagens mínima e máxima de nós configuráveis. Quando Pods não conseguem ser agendados por recursos insuficientes, o Cluster Autoscaler provisiona nós adicionais. Quando os nós ficam ociosos, ele migra os Pods e remove os nós ociosos. Combinar HPA com Cluster Autoscaler cria um loop de automação de duas camadas: o HPA ajusta a contagem de réplicas e o Cluster Autoscaler ajusta a contagem de nós para acompanhar.
A confusão mais comum no exame se resolve claramente: o ajuste automático do número de nós usa Cluster Autoscaler; o ajuste automático do número de Pods usa HPA; o ajuste automático do tamanho dos resource requests do Pod usa VPA. Mantenha esses três papéis bem diferenciados.
---
Construindo integração de identidade segura com Workload Identity
Aplicações rodando no GKE frequentemente precisam acessar serviços do GCP como Cloud Storage, BigQuery e Cloud SQL. A forma como você configura a autenticação para esse acesso é uma questão de segurança central.
| Método de autenticação | Descrição | Risco de segurança | |-----------------------|-----------|-------------------| | Montagem de arquivo de chave de conta de serviço | Montar um arquivo de chave JSON em um Pod como Kubernetes Secret | A exposição da chave compromete todas as permissões; a rotação de chaves é um fardo de gestão | | Conta de serviço compartilhada do nó | Todos os Pods de um nó herdam as permissões da conta de serviço do nó | Viola o princípio de menor privilégio; concede permissões excessivas em todo o cluster | | Workload Identity | Vincula um Kubernetes Service Account (KSA) a um GCP IAM Service Account (GSA) | Sem arquivos de chave; acesso de menor privilégio por Pod |
O Workload Identity vincula um Kubernetes Service Account a um GCP IAM Service Account. Quando um Pod chama uma API do GCP, o servidor de metadados do GKE fornece automaticamente as credenciais pertencentes ao GSA vinculado ao KSA desse Pod. Como nenhum arquivo de