Neste post, vamos explorar GKE Compute Class, um recurso fundamental do Google Kubernetes Engine que centraliza a configuração de infraestrutura de clusters. Se você trabalha com Kubernetes e busca reduzir a complexidade de gerenciamento de infraestrutura enquanto mantém flexibilidade, esse conceito é essencial.
O que é GKE Compute Class?
GKE Compute Class é um recurso personalizado (CustomResource) do Kubernetes que define um conjunto de atributos de nós e configurações de escalonamento automático. Ele funciona como um “blueprint” que o cluster usa para criar nós otimizados para tipos específicos de workload.
Em vez de você precisar criar e gerenciar múltiplos node pools manualmente, os ComputeClasses permitem declarar centralizadamente como os nós devem ser configurados. Quando um pod seleciona uma ComputeClass, o scheduler automático do GKE usa essas especificações para provisionar nós adequados.
Componentes principais
Uma ComputeClass define:
- Famílias de máquinas (N4, N2, C3, etc.)
- Comportamento de fallback entre opções de hardware
- Configurações de escalonamento automático para consolidação de nós
- Locais de nós (zonas, regiões)
- Aceleradores (GPUs, TPUs) e outras configurações de hardware
- Taints e tolerâncias que o GKE aplica automaticamente aos nós
Como GKE Compute Class funciona
O funcionamento é simples mas poderoso:
O fluxo de trabalho
- Declaração: Engenheiros de plataforma definem ComputeClasses em manifestos YAML
- Registro: As ComputeClasses são criadas como recursos personalizados no cluster
- Seleção: Operadores de apps especificam uma ComputeClass nos seus pods usando
nodeSelector - Escalonamento: O cluster autoscaler usa as prioridades definidas para criar nós apropriados
- Configuração: O GKE aplica automaticamente rótulos, taints e tolerâncias aos nós criados
Prioridades de fallback
Uma das características mais poderosas são as prioridades de fallback. Você pode definir múltiplas opções de hardware, ordenadas por preferência:
1ª escolha: Série N4 (preferida) ↓ (Se não disponível) 2ª escolha: Série N2 (alternativa) ↓ (Se não disponível) Comportamento: DoNotScaleUp (aguarda disponibilidade)
Se a série N4 não estiver disponível na sua região, o GKE automaticamente tenta N2. Se ambas falharem, ele pode ficar aguardando (DoNotScaleUp) ou criar nós mesmo assim (ScaleUpAnyway).
Essa funcionalidade de fallback facilita muito a utilização de máquinas spot. Isso pois é possível configurar a mesma máquinas ou família com máquinas spot em prioridade mais alta, seguida da mesma configuração, porém com uma prioridade menor para máquinas on demand.
Migração ativa
Outro recurso importante é a migração ativa de prioridades. Se você configurar isso, o GKE monitora continuamente se nós com maior prioridade ficaram disponíveis e substitui automaticamente os nós de menor prioridade por nós preferidos ao longo do tempo. Isso significa que seus pods migram gradualmente para o melhor hardware conforme ele fica disponível.
ComputeClass vs Node Pool
É importante entender a diferença:
| Aspecto | Node Pool | ComputeClass |
|---|---|---|
| Criação | Manual, imperativa | Declarativa, centralizada |
| Escopo | Um pool para um tipo de máquina | Define regras que o autoscaler segue |
| Flexibilidade | Limitada a configuração do pool | Suporta prioridades e fallback |
| Gerenciamento | Você gerencia cada pool | GKE gerencia automaticamente |
| Reusabilidade | Pool é estático | ComputeClass é reutilizável em múltiplas cargas |
Definindo uma ComputeClass
Vamos criar um exemplo prático. Aqui está uma ComputeClass para cargas de trabalho de análise de dados:
apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
name: data-analysis
spec:
# Habilita criação automática de node pools
nodePoolAutoCreation:
enabled: true
# Prioridades de máquinas (em ordem)
priorities:
- machineType: c3-standard-22
spot: true
- machineType: n2-standard-32
spot: true
- machineType: c3-standard-22
- machineType: n2-standard-32
# O que fazer se nenhuma prioridade estiver disponível
whenUnsatisfiable: DoNotScaleUp
# Configurações de escalonamento automático
autoscalingPolicy:
consolidationPolicy:
enabled: true
Quando um pod seleciona essa ComputeClass, o GKE tentará:
- Criar nó C3-standard-22 spot
- Se indisponível, usar n2-standard-32 spot
- Se ambos indisponíveis, usar c3-standard-22
- Por fim, tentará usar n2-standard-32
- Se nada funcionar, manter o pod pendente até disponibilidade
Selecionando uma ComputeClass nos pods
Para usar uma ComputeClass, você especifica a seleção via nodeSelector:
apiVersion: apps/v1
kind: Deployment
metadata:
name: analytics-pipeline
spec:
replicas: 3
selector:
matchLabels:
app: analytics
template:
metadata:
labels:
app: analytics
spec:
# Seleciona a ComputeClass
nodeSelector:
cloud.google.com/compute-class: data-analysis
containers:
- name: processor
image: gcr.io/seu-projeto/analytics:latest
resources:
requests:
cpu: "8"
memory: "16Gi"
limits:
cpu: "16"
memory: "32Gi"
Quando essa deployment é criada, o GKE automaticamente:
- Lê as prioridades da ComputeClass
data-analysis - Tenta provisionar nós C3
- Aplica rótulos e taints necessários
- Escala horizontalmente conforme necessário
Configurando ComputeClass padrão
Você também pode definir uma ComputeClass como padrão para o cluster ou para um namespace específico:
kubectl patch computeclass default --type merge -p '
{
"spec": {
"whenUnsatisfiable": "ScaleUpAnyway",
"nodePoolAutoCreation": {
"enabled": true
}
}
}'
Com isso, qualquer pod que não especificar uma ComputeClass usará a padrão automaticamente.
Verificando ComputeClasses no seu cluster
Para listar todas as ComputeClasses disponíveis:
kubectl get computeclass
Para ver detalhes de uma específica:
kubectl describe computeclass data-analysis
Para verificar qual ComputeClass está sendo usada pelos nós:
kubectl get nodes -L cloud.google.com/compute-class
Casos de uso recomendados
Quando usar ComputeClasses:
- Análise de dados: Usar máquinas otimizadas para CPU (C3, C2)
- APIs de produção: Usar máquinas balanceadas (N4, N2)
- Machine Learning: Usar máquinas com GPUs/TPUs
- Bancos de dados: Usar máquinas otimizadas para memória
- Cargas variáveis: Definir fallbacks para manter custos baixos
Benefícios principais
✅ Reduz complexidade: Engenheiros de plataforma definem infraestrutura uma vez; operadores selecionam pela classe
✅ Consistência: Todas as cargas de mesmo tipo usam mesma configuração
✅ Flexibilidade: Fallbacks automáticos mantêm cargas rodando mesmo com indisponibilidade
✅ Otimização: Nós são provisionados exatamente como necessário, reduzindo custos
✅ Declarativo: Integra com CI/CD e versionamento de código
O que vem no Part 2?
Este post cobriu os fundamentos e configuração de ComputeClasses. No próximo artigo, vamos aprofundar em:
- Como otimizar nodes criados por ComputeClasses
- Tuning de kernel para extrair máximo desempenho
- Monitoramento e troubleshooting de ComputeClasses
- Consolidação inteligente de nós com autoscaling
- Estratégias de custo combinando ComputeClasses com autoscaling
Acompanhe para dominar essa tecnologia completamente!
Gostou do conteúdo?
- ✅ Inscreva-se na newsletter para receber mais dicas práticas sobre Go e infraestrutura diretamente no seu e-mail!
- 🚀 Conheça a Imersão Golang e leve seus conhecimentos em Go para o próximo nível!
Faça parte da comunidade!
Receba os melhores conteúdos sobre Go, Kubernetes, arquitetura de software, Cloud e esteja sempre atualizado com as tendências e práticas do mercado.
