En este artículo te muestro cómo configurar un failover automático de un clúster EKS hacia tu región de recuperación ante desastres (DR). Va una breve introducción a EKS y Route 53.
Amazon Elastic Kubernetes Service (EKS) es un servicio totalmente administrado que te permite correr Kubernetes en AWS sin tener que instalar, operar ni mantener tu propio plano de control de Kubernetes ni los nodos worker. Con EKS aprovechas la potencia y la flexibilidad de Kubernetes para desplegar, administrar y escalar tus aplicaciones en contenedores en varias zonas de disponibilidad de AWS. Además, EKS se integra con muchos servicios y funciones de AWS, como IAM, VPC, CloudWatch, CloudFormation y más, para ofrecerte una plataforma de Kubernetes segura, confiable y escalable.
Amazon Route 53 es un servicio DNS en la nube que te ayuda a conectar a tus usuarios con tus aplicaciones web y recursos en AWS y en internet. Route 53 ofrece alta disponibilidad, escalabilidad, rendimiento y seguridad para tus consultas y respuestas DNS. También admite funciones avanzadas, como health checks, gestión de tráfico, registro de nombres de dominio y DNSSEC. Route 53 puede trabajar con otros servicios de AWS, como Elastic Load Balancing, CloudFront, S3 y más, para enrutar a tus usuarios al endpoint óptimo de tu aplicación.
En este artículo voy a lanzar dos clústeres EKS, uno en US-EAST-1 (región de producción) y otro en US-WEST-2 (región DR). Para el clúster de producción uso un dominio personalizado a través de Route 53. Después voy a correr el juego 2048 en ambos clústeres y a mostrar el failover automático de Route 53 introduciendo fallos en el clúster de producción. Hay varias maneras de lanzar un clúster EKS, como la consola de AWS, Terraform, CloudFormation, etc., pero voy a usar la consola de AWS para mantenerlo simple y que se entienda mejor. Abajo se muestra un diagrama conceptual de la arquitectura.
Arquitectura conceptual
**Paso 1: Crear un clúster EKS**
Voy a mostrar los pasos para lanzar el juego en la región de producción us-east-1. Tengo una configuración similar disponible en us-west-2.
Nombre: eks-blog-production-us-east-1
Versión de Kubernetes: 1.25
Cluster Service Role: Tienes que crear un rol "eksClusterRole" y asegurarte de que tenga estas 3 políticas asociadas: AmazonEKSWorkerNodePolicy, AmazonEC2ContainerRegistryReadOnly y AmazonEKS_CNI_Policy.
eksClusterRole
Selecciona la VPC predeterminada y elige 2 o 3 subredes.
Selecciona un security group que tenga abiertos los puertos 22, 80 y 8080.
Acceso al endpoint del clúster: público
Detalle completo del clúster antes del lanzamiento
Paso 2: Agregar Node Groups al clúster
Abre el clúster > Compute > Add NodeGrp
Nombre: eks-blog-production-eks-nodegrp-1
Cluster Service Role: Tienes que crear un rol "eksNodeRole" y asegurarte de que tenga estas 3 políticas asociadas: AmazonEKSWorkerNodePolicy, AmazonEC2ContainerRegistryReadOnly y AmazonEKS_CNI_Policy.
Deja los valores predeterminados en todo lo demás.
EKS Node Group
Paso 3: Autenticarse en el clúster
Abre AWS Cloud Shell y ejecuta los siguientes comandos.
# Ejecuta en tu ventana de AWS CLI
aws sts get-caller-identity
# observa los detalles de tu cuenta y user id
# Crea un archivo kubeconfig donde se almacenan las credenciales para EKS:
# La configuración de kubeconfig te permite conectarte a tu clúster usando la línea de comandos kubectl.
aws eks update-kubeconfig --region us-east-1 --name eks-blog-production-us-east-1
# verifica si puedes obtener los nodos que creaste
kubectl get nodes
Salida de los comandos
Paso 4: Crear un nuevo POD en EKS para el juego 2048
Crea el siguiente archivo 2048-pod.yaml para desplegar el pod del juego 2048 en el clúster.
### inicio del código ###
apiVersion: v1
kind: Pod
metadata:
name: 2048-pod
labels:
app: 2048-ws
spec:
containers:
- name: 2048-container
image: blackicebird/2048
ports:
- containerPort: 80
### fin del código ###
Aplica el archivo YAML para crear el pod.
# aplica el archivo de configuración para crear el pod
kubectl apply -f 2048-pod.yaml
#pod/2048-pod created
# visualiza el pod recién creado
kubectl get pods
Pod 2048 creado
Paso 5: Configurar el servicio Load Balancer
Ahora vamos a configurar un servicio de balanceador de carga creando un archivo YAML llamado mygame-svc.yaml como el siguiente.
### inicio del código ###
apiVersion: v1
kind: Service
metadata:
name: mygame-svc
spec:
selector:
app: 2048-ws
ports:
- protocol: TCP
port: 80
targetPort: 80
type: LoadBalancer
### fin del código ###
Aplica el archivo del servicio Load Balancer.
# aplica el archivo de configuración
kubectl apply -f mygame-svc.yaml
# visualiza los detalles del servicio modificado
kubectl describe svc mygame-svc
Servicio Load Balancer creado
Cuando pegas el endpoint del Load Balancer "ab8412c93389c4e29beb8c5e3778d368–260705609.us-east-1.elb.amazonaws.com" en el navegador, se carga el juego.
Paso 6: Enrutar el dominio [www.doyouneedk8s.com](http://www.doyouneedk8s.com/) hacia el juego.
Entra a la zona alojada de Route 53 para el dominio www.doyouneedk8s.com y agrega el endpoint del Load Balancer como un registro CNAME. Una vez que se propague el registro DNS, al pegar el dominio en el navegador verás cargar el juego.
CNAME en Route 53
Paso 7: Provocar un fallo
Supongamos que US Virginia tiene una caída. Vamos a provocar un fallo manual en la aplicación de US-EAST-1. Para eso, voy a eliminar la regla de entrada del puerto 80 en el security group del Load Balancer. El juego dejará de cargar, ya que no hay failover configurado para la aplicación de producción.
Paso 8: Configurar el failover de Route 53 hacia la región DR
Lo primero es crear un Health Check para tu aplicación en Route 53. Entra a Route 53, selecciona "Health Checks" en el menú lateral izquierdo y haz clic en el botón "Create Health Check".
Nombre: www.doyouneedk8s.com
Qué monitorear: Endpoint
Monitor and endpoint > Selecciona Domain Name > Agrega www.doyouneedk8s.com en el cuadro de texto Domain Name, puerto 80.
Crear Health Check, página 1
Después de hacer clic en Next, en la siguiente página tienes la opción de crear una alarma para este evento y así recibir una notificación cuando ocurra el failover. Es muy simple: solo necesitas un SNS topic verificado y lo seleccionas. Marca Yes en "Create Alarm" y luego haz clic en "Create health check".
Crear health check
Verás un health check en verde con el estado "Healthy" una vez que pase los parámetros configurados.
Health Check listo para usar
Entra a la zona alojada de www.doyouneedk8s.com en Route 53. Selecciona el registro CNAME y, en Routing Policy, selecciona "Failover".
Failover record type: Secondary
Health Check ID: el health check de dominio que creaste antes.
Record ID: el Load Balancer de US-WEST-2 que se creó cuando lanzaste el juego en la región US Oregon. Guarda el registro.
Ahora toca probar. Vuelve a provocar el mismo fallo del paso 7 y esta vez verás que el juego sigue funcionando. Para que se note la diferencia, agregué un texto distinto en la página del juego, así sabemos que ahora se está sirviendo desde la región DR.
Failover de DR exitoso
Conclusión:
Route 53 es una herramienta muy potente de AWS para crear estrategias robustas de DR y continuidad del negocio. En el artículo demostré el concepto para lograr el failover, pero mantener sincronizadas las actualizaciones de código entre los clústeres de producción y DR queda de tu lado. Además, si configuras esta estrategia de failover, conviene hacer pruebas de funcionamiento de forma periódica en ventanas de mantenimiento para verificar que ambas aplicaciones, Prod y DR, funcionen correctamente.