Se você está começando com Kubernetes no Google Cloud, provavelmente se deparou com duas opções: GKE Standard e GKE Autopilot. Neste post, vamos entender o que é cada uma, suas diferenças fundamentais e quando usar uma ou outra. Ao final, você saberá exatamente qual escolher para sua arquitetura.

O que é GKE?

Google Kubernetes Engine (GKE) é o serviço gerenciado de Kubernetes oferecido pela Google Cloud. Ele abstrai a complexidade de manter um cluster Kubernetes, delegando tarefas críticas (como atualizações, scaling de nós e monitoramento da control plane) para o Google.

O GKE não é apenas um Kubernetes rodando em máquinas virtuais. É uma plataforma inteligente que oferece diferentes níveis de automação e controle, dependendo de como você quer operá-la.

GKE vs Kubernetes Self-Hosted

Antes de compararmos Standard e Autopilot, é importante entender por que usar GKE em vez de instalar Kubernetes na mão.

Instalação Self-Hosted

Quando você instala Kubernetes manualmente em VMs, você é responsável por:

• Gerenciar a control plane: Manter etcd, kube-apiserver, kube-controller-manager e kube-scheduler rodando e saudáveis
• Atualizar versões: Planejamento, testes e execução de upgrades do cluster
• Escalabilidade de nós: Adicionar, remover e substituir máquinas manualmente ou via scripts customizados
• Monitoramento e alertas: Implementar sua própria estratégia de observabilidade
• Segurança e patches: Aplicar patches de kernel, atualizar componentes, gerenciar certificados
• Networking: Configurar plugins CNI, gerenciar IPs e roteamento

É viável, mas exige expertise profunda e consome muitos recursos operacionais.

Leia mais »

Neste post, vamos explorar como mapear e entender a memória de programas Go 1.27 no Linux. Com o crescimento de aplicações Go em produção, saber o que está acontecendo na memória é essencial para otimizar performance e debugar problemas. Vou mostrar as ferramentas que surgiram para facilitar essa tarefa.

O que significa mapear a memória?

Mapear a memória é entender como seu programa Go está usando a RAM do sistema. Não é só sobre quanto de memória está sendo usado, mas onde essa memória está sendo alocada, qual estrutura de dados está consumindo mais bytes e se há vazamentos de memória.

No Linux, você pode ver essa informação de várias formas. As mais comuns são:

• pprof — o profiler integrado do Go que mostra allocations e heap
• /proc/maps — arquivo do kernel que lista todas as regiões de memória do processo
• runtime.MemStats — estatísticas do runtime do Go em tempo real

Por que isso importa no Go 1.27?

O Go 1.27 trouxe melhorias significativas no runtime e no garbage collector. Essas mudanças tornaram mais fácil (e necessário) entender como a memória está sendo distribuída. Se você está migrando de versões antigas, provavelmente quer verificar se o comportamento de memória mudou.

Leia mais »

A partir do Go 1.27, podemos finalmente detectar goroutine leaks de forma nativa e sem precisar de flags experimentais. Neste post, vamos entender como funciona esse novo perfil de detecção e como usá-lo na prática para evitar um dos bugs mais difíceis de rastrear em aplicações Go.

O que é um Goroutine Leak?

Um goroutine leak ocorre quando uma goroutine fica bloqueada indefinidamente em alguma primitiva de concorrência (channels, sync.Mutex, sync.Cond, etc.) e nunca consegue ser desbloqueada. Diferente de uma goroutine que apenas dorme, uma goroutine em leak está prisioneira — nenhum outro código pode libertá-la.

Isso é um problema sério porque goroutines consomem memória. Se sua aplicação cria milhares delas sem desbloqueá-las, você terá vazamento de memória gradual e difícil de diagnosticar.

Como o Runtime Detecta Leaks

O Go 1.27 usa uma abordagem elegante baseada no garbage collector:

1. O runtime executa um ciclo de GC (Garbage Collector)
2. Para cada goroutine, verifica se ela está bloqueada em uma primitiva de concorrência
3. Verifica se aquela primitiva é alcançável a partir de alguma goroutine que possa ser desbloqueada
4. Se a primitiva for inalcançável, a goroutine está vazando

Esse mecanismo funciona porque se uma primitiva é inalcançável, ninguém pode sinalizar para ela, portanto a goroutine nunca acordará.

Leia mais »

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

1. Declaração: Engenheiros de plataforma definem ComputeClasses em manifestos YAML
2. Registro: As ComputeClasses são criadas como recursos personalizados no cluster
3. Seleção: Operadores de apps especificam uma ComputeClass nos seus pods usando nodeSelector
4. Escalonamento: O cluster autoscaler usa as prioridades definidas para criar nós apropriados
5. Configuração: O GKE aplica automaticamente rótulos, taints e tolerâncias aos nós criados

Leia mais »

Se você trabalha com cargas de trabalho de AI/ML ou aplicações que levam minutos para inicializar no GKE, Pod Snapshot é uma feature que pode mudar o jogo. Neste post, vou explicar o que é, por que importa e como implementar.

O que é Pod Snapshot?

Pod Snapshot é um recurso do GKE que captura o estado completo de um Pod em execução — incluindo memória, estado da CPU, GPU e alterações no sistema de arquivos — e o salva no Cloud Storage. Quando um novo Pod precisa ser criado, em vez de começar do zero, o GKE restaura esse snapshot e o Pod retoma a execução exatamente de onde estava.

Diferente de Volume Snapshot (que captura apenas dados persistentes), Pod Snapshot congela toda a runtime do seu aplicativo, incluindo a memória com o modelo de IA já carregado, todas as dependências inicializadas, e qualquer estado computado.

Por que Isso Importa

Cargas de trabalho de AI/ML são notoriamente lentas para inicializar. Um modelo de 70B parâmetros pode levar vários minutos apenas para ser carregado na memória da GPU. Com Pod Snapshot, você reduz esse tempo para segundos.

Números reais do GCP:

• Modelo 70B: Startup normal = ~300s | Com snapshot = ~80s (73% mais rápido)
• Modelo 8B: Startup normal = ~60s | Com snapshot = ~16s (73% mais rápido)

Cenários onde Pod Snapshot brilha:

• Inferência de AI/ML — reduz latência de cold start para usuários
• Batch jobs pesados — inicia processamento em segundos em vez de minutos
• Aplicações com muitas dependências — Node.js, Python com libs grandes
• Auto-scaling — novos replicas escalam instantaneamente

Leia mais »

O Fyne acaba de chegar à versão 2.8 com mais de mil commits, trazendo novos componentes de gráficos, APIs melhoradas e otimizações que tornam o desenvolvimento de aplicações desktop com Go ainda mais prático. Neste post, vamos explorar o que mudou e como você pode aproveitar essas novidades.

O que é Fyne?

Fyne é um framework Go para construir interfaces gráficas modernas que funcionam no Linux, macOS e Windows com o mesmo código. Diferente de outras abordagens que geram binários pesados, o Fyne oferece um controle fino sobre performance e tamanho de arquivo — ideial para apps desktop leves e responsivos.

Se você trabalha com Go e já se perguntou como fazer uma boa GUI sem mergulhar em C++, Fyne é a resposta.

Novidades da v2.8

Novos componentes de gráficos

A v2.8 introduziu um novo package canvas com suporte expandido para gráficos e renderização. Agora você pode criar visualizações mais elaboradas sem depender de bibliotecas externas complexas.

Leia mais »

Se você trabalha com Go e gerencia dependências via módulos, já deve ter se deparado com um arquivo go.mod bagunçado — com blocos require duplicados que geram confusão e versionamento inconsistente. Na versão 1.27 do Go, o comando go mod tidy ganhou uma nova responsabilidade: mesclar automaticamente blocos de require duplicados.

Neste post, vamos entender como essa feature simplifica a vida do desenvolvedor.

O que é go mod tidy?

O go mod tidy é o comando responsável por limpar e organizar seu arquivo go.mod. Ele:

• Remove dependências não utilizadas
• Adiciona dependências que faltam
• Garante que as versões estejam sincronizadas com go.sum
• Reorganiza o arquivo em um formato padrão

Desde o surgimento dos Go Modules (Go 1.11), ele é essencial para manter a saúde do seu projeto.

Leia mais »

O Go 1.27 traz uma mudança esperada por muitos desenvolvedores: métodos genéricos. Depois de anos mantendo essa funcionalidade fora da linguagem, o Go finalmente permite declarar parâmetros de tipo diretamente em métodos.
Neste post, vamos entender o que são, como usá-los e por que isso muda a forma como escrevemos código genérico.

O que são Generic Methods?

Generic methods (métodos genéricos) são métodos que declaram seus próprios parâmetros de forma genérica, independentemente da struct ser genérica. Em outras palavras, você pode ter um método com parâmetros genéricos em uma struct que não é genérica.

Antes do Go 1.27, para ter um método genérico, você precisava tornar toda a struct genérica. No entanto, agora, tudo o que você precisa fazer é colocar os parâmetros de genéricos diretamente no método onde são necessários.

A sintaxe é simples:

func (r ReceiverType) MethodName[T any](param T) T {
    // implementação
}

Leia mais »

Desde que eu trabalhava como SRE, havia um workload na empresa o qual era praticamente impossível de colocar 2 pods em um mesmo node sem uma degradação muito grande em sua performance.

No início desse ano, fiz uma mudança interna de carreira, indo trabalhar exatamente no time que cuida desse workload. Isso me possibilitou estudá-lo intensivamente durante alguns meses, até que entendi o por que dele perder performance.

Nesse post, vou compartilhar algumas das minhas descobertas, e como fiz para resolver o problema de ter 2 pods com TFSS rodando no mesmo node.

O problema

Além da questão mencionada acima, ter somente 1 pod por node trás outros problema, como por exemplo, quando precisamos escalar o ambiente, além do tempo que o workload leva para ficar pronto, ainda temos o tempo que o provider leva para provisionar um novo node.

Outra problema associado a escalabilidade é que, se alguma parte do seu cluster for formado por nodes spot, ainda há o risco de throttling, caso seja solicitado um grande número de nodes de uma só vez.

A solução

Como eu disse inicialmente, foram meses estudando e entendendo profundamente desde como o workload funcionava, até como é a arquitetura de hardware do GCP nas máquinas que usamos.

E nesse ponto você pode estar imaginando que a solução deve ser extremamente complexa. Pois acredite se quiser, ela não é!

Leia mais »

Imagens Docker gigantes são um problema silencioso em ambientes Kubernetes. Você já parou para pensar quanto tempo e banda estão sendo gastos puxando uma imagem de 2GB para cada novo deployment? Neste post, vou compartilhar estratégias práticas para reduzir o tamanho das suas imagens sem sacrificar funcionalidade.

O que é otimização de imagens de container?

É o processo de reduzir o tamanho do arquivo (layer) de uma imagem Docker mantendo toda a funcionalidade necessária. Uma imagem menor significa pulls mais rápidos, menos consumo de armazenamento no registry e deploys mais eficientes em Kubernetes.

Por que isso importa em Kubernetes?

Em um cluster Kubernetes, você pode ter dezenas ou centenas de nodes. Quando você faz um deploy de uma nova versão, o kubelet precisa fazer o pull da imagem. Uma imagem de 500MB vs. 100MB não parece grande diferença, mas multiplique por 50 nodes e você está falando de 20GB de transferência versus 5GB.

Sem contar que imagens menores consomem menos espaço em disco nos nodes, deixam menos margem para node pressure, e tornam o scaling mais ágil.

Leia mais »