
Curso Kubernetes 20 — Upgrade de nós com segurança
Todo cluster precisa de manutenção: atualizar o SO, o kubelet, aumentar RAM, trocar disco. A diferença entre uma janela tranquila e um incidente é o processo.
Este capítulo fecha a Temporada 2 com o upgrade que fizemos de verdade: workers de 8 GiB para 16 GiB.
Selo do curso: testado em Kubernetes 1.35 e Ubuntu 24.04.
Antes de tocar em qualquer nó
Checklist de pré-voo:
- Capacidade livre nos outros nós para receber os pods.
- PDBs das cargas críticas.
- Anti-affinity (bancos, Elasticsearch, RabbitMQ).
- Quórum (etcd, RabbitMQ, Redis Sentinel).
- Storage preso ao nó (
local-path) e PVCs. - DaemonSets que precisam rodar no nó.
- Backup recente e restore testado.
kubectl get nodes -o wide
kubectl top nodes
kubectl get pdb -A
kubectl get pods -A -o wide | grep <node>
O processo, um nó por vez
1. Cordon
kubectl cordon k8s-worker-01
Nenhum pod novo é agendado ali; os existentes continuam.
2. Drain
kubectl drain k8s-worker-01 --ignore-daemonsets --delete-emptydir-data
O drain respeita PDBs. Se travar, não use --force sem entender: descubra qual PDB está bloqueando.
kubectl get pdb -A
kubectl describe pdb <pdb>
3. Valide o reagendamento
kubectl get pods -A -o wide | grep -v Running
kubectl -n <ns> get pods -o wide
Pods de anti-affinity obrigatória podem ficar Pending até o nó voltar. É esperado — mas você precisa saber quais.
4. Desligue/atualize
- Aumente a RAM na VM/host.
- Atualize o SO e o kubelet, se for o caso.
- Reinicie.
5. Suba e uncordon
kubectl uncordon k8s-worker-01
kubectl get nodes
kubectl get pods -A -o wide | grep k8s-worker-01
6. Valide antes do próximo
- Nós
Ready. - Cargas críticas saudáveis.
- Quórum restaurado.
- PDBs com disrupturas permitidas.
- Métricas sem anomalia.
Ordem importa
Em um cluster com dados:
- Nó sem banco/estado primeiro.
- Réplicas antes do primário.
- Primário por último (com failover planejado).
- Nunca dois nós ao mesmo tempo.
No nosso caso, o worker com o primário do Postgres foi o último.
O que deu errado no nosso upgrade
- MinIO todo em um nó. Os 4 pods estavam no mesmo worker; drenar aquele nó derrubaria o object storage. Movemos os pods antes (cordon + reciclagem), mas descobrimos que a imagem não estava em cache em outro nó —
ErrImagePull. - PDB do MinIO
minAvailable: 3. Drenar um nó com 2 pods violava o PDB. Ajustamos temporariamente para 2. - Postgres primário no nó. O drain exigiu failover; o PDB do primário bloqueava. Fizemos o failover controlado antes.
- Pods Pending por anti-affinity. Com um nó fora, Elasticsearch e RabbitMQ não conseguiam manter 3 réplicas. Esperado; documentamos.
- HPA agressivo. Em outro incidente, 10 pods de backend pressionaram a memória e derrubaram o Postgres. Capacidade não é só CPU.
Upgrade de versão do Kubernetes
Para o kubelet:
kubectl drain <node> --ignore-daemonsets --delete-emptydir-data
sudo apt-mark unhold kubeadm kubelet kubectl
sudo apt install -y kubeadm=1.35.x-1.1 kubelet=1.35.x-1.1 kubectl=1.35.x-1.1
sudo kubeadm upgrade node
sudo systemctl restart kubelet
kubectl uncordon <node>
Masters primeiro (um por vez), depois workers. Nunca pule versões menores.
Erros comuns
| Sintoma | Causa |
|---|---|
| Drain travado | PDB sem disrupturas |
Pods Pending após drain |
anti-affinity/capacidade |
local-path PVC preso |
volume é do nó antigo |
| DaemonSet ausente | taint sem toleration |
| Postgres sem quórum | primário/replica no mesmo nó |
Nó não volta Ready |
kubelet/CNI/relógio |
| HPA escala demais | orçamento de memória ignorado |
Checklist
- [ ] Capacidade nos nós restantes.
- [ ] PDBs revisados.
- [ ] Anti-affinity/quórum mapeados.
- [ ] Backup recente.
- [ ] Cordon + drain + validação.
- [ ] Um nó por vez.
- [ ] Uncordon e validação antes do próximo.
- [ ] PDBs restaurados ao valor original.
Glossário
- cordon: impede novos pods no nó.
- drain: evacua pods do nó.
- uncordon: libera o nó.
- eviction: remoção respeitando PDB.
- quórum: maioria para consenso.
- anti-affinity: regra de distribuição.
Próximo
Temporada 2 concluída. Na Temporada 3 vamos empacotar a aplicação com Helm, versionar no GitOps, montar CI/CD, endurecer segurança, medir capacidade e fechar com SLO e DR.
Próximo: Curso Kubernetes 21 — Helm: empacotando a aplicação
Continuar a ler
Leia também
KubernetesKubernetes de Verdade — do zero ao cluster em produção
Uma trilha prática para entender, montar e operar um cluster Kubernetes — do primeiro pod ao failover do Postgres.
4 min de leitura
KubernetesCurso Kubernetes 28 — DR e capstone: provar que o cluster volta
RPO, RTO e drills reais: cenários de desastre, runbook, restore medido e o capstone que fecha o curso com um cluster que se recupera.
5 min de leitura
KubernetesCurso Kubernetes 27 — SLO/SLI, on-call e postmortem blameless
O que prometer, como medir e o que fazer quando o erro estoura: SLI, SLO, error budget, alertas que acordam alguém e postmortem sem caça às bruxas.
4 min de leitura
Comentários
Ainda sem comentários
Seja o primeiro a compartilhar sua opinião sobre este artigo.
Deixe um comentário