Neste artigo, vou mostrar como configurar o failover automático de um cluster EKS para a sua região de disaster recovery (DR). Antes, uma rápida apresentação do EKS e do Route 53.
O Amazon Elastic Kubernetes Service (EKS) é um serviço totalmente gerenciado que permite rodar Kubernetes na AWS sem precisar instalar, operar ou manter seu próprio control plane ou worker nodes. Com o EKS, você aproveita todo o poder e a flexibilidade do Kubernetes para implantar, gerenciar e escalar aplicações em contêineres em várias zonas de disponibilidade da AWS. O EKS também se integra a diversos serviços e recursos da AWS — IAM, VPC, CloudWatch, CloudFormation e outros — entregando uma plataforma Kubernetes segura, confiável e escalável.
O Amazon Route 53 é um serviço de DNS na nuvem que conecta seus usuários às aplicações e aos recursos web na AWS e na internet. O Route 53 oferece alta disponibilidade, escalabilidade, performance e segurança para consultas e respostas de DNS. Ele também conta com recursos avançados, como health checks, gerenciamento de tráfego, registro de domínios e DNSSEC. E pode trabalhar em conjunto com outros serviços da AWS — como Elastic Load Balancing, CloudFront, S3 e mais — para encaminhar seus usuários ao endpoint ideal da sua aplicação.
Aqui, vou subir dois clusters EKS: um em US-EAST-1 (região de produção) e outro em US-WEST-2 (região de DR). Vou usar um domínio personalizado no cluster de produção via Route 53. Depois, vou rodar o jogo 2048 nos dois clusters e demonstrar o failover automático do Route 53 introduzindo falhas no cluster de produção. Existem várias formas de criar um cluster EKS — AWS Console, Terraform, CloudFormation etc. —, mas vou ficar no AWS Console para simplificar e facilitar o entendimento. Veja abaixo o diagrama conceitual da arquitetura.
Arquitetura conceitual
**Passo 1: Criar um cluster EKS**
Vou mostrar o passo a passo para subir o jogo na região de produção us-east-1; em us-west-2 tenho uma configuração equivalente.
Nome: eks-blog-production-us-east-1
Versão do Kubernetes: 1.25
Cluster Service Role: crie uma role chamada "eksClusterRole" e garanta que ela tenha estas 3 políticas anexadas: AmazonEKSWorkerNodePolicy, AmazonEC2ContainerRegistryReadOnly e AmazonEKS_CNI_Policy.
eksClusterRole
Selecione a VPC padrão e escolha 2 ou 3 sub-redes
Selecione um security group com as portas 22, 80 e 8080 liberadas
Defina o Cluster endpoint access: public
Detalhes completos do cluster antes do lançamento
Passo 2: Adicionar Node Groups ao cluster
Abra o cluster > Compute > Add NodeGrp
Nome: eks-blog-production-eks-nodegrp-1
Cluster Service Role: crie uma role chamada "eksNodeRole" e garanta que ela tenha estas 3 políticas anexadas: AmazonEKSWorkerNodePolicy, AmazonEC2ContainerRegistryReadOnly e AmazonEKS_CNI_Policy.
Mantenha os valores padrão no restante.
EKS Node Group
Passo 3: Autenticar no cluster
Abra o AWS CloudShell e rode os comandos abaixo.
# Digite no AWS CLI
aws sts get-caller-identity
# observe os detalhes da sua conta e do user id
# Cria um arquivo kubeconfig com as credenciais do EKS:
# A configuração do kubeconfig permite conectar ao cluster pela linha de comando kubectl.
aws eks update-kubeconfig --region us-east-1 --name eks-blog-production-us-east-1
# verifique se você consegue ver os nodes que criou
kubectl get nodes
Saída dos comandos
Passo 4: Criar um novo Pod no EKS para o jogo 2048
Crie o arquivo 2048-pod.yaml abaixo para implantar o pod do jogo 2048 no cluster.
### code starts ###
apiVersion: v1
kind: Pod
metadata:
name: 2048-pod
labels:
app: 2048-ws
spec:
containers:
- name: 2048-container
image: blackicebird/2048
ports:
- containerPort: 80
### code ends ###
Aplique o arquivo YAML para criar o pod
# aplica o arquivo de configuração para criar o pod
kubectl apply -f 2048-pod.yaml
#pod/2048-pod created
# veja o pod recém-criado
kubectl get pods
Pod 2048 criado
Passo 5: Configurar o serviço de Load Balancer
Agora vamos configurar um serviço de load balancer criando o arquivo YAML de serviço mygame-svc.yaml, conforme abaixo.
### code starts ###
apiVersion: v1
kind: Service
metadata:
name: mygame-svc
spec:
selector:
app: 2048-ws
ports:
- protocol: TCP
port: 80
targetPort: 80
type: LoadBalancer
### code ends ###
Aplique o arquivo do serviço de Load Balancer.
# aplica o arquivo de configuração
kubectl apply -f mygame-svc.yaml
# veja os detalhes do serviço modificado
kubectl describe svc mygame-svc
Serviço de Load Balancer criado
Ao colar o endpoint do Load Balancer "ab8412c93389c4e29beb8c5e3778d368–260705609.us-east-1.elb.amazonaws.com" no navegador, o jogo carrega.
Passo 6: Apontar o domínio [www.doyouneedk8s.com](http://www.doyouneedk8s.com/) para o jogo
Acesse a hosted zone do Route 53 do domínio www.doyouneedk8s.com e adicione o endpoint do Load Balancer como um registro CNAME. Após a propagação do DNS, ao colar o domínio no navegador, o jogo aparece carregando.
CNAME no Route 53
Passo 7: Provocar uma falha
Agora, suponha que a região US Virginia sofra uma indisponibilidade. Vamos simular manualmente uma falha na aplicação em US-EAST-1: vou remover a regra de entrada da porta 80 do security group do Load Balancer. O jogo deixa de carregar — afinal, ainda não há failover configurado para a aplicação de produção.
Passo 8: Configurar o failover do Route 53 para a região de DR
O primeiro passo é criar um Health Check no Route 53 para a sua aplicação. Acesse o Route 53, selecione "Health Checks" no menu lateral esquerdo e clique em "Create Health Check".
Nome: www.doyouneedk8s.com
What to monitor: Endpoint
Monitor an endpoint > selecione Domain Name > preencha www.doyouneedk8s.com no campo Domain Name, Porta 80
Tela 1 de criação do Health Check
Ao clicar em Next, na tela seguinte você tem a opção de criar um alarme para esse evento, para ser notificado quando o failover ocorrer. É bem simples: basta ter um SNS topic verificado e selecioná-lo. Marque Yes em "Create Alarm". Depois, clique em "Create health check".
Criar health check
Você verá um health check verde com status "Healthy" assim que ele atender aos parâmetros definidos.
Health Check pronto para uso
Volte à hosted zone de www.doyouneedk8s.com no Route 53. Selecione o registro CNAME e, em Routing Policy, escolha "Failover".
Failover record type: Secondary
Health Check ID: o health check do domínio criado anteriormente.
Record ID: o Load Balancer de US-WEST-2 que foi criado quando você subiu o jogo na região US Oregon. Salve o registro.
Hora de testar. Repita a mesma falha do Passo 7. Desta vez, o jogo continua funcionando. Para deixar o resultado mais claro, coloquei um texto diferente na página do jogo, sinalizando que ele está sendo servido pela região de DR.
Failover de DR concluído com sucesso
Conclusão
O Route 53 é uma ferramenta realmente poderosa da AWS para montar estratégias robustas de DR e continuidade de negócios. No artigo, mostrei o conceito de como executar o failover, mas manter os clusters de produção e de DR sincronizados em relação a atualizações de código fica por sua conta. Outro ponto: ao adotar essa estratégia de failover, faça testes de sanidade com regularidade em janelas de manutenção para confirmar que tanto a aplicação de produção quanto a de DR estão funcionando como esperado.