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 »

Neste post, vou explicar o que é TinyGo, por que você deveria conhecer e como começar com um exemplo bem simples. Se você nunca ouviu falar em TinyGo ou simplesmente quer entender esse universo de programação para microcontroladores, esse post é para você.

O que é TinyGo?

TinyGo é um compilador Go otimizado para ambientes com recursos limitados. Enquanto a linguagem Go tradicional foi criada para sistemas desktop, como CLIs, e servidores, como aplicações cloud, o TinyGo permite que você escreva código Go para rodar em microcontroladores e pequenos dispositivos.

A ideia é simples: leve a simplicidade e a elegância do Go para o mundo do IoT (Internet das Coisas) e sistemas embarcados.

Leia mais »