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.

Como dito anteriormente, o papel do Deployment é registrar as configurações de uma aplicação no Kubernetes, ou seja, ele não é o responsável por gerenciar se os pods estão sendo executados ou não. Para isso, existe um outro objeto chamado ReplicaSet.

Controladores de Pods

Uma das funcionalidades que fazem o Kubernetes ser lindo, é a sua capacidade de gerenciar automaticamente o estado de seus objetos.

Imagine comigo, quão ruim seria se você tivesse que:

• Reiniciar um container quando ele encerrar de forma inesperada.
• Gerenciar a quantidade de replicas.
• Fazer balanceamento de carga entre as replicas na mão.
• Decidir manualmente onde (em qual máquina do cluster) cada uma de suas replicas será executada.
• Ao lançar uma nova versão da app, tivesse que parar cada uma das replicas com a versão antiga e iniciar as replicas com a nova versão.

Pois bem, ao utilizar Kubernetes, não precisamos nos preocupar com nada disso. Isso por que ele foi projetado para tirar todo esse trabalho manual das nossas mãos, através de um recurso chamado controladores.

Agora vamos falar sobre três tipos de controladores existentes no Kubernetes.

ReplicaSets

Esse tipo de objeto é criado automaticamente pelo Deployment, ou seja, você não configura e nem interage diretamente com ele.

O papel de uma ReplicaSet é, manter em sincronia o estado especificado no Deployment, com o estado real do cluster Kubernetes. Esse processo é chamado de reconciliation loop.

Para exemplificar, imagine que a quantidade de réplicas configuradas no Deployment é alterada. Essa mudança fará com que a ReplicaSet execute ou remova Pods até que a quantidade especificada seja atendida.

Para que não haja conflito entre o nome das réplicas, um sufixo é adicionado automaticamente. Como os Pods sobem em paralelo, esse sufixo é uma hash gerada aleatoriamente.

StatefulSets

Embora objetos do tipo StatefulSets também sejam controladores de Pods, existe uma grande diferença entre eles e ReplicaSets.

Enquanto a ReplicaSet inicia/encerra seus Pods em paralelo, objetos do tipo StatefulSet o fazem em sequência. Em outras palavras, levando em consideração um StatefulSet com 3 réplicas, ele só iniciará o segundo Pod após o primeiro estar 100% funcional.

Além disso, para que os nomes das réplicas sejam únicos, o controlador adiciona um sufixo sequencial, iniciando em 0, a cada uma delas.

StatefulSets são muito utilizados para aplicações que tem estado, como por exemplo, MongoDB, Redis e Postgres.

DaemonSets

Para finalizar, vamos falar sobre DaemonSet. Para entendê-lo melhor, imagine que temos um cluster Kubernetes com vários nós. Cada um desses nós com várias aplicações e réplicas sendo executadas.

Agora, imagine que precisamos adicionar um agente para coletar logs das aplicações.

Uma das formas de se fazer isso, seria adicionando um container extra a cada um dos Pods. Essa técnica é chamada de sidecar.

Escolher essa solução, faria com que dezenas ou talvez até centenas de agentes de logs fossem executados em cada um dos nós. Como cada agente consome alguma quantidade de recurso, no fim, embora a solução resolva o problema, estaríamos desperdiçando recursos.

Uma abordagem melhor seria ter somente 1 agente sendo executado por nó. É aí que entra o DaemonSet, pois esse tipo de objeto, só permite que um Pod seja executado em cada nó.

Conclusão

Nesse post falamos sobre três tipos de deploy que podemos fazer no Kubernetes. Entendemos seus objetivos, particularidades e diferenças.

No próximo post sobre controladores de Pod, vou falar sobre Job, CronJob e Horizontal Pod Autoscalers (HPA).

Para não perder nada, não deixe de se inscrever na nossa newsletter.

Espero que esse post tenha sido útil.

Até a próxima!

Se inscreva na nossa newsletter