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 »

Em sistemas distribuídos, é comum precisar garantir que apenas uma instância de um serviço execute uma tarefa crítica — seja backup, sincronização de dados ou processamento de eventos. O Kubernetes oferece a State Lock API exatamente para isso: coordenação segura entre múltiplos pods.

Neste post, vamos entender como usar State Lock API, quando usá-la, compará-la com outras abordagens e implementar um exemplo prático.

O que é State Lock API?

A State Lock API do Kubernetes (via leaderelection) é um mecanismo que permite que múltiplas réplicas de um aplicativo coordenem entre si para eleger um “líder” — uma única instância responsável por executar tarefas críticas.

Ela funciona através de:

• Recurso ConfigMap ou Lease: armazena informações sobre quem é o líder
• Renovação periódica: o líder renova seu “lock” em intervalos regulares
• Eleição automática: se o líder falhar, outro pod toma o lugar

Leia mais »

Neste post, vamos explorar uma mudança pequena, mas poderosa, que chegou no Go 1.26: o built-in new() agora aceita uma expressão como valor inicial. Pode parecer um detalhe, mas simplifica inicializações e abre espaço para padrões de código mais elegantes.

O que é o built-in new()?

O new() é uma função built-in que aloca memória para um tipo e retorna um ponteiro inicializado com o valor zero do tipo. Historicamente, você só podia passar um tipo para new().

Como era antes (Go 1.25 e anteriores)

Antes, se você quisesse alocar memória e inicializar com um valor específico, tinha duas opções:

// Opção 1: alocar e depois atribuir
p := new(int)
*p = 42

// Opção 2: usar composição literal com &
p := &int{42}  // Só funciona com tipos estruturados

Leia mais »

Quando você coloca uma aplicação em produção no Kubernetes, uma das decisões mais importantes é como especificar os recursos que seus pods precisam. Essa escolha determina qual classe de Quality of Service (QoS) seu pod recebe — e isso impacta diretamente na sua estabilidade e custo. Neste post, vou explicar em detalhe os três níveis de QoS: Guaranteed, Burstable e BestEffort.

O que é QoS no Kubernetes?

QoS (Quality of Service) é um mecanismo que o Kubernetes usa para classificar e priorizar seus pods em relação ao uso de recursos. Quando o nó está sem memória ou CPU disponível, o Kubernetes usa a classe QoS para decidir qual pod será removido (evicted) ou compactado.

O Kubernetes define três classes de QoS:

• BestEffort — mínima prioridade, primeira a ser removida
• Burstable — prioridade média, removida após Guaranteed
• Guaranteed — máxima prioridade, última a ser removida

Qual classe seu pod recebe depende de como você especifica os requests e limits de CPU e memória.

QoS BestEffort: Máxima Flexibilidade, Sem Garantias

Um pod é classificado como BestEffort quando:

• Você não define requests nem limits de CPU ou memória
• É a situação padrão quando você simplesmente não especifica nada

Leia mais »