In questo articolo vedremo come configurare il failover automatico di un cluster EKS verso la regione di disaster recovery (DR). Iniziamo con una breve introduzione a EKS e Route 53.
Amazon Elastic Kubernetes Service (EKS) è un servizio completamente gestito che permette di eseguire Kubernetes su AWS senza dover installare, gestire o mantenere il control plane Kubernetes o i nodi worker. Con EKS si possono sfruttare la potenza e la flessibilità di Kubernetes per distribuire, gestire e scalare le applicazioni containerizzate su più zone di disponibilità AWS. EKS si integra inoltre con numerosi servizi e funzionalità AWS — IAM, VPC, CloudWatch, CloudFormation e altri ancora — per offrire una piattaforma Kubernetes sicura, affidabile e scalabile.
Amazon Route 53 è un servizio DNS in cloud che collega gli utenti alle applicazioni web e alle risorse su AWS e su Internet. Route 53 garantisce alta disponibilità, scalabilità, prestazioni e sicurezza nelle query e risposte DNS. Supporta inoltre funzionalità avanzate come health check, gestione del traffico, registrazione di domini e DNSSEC. Route 53 si integra con altri servizi AWS — Elastic Load Balancing, CloudFront, S3 e molti altri — per indirizzare gli utenti all'endpoint ottimale per la propria applicazione.
In questo articolo avvieremo due cluster EKS: uno in US-EAST-1 (regione di produzione) e uno in US-WEST-2 (regione DR). Per il cluster di produzione utilizzerò un dominio personalizzato gestito tramite Route 53. Eseguiremo poi il gioco 2048 su entrambi i cluster e dimostreremo il failover automatico di Route 53 introducendo dei guasti nel cluster di produzione. Per avviare un cluster EKS esistono diverse strade — AWS Console, Terraform, CloudFormation, ecc. — ma userò la AWS Console per mantenere tutto semplice e accessibile a chiunque. Di seguito un diagramma concettuale dell'architettura.
Architettura concettuale
**Step 1: creare un cluster EKS**
Vediamo i passaggi per avviare il gioco nella regione di produzione us-east-1; ho già predisposto una configurazione analoga in us-west-2.
Nome: eks-blog-production-us-east-1
Versione di Kubernetes: 1.25
Cluster Service Role: occorre creare un ruolo "eksClusterRole" assicurandosi che abbia associate queste 3 policy: AmazonEKSWorkerNodePolicy, AmazonEC2ContainerRegistryReadOnly e AmazonEKS_CNI_Policy.
eksClusterRole
Selezionare la VPC predefinita e scegliere 2 o 3 subnet.
Selezionare un security group con le porte 22, 80, 8080 aperte.
Cluster endpoint access: public
Dettaglio completo del cluster prima dell'avvio
Step 2: aggiungere i Node Group al cluster
Aprire il cluster > Compute > Add NodeGrp
Nome: eks-blog-production-eks-nodegrp-1
Cluster Service Role: occorre creare un ruolo "eksNodeRole" assicurandosi che abbia associate queste 3 policy: AmazonEKSWorkerNodePolicy, AmazonEC2ContainerRegistryReadOnly e AmazonEKS_CNI_Policy.
Lasciare i valori predefiniti per tutto il resto.
EKS Node Group
Step 3: autenticarsi al cluster
Aprire AWS CloudShell ed eseguire i comandi seguenti.
# Digita nella finestra della AWS CLI
aws sts get-caller-identity
# osserva i dettagli dell'account e dello user id
# Crea un file kubeconfig in cui memorizza le credenziali per EKS:
# La configurazione kubeconfig consente di connettersi al cluster tramite la riga di comando kubectl.
aws eks update-kubeconfig --region us-east-1 --name eks-blog-production-us-east-1
# verifica di poter recuperare i nodi creati
kubectl get nodes
Output dei comandi
Step 4: creare un nuovo POD in EKS per il gioco 2048
Creare il file 2048-pod.yaml seguente per distribuire nel cluster il pod del gioco 2048.
### 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 ###
Applicare il file YAML per creare il pod.
# applica il file di configurazione per creare il pod
kubectl apply -f 2048-pod.yaml
#pod/2048-pod created
# visualizza il pod appena creato
kubectl get pods
Pod 2048 creato
Step 5: configurare il servizio Load Balancer
Configuriamo ora un servizio di load balancer creando un file YAML di servizio mygame-svc.yaml come quello qui sotto.
### 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 ###
Applicare il file del servizio Load Balancer.
# applica il file di configurazione
kubectl apply -f mygame-svc.yaml
# visualizza i dettagli del servizio modificato
kubectl describe svc mygame-svc
Servizio Load Balancer creato
Incollando l'endpoint del Load Balancer "ab8412c93389c4e29beb8c5e3778d368–260705609.us-east-1.elb.amazonaws.com" nel browser, vedremo il gioco caricarsi.
Step 6: instradare il dominio [www.doyouneedk8s.com](http://www.doyouneedk8s.com/) verso il gioco
Aprire la hosted zone di Route 53 per il dominio www.doyouneedk8s.com e aggiungere l'endpoint del Load Balancer come record CNAME. Una volta propagato il record DNS, incollando il dominio nel browser vedremo il gioco caricarsi.
Record CNAME in Route 53
Step 7: introdurre un guasto
Ipotizziamo ora che la regione US Virginia subisca un'interruzione del servizio. Simuleremo un failover manuale dell'applicazione in US-EAST-1 rimuovendo la regola Inbound sulla porta 80 dal Security Group del Load Balancer. Il gioco smetterà di caricarsi, perché per l'applicazione di produzione non è ancora previsto alcun failover.
Step 8: configurare il failover di Route 53 verso la regione DR
In questo passaggio dobbiamo prima creare un Health Check per la nostra applicazione su Route 53. Aprire Route 53, selezionare "Health Checks" nella barra di navigazione a sinistra e fare clic su "Create Health Check".
Nome: www.doyouneedk8s.com
What to monitor: Endpoint
Monitor and endpoint > selezionare Domain Name > inserire www.doyouneedk8s.com nella casella Domain Name, porta 80.
Pagina 1 della creazione dell'Health Check
Dopo aver fatto clic su Next, nella pagina successiva si può creare un Allarme per ricevere una notifica in caso di failover. La procedura è molto semplice: basta selezionare un topic SNS già verificato. Selezionare Yes in "Create Alarm", quindi fare clic su "Create health check".
Creazione dell'health check
Quando l'health check supererà i parametri impostati, lo stato apparirà in verde con la dicitura "Healthy".
Health Check pronto all'uso
Tornare alla hosted zone di www.doyouneedk8s.com in Route 53. Selezionare il record CNAME e, in Routing Policy, scegliere "Failover".
Failover record type: Secondary
Health Check ID: l'health check del dominio creato in precedenza.
Record ID: il Load Balancer di US-WEST-2 creato all'avvio del gioco nella regione US Oregon. Salvare il record.
Ora passiamo al test. Reintroducendo lo stesso guasto descritto nello Step 7, vedremo che questa volta il gioco continua a funzionare. Per renderlo evidente ho modificato un testo nella pagina del gioco, così da capire a colpo d'occhio che il gioco viene servito dalla regione DR.
Failover DR riuscito
Conclusioni
Route 53 è uno strumento davvero potente offerto da AWS per costruire strategie solide di DR e Business Continuity. In questo articolo ho mostrato come realizzare il failover, ma mantenere allineati il cluster di produzione e quello di DR rispetto agli aggiornamenti del codice resta una responsabilità dell'utente. Inoltre, una volta implementata la strategia di failover descritta, è opportuno eseguire test periodici di sanity check durante le finestre di manutenzione, per verificare che entrambe le applicazioni — Prod e DR — funzionino correttamente.