1. Estado Atual (Blue)

Duração: 5 min

Vamos explorar o ambiente atual - um cluster EKS 1.34 servindo 100% do tráfego.

Verificar a versão do cluster

1
kubectl --context eks-blue version | grep Server

Resultado esperado: Server Version: v1.34.x-eks-...

Nodes do cluster (MNG core + Karpenter workload)

1
kubectl --context eks-blue get nodes -L role,karpenter.sh/nodepool

Resultado esperado: 2 nodes "core" (MNG, t3.large) + 1-2 nodes Karpenter (spot, workload)

Aplicação rodando

1
kubectl --context eks-blue get pods -n demo -o wide

Resultado esperado: 3 pods demo-app nos nodes Karpenter

Registro weighted no Route53

1
2
3
aws route53 list-resource-record-sets --hosted-zone-id $ZONE_ID \
  --query "ResourceRecordSets[?Name=='app.bluegreen.lab.'].[SetIdentifier,Weight]" \
  --output table

Resultado esperado: eks-blue | 100 (100% do tráfego no blue)

Testar o app (de dentro da VPC)

1
2
3
4
5
kubectl --context eks-blue run test --rm -i --restart=Never \
  --image=python:3.13-slim -- python3 -c "
import json, urllib.request
r = json.load(urllib.request.urlopen('http://app.bluegreen.lab/'))
print(json.dumps(r, indent=2))"

Resultado esperado: {"cluster": "eks-blue", "message": "hello from the eks-blue cluster"}

Ponto-chave

Este cluster está 2 versões atras. O upgrade in-place de control plane EKS não tem rollback. Em Outposts Local Clusters v1, nem existe botao de upgrade pra v2. Vamos resolver dos dois jeitos: não atualizar, e sim SUBSTITUIR - sem que o usuário perceba.