<h2>Entendendo Deployments em Kubernetes</h2>

<p>Um Deployment é um controlador do Kubernetes que gerencia a criação, atualização e escalabilidade de Pods de forma declarativa. Diferente de criar Pods manualmente, um Deployment garante que o estado desejado seja mantido constantemente — se um Pod falhar, outro será criado automaticamente. Ele utiliza ReplicaSets internamente para gerenciar múltiplas réplicas da mesma aplicação.</p>

<p>Quando você define um Deployment, você descreve qual container executar, quantas réplicas deseja, recursos necessários e políticas de atualização. O Kubernetes então trabalha continuamente para manter aquele estado desejado. Isso é especialmente crítico em produção, onde você não pode parar a aplicação para atualizações.</p>

<pre><code class="language-yaml">apiVersion: apps/v1

kind: Deployment

metadata:

name: webapp

namespace: production

spec:

replicas: 3

selector:

matchLabels:

app: webapp

template:

metadata:

labels:

app: webapp

spec:

containers:

• name: webapp

image: webapp:v1.0.0

ports:

• containerPort: 8080

resources:

requests:

memory: &quot;256Mi&quot;

cpu: &quot;250m&quot;

limits:

memory: &quot;512Mi&quot;

cpu: &quot;500m&quot;

livenessProbe:

httpGet:

path: /health

port: 8080

initialDelaySeconds: 30

periodSeconds: 10</code></pre>

<p>Este exemplo básico cria 3 réplicas de um container <code>webapp</code>. O seletor garante que apenas Pods com a label <code>app: webapp</code> sejam gerenciados por este Deployment. O <code>livenessProbe</code> reinicia o container se deixar de responder.</p>

<h2>Estratégias de Atualização</h2>

<p>Kubernetes oferece duas principais estratégias para atualizar aplicações: <strong>RollingUpdate</strong> (padrão) e <strong>Recreate</strong>. A escolha depende de seus requisitos de disponibilidade e recursos.</p>

<h3>RollingUpdate: Atualizações sem downtime</h3>

<p>Na estratégia RollingUpdate, o Kubernetes substitui Pods antigos pelos novos gradualmente. Você controla quantos Pods podem ser indisponíveis (<code>maxUnavailable</code>) e quantos novos podem ser criados além do desejado (<code>maxSurge</code>). Isso permite que sua aplicação permaneça acessível durante a atualização.</p>

<pre><code class="language-yaml">apiVersion: apps/v1

kind: Deployment

metadata:

name: api-service

spec:

replicas: 4

strategy:

type: RollingUpdate

rollingUpdate:

maxUnavailable: 1

maxSurge: 2

selector:

matchLabels:

app: api-service

template:

metadata:

labels:

app: api-service

spec:

containers:

• name: api

image: api-service:v2.0.0

ports:

• containerPort: 3000

terminationGracePeriodSeconds: 30</code></pre>

<p>Com <code>maxUnavailable: 1</code>, apenas um Pod pode estar indisponível por vez. Com <code>maxSurge: 2</code>, até 6 Pods podem estar rodando simultaneamente durante a atualização (4 desejados + 2 extras). O <code>terminationGracePeriodSeconds</code> dá tempo para requisições em andamento terminarem antes do Pod ser desligado.</p>

<h3>Recreate: Atualização rápida com downtime</h3>

<p>Recreate encerra todos os Pods antigos e cria novos imediatamente. Útil em ambientes de teste ou quando downtime é aceitável, pois é mais rápido e consome menos recursos.</p>

<pre><code class="language-yaml">apiVersion: apps/v1

kind: Deployment

metadata:

name: batch-processor

spec:

replicas: 2

strategy:

type: Recreate

selector:

matchLabels:

app: batch-processor

template:

metadata:

labels:

app: batch-processor

spec:

containers:

• name: processor

image: batch-processor:v3.1.0

env:

• name: BATCH_SIZE

value: &quot;1000&quot;</code></pre>

<p>Use Recreate quando a aplicação não suporta múltiplas versões rodando simultaneamente ou quando o downtime é previsível e aceitável.</p>

<h2>Rollbacks e Revision History</h2>

<p>Kubernetes mantém automaticamente um histórico de revisões do seu Deployment. Cada vez que a especificação do template de Pod muda, uma nova revisão é criada. Você pode consultar esse histórico e reverter para qualquer revisão anterior.</p>

<h3>Visualizando o histórico de revisões</h3>

<pre><code class="language-bash">kubectl rollout history deployment/api-service -n production</code></pre>

<p>Este comando lista todas as revisões, mostrando um identificador de revisão e a descrição (se fornecida). O número de revisões mantidas é controlado por <code>revisionHistoryLimit</code> (padrão é 10).</p>

<pre><code class="language-yaml">apiVersion: apps/v1

kind: Deployment

metadata:

name: api-service

spec:

revisionHistoryLimit: 15

replicas: 3

selector:

matchLabels:

app: api-service

template:

metadata:

labels:

app: api-service

annotations:

deployment.kubernetes.io/revision: &quot;5&quot;

spec:

containers:

• name: api

image: api-service:v2.1.5</code></pre>

<p>Aumentar <code>revisionHistoryLimit</code> permite manter mais histórico, útil quando você precisa reverter para versões muito antigas. Por outro lado, cada revisão consome espaço no etcd.</p>

<h3>Executando um rollback</h3>

<p>Quando algo dá errado com a nova versão, você pode reverter instantaneamente:</p>

<pre><code class="language-bash"># Reverter para a revisão anterior

kubectl rollout undo deployment/api-service -n production

Reverter para uma revisão específica

kubectl rollout undo deployment/api-service --to-revision=8 -n production</code></pre>

<p>O rollback cria uma nova revisão (não volta literalmente para o passado), garantindo que você tenha rastreabilidade completa de todas as mudanças.</p>

<h3>Monitorando o status de um rollout</h3>

<pre><code class="language-bash"># Ver progresso em tempo real

kubectl rollout status deployment/api-service -n production --watch

Ver detalhes de uma revisão específica

kubectl rollout history deployment/api-service --revision=5 -n production</code></pre>

<h2>Casos Práticos e Cenários Avançados</h2>

<h3>Cenário 1: Atualização com problemas detectados</h3>

<p>Imagine que você atualizou sua aplicação e novos Pods começam a falhar nos health checks:</p>

<pre><code class="language-bash"># Ver o status

kubectl get deployment webapp -n prod

Verificar logs do Pod problemático

kubectl logs -l app=webapp -n prod --tail=50

Se necessário, reverter instantaneamente

kubectl rollout undo deployment/webapp -n prod

Verificar a reversão

kubectl rollout status deployment/webapp -n prod --watch</code></pre>

<h3>Cenário 2: Atualização com validação manual</h3>

<p>Para estratégias mais conservadoras, você pode pausar o rollout entre atualizações:</p>

<pre><code class="language-bash"># Iniciar atualização com nova imagem

kubectl set image deployment/webapp webapp=webapp:v2.0.0 -n prod --record

Pausar o rollout

kubectl rollout pause deployment/webapp -n prod

Executar testes (pode ser automático via tests)

Se passou, retomar

kubectl rollout resume deployment/webapp -n prod

Se falhou, reverter

kubectl rollout undo deployment/webapp -n prod</code></pre>

<h3>Cenário 3: Garantindo revisão anterior sempre disponível</h3>

<p>Você pode usar <code>minReadySeconds</code> para garantir que um Pod esteja pronto antes de prosseguir com as próximas atualizações:</p>

<pre><code class="language-yaml">apiVersion: apps/v1

kind: Deployment

metadata:

name: critical-app

spec:

replicas: 5

minReadySeconds: 60

progressDeadlineSeconds: 600

strategy:

type: RollingUpdate

rollingUpdate:

maxUnavailable: 1

maxSurge: 1

selector:

matchLabels:

app: critical-app

template:

metadata:

labels:

app: critical-app

spec:

containers:

• name: app

image: critical-app:v1.5.0

readinessProbe:

httpGet:

path: /ready

port: 8080

initialDelaySeconds: 20

periodSeconds: 5

failureThreshold: 3</code></pre>

<p>O <code>minReadySeconds: 60</code> força esperar 60 segundos após um Pod reportar ready antes de considerar a atualização bem-sucedida. <code>progressDeadlineSeconds: 600</code> aborta a atualização se não completar em 10 minutos, prevenindo hang indefinido.</p>

<h2>Conclusão</h2>

<p>O domínio de Deployments em Kubernetes é fundamental para qualquer engenheiro de plataforma ou DevOps. Você aprendeu que <strong>RollingUpdate oferece atualizações contínuas mantendo disponibilidade</strong>, enquanto Recreate é apropriado para casos específicos. Mais importante ainda, <strong>o Kubernetes mantém automaticamente um histórico de revisões que permite rollbacks em segundos</strong>, eliminando o pânico de deployments errados. Na prática, combine essas estratégias com health checks robustos e automação de testes para ter confiança nas suas atualizações em produção.</p>

<h2>Referências</h2>

<ul>

<li><a href="https://kubernetes.io/docs/concepts/workloads/controllers/deployment/" target="_blank" rel="noopener noreferrer">Kubernetes Documentation: Deployments</a></li>

<li><a href="https://kubernetes.io/docs/concepts/configuration/overview/" target="_blank" rel="noopener noreferrer">Kubernetes Documentation: Rollouts and Rollbacks</a></li>

<li><a href="https://www.manning.com/books/kubernetes-in-action" target="_blank" rel="noopener noreferrer">Kubernetes in Action - Marko Lukša</a></li>

<li><a href="https://www.thekubernetesbook.com/" target="_blank" rel="noopener noreferrer">The Kubernetes Book - Nigel Poulton</a></li>

<li><a href="https://www.oreilly.com/library/view/production-kubernetes/9781492092711/" target="_blank" rel="noopener noreferrer">Production Kubernetes - Liquid Cloud</a></li>

</ul>

<p>&lt;!-- FIM --&gt;</p>