In-Place Pod Resize — redimensionando sem restart

Se você trabalha com Kubernetes em produção, sabe que ajustar recursos de CPU e memória geralmente significa recriar os pods. Neste post, vamos explorar o In-Place Pod Resize, um recurso que permite redimensionar containers sem perder o uptime.

O que é In-Place Pod Resize?

In-Place Pod Resize é uma funcionalidade do Kubernetes que permite alterar os requests e limits de CPU e memória de um container enquanto o pod continua rodando. Não há reinicialização, sem downtime, sem interrupção de conexões.

Antes dessa feature, a única forma era deletar e recriar o pod com novos valores — algo impraticável em ambientes críticos.

Por que isso importa?

Imagine este cenário: você subiu uma aplicação com 256Mi de memória, achando que era suficiente. Alguns dias depois, monitoramento mostra que está usando 400Mi, próximo ao limite. Você precisa aumentar — e rápido.

Leia mais »

O que é e como configurar affinity e anti-affinity no Kubernetes

Embora o Kubernetes faça um ótimo trabalho em escalonar os pods de um cluster, algumas vezes, e SOMENTE algumas vezes (note o negrito, itálico e sublinhado), precisamos controlar como e onde os pods serão escalonados.

Para resolver esses casos, que são (ou pelo menos deveriam ser) raros de acontecer, utilizamos as funcionalidades de Affinity e Anti-Affinity do Kubernetes.

Ao utilizar essas funcionalidades, podemos decidir em quais tipos de nodes os pods serão escalonados, além de especificar que determinados pods sejam escalonados próximos ou distantes uns dos outros.

Também “dizemos” ao Kubernetes qual é a expectativa sobre as condições definidas no Affinity ou Anti-Affinity. Em outras palavras, precisamos dizer se as condições precisam ser atendidas (modo hard), ou se seria bom que elas fossem atendidas (modo soft).

Para o modo hard, utilizamos a chave requiredDuringSchedulingIgnoreDuringExecution. Já para o modo soft, a chave preferredDuringSchedulingIgnoreDuringExecution.

Leia mais »

Qual a diferença e quando utilizar Deployment, StatefulSet e DaemonSet

Hoje iniciamos uma nova série aqui no blog, a Kubernetes 101. Nessa série, vou escrever sobre o funcionamento e utilização do Kubernetes do ponto de vista dev. Em outras palavras, não vamos entrar nos detalhes e funcionamentos internos do orquestrador, mas sim como utilizá-lo para executar aplicações.

E para começar essa série, nada melhor do que explicar as diferenças e aplicabilidades dos objetos Deployment, StatefulSet e DaemonSet.

Deployments

Esse tipo de objeto do Kubernetes serve como uma espécie de supervisor. Seu papel principal é registrar algumas informações no Kubernetes, como por exemplo, os nomes das imagens que compõe um Pod e o número de réplicas a serem executadas.

A utilização de objetos do tipo Deployment é recomendada para aplicações que não dependem de um estado, ou seja, aplicações stateless. Se você não está familiarizado com o termo, uma aplicação stateless, basicamente, caso tenha sua execução interrompida, uma nova instância pode ser executada sem nenhuma dependência da execução anterior. Salvo algumas exceções, normalmente esse tipo de aplicação não precisa de um disco para ser executada.

Leia mais »