In diesem Artikel zeige ich Ihnen, wie Sie ein automatisches Failover für einen EKS-Cluster in Ihre Disaster-Recovery-Region (DR) einrichten. Vorab eine kurze Einordnung von EKS und Route 53.
Amazon Elastic Kubernetes Service (EKS) ist ein vollständig verwalteter Dienst, mit dem Sie Kubernetes auf AWS betreiben, ohne eine eigene Kubernetes Control Plane oder Worker Nodes installieren, betreiben oder warten zu müssen. Mit EKS nutzen Sie die Stärken und die Flexibilität von Kubernetes, um Ihre containerisierten Anwendungen über mehrere AWS Availability Zones hinweg auszurollen, zu verwalten und zu skalieren. EKS lässt sich zudem nahtlos mit zahlreichen AWS-Diensten und Funktionen wie IAM, VPC, CloudWatch oder CloudFormation verzahnen – für eine sichere, zuverlässige und skalierbare Kubernetes-Plattform.
Amazon Route 53 ist ein cloud-basierter DNS-Dienst, der Ihre Nutzer mit Ihren Webanwendungen und Ressourcen auf AWS und im Internet verbindet. Route 53 bietet hohe Verfügbarkeit, Skalierbarkeit, Performance und Sicherheit für DNS-Anfragen und -Antworten. Darüber hinaus stehen Funktionen wie Health Checks, Traffic Management, Domain-Registrierung und DNSSEC zur Verfügung. Route 53 spielt zudem mit weiteren AWS-Diensten wie Elastic Load Balancing, CloudFront oder S3 zusammen und leitet Ihre Nutzer zuverlässig an den optimalen Endpoint Ihrer Anwendung.
Für dieses Beispiel starte ich zwei EKS-Cluster: einen in US-EAST-1 (Produktionsregion) und einen in US-WEST-2 (DR-Region). Für den Produktionscluster nutze ich eine eigene Domain über Route 53. Anschließend lasse ich auf beiden Clustern eine 2048-Spielanwendung laufen und zeige das automatische Failover von Route 53, indem ich gezielt Ausfälle im Produktionscluster provoziere. Einen EKS-Cluster können Sie auf vielen Wegen aufsetzen – über die AWS-Konsole, Terraform, CloudFormation und weitere Tools. Ich nutze hier die AWS-Konsole, damit das Vorgehen für alle gut nachvollziehbar bleibt. Unten sehen Sie das zugehörige Architekturkonzept.
Konzeptionelle Architektur
**Schritt 1: EKS-Cluster anlegen**
Im Folgenden zeige ich die Schritte für die Produktionsregion us-east-1; ein vergleichbares Setup steht in us-west-2 bereit.
Name: eks-blog-production-us-east-1
Kubernetes-Version: 1.25
Cluster Service Role: Legen Sie eine Rolle "eksClusterRole" an und stellen Sie sicher, dass die folgenden drei Policies zugewiesen sind: AmazonEKSWorkerNodePolicy, AmazonEC2ContainerRegistryReadOnly und AmazonEKS_CNI_Policy.
eksClusterRole
Wählen Sie die Default-VPC und 2 oder 3 Subnetze aus.
Wählen Sie eine Security Group, in der die Ports 22, 80 und 8080 freigegeben sind.
Cluster-Endpoint-Zugriff: public
Vollständige Cluster-Details vor dem Start
Schritt 2: Node Groups zum Cluster hinzufügen
Cluster öffnen > Compute > Add NodeGrp
Name: eks-blog-production-eks-nodegrp-1
Cluster Service Role: Legen Sie eine Rolle "eksNodeRole" an und stellen Sie sicher, dass die folgenden drei Policies zugewiesen sind: AmazonEKSWorkerNodePolicy, AmazonEC2ContainerRegistryReadOnly und AmazonEKS_CNI_Policy.
Alle übrigen Einstellungen lassen Sie auf den Standardwerten.
EKS Node Group
Schritt 3: Am Cluster authentifizieren
Öffnen Sie die AWS Cloud Shell und führen Sie die folgenden Befehle aus.
# Im AWS-CLI-Fenster ausführen
aws sts get-caller-identity
# Account- und User-ID-Details prüfen
# kubeconfig-Datei anlegen, in der die EKS-Anmeldedaten gespeichert werden:
# Über die kubeconfig stellen Sie die Verbindung zum Cluster mit dem kubectl-CLI her.
aws eks update-kubeconfig --region us-east-1 --name eks-blog-production-us-east-1
# prüfen, ob die erstellten Nodes abrufbar sind
kubectl get nodes
Befehlsausgaben
Schritt 4: Neuen Pod in EKS für das 2048-Spiel anlegen
Erstellen Sie die folgende Datei 2048-pod.yaml, um den 2048-Game-Pod im Cluster auszurollen.
### 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 ###
Wenden Sie die YAML-Datei an, um den Pod anzulegen.
# Konfigurationsdatei anwenden, um den Pod anzulegen
kubectl apply -f 2048-pod.yaml
#pod/2048-pod created
# den neu erstellten Pod anzeigen
kubectl get pods
2048-Pod angelegt
Schritt 5: Load-Balancer-Service einrichten
Jetzt richten wir einen Load-Balancer-Service ein. Legen Sie dazu die folgende Service-YAML-Datei mygame-svc.yaml an.
### 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 ###
Wenden Sie die Service-Datei an.
# Konfigurationsdatei anwenden
kubectl apply -f mygame-svc.yaml
# Details des angepassten Service anzeigen
kubectl describe svc mygame-svc
Load-Balancer-Service angelegt
Wenn Sie den Load-Balancer-Endpoint "ab8412c93389c4e29beb8c5e3778d368–260705609.us-east-1.elb.amazonaws.com" im Browser aufrufen, lädt das Spiel.
Schritt 6: Domain [www.doyouneedk8s.com](http://www.doyouneedk8s.com/) auf das Spiel routen
Wechseln Sie in Route 53 zur Hosted Zone der Domain www.doyouneedk8s.com und legen Sie den Load-Balancer-Endpoint als CNAME-Record an. Sobald der DNS-Eintrag propagiert ist, lädt das Spiel im Browser, wenn Sie die Domain aufrufen.
Route 53 CNAME
Schritt 7: Ausfall provozieren
Nehmen wir an, in US Virginia tritt eine Störung auf. Wir lösen manuell ein Failover für die Anwendung in US-EAST-1 aus, indem ich die Inbound-Regel für Port 80 aus der Security Group des Load Balancers entferne. Das Spiel lädt nicht mehr, da für die Produktionsanwendung bislang kein Failover hinterlegt ist.
Schritt 8: Route-53-Failover in die DR-Region einrichten
Im ersten Schritt legen Sie in Route 53 einen Health Check für Ihre Anwendung an. Öffnen Sie Route 53, wählen Sie in der linken Navigation "Health Checks" und klicken Sie auf "Create Health Check".
Name: www.doyouneedk8s.com
What to monitor: Endpoint
Monitor and endpoint > Domain Name auswählen > www.doyouneedk8s.com im Feld Domain Name eintragen, Port 80
Health Check anlegen – Seite 1
Nach einem Klick auf "Next" können Sie auf der Folgeseite einen Alarm zu diesem Ereignis einrichten, damit Sie über das Failover informiert werden. Das ist schnell erledigt: Sie brauchen nur ein verifiziertes SNS-Topic und wählen es aus. Setzen Sie "Create Alarm" auf "Yes" und klicken Sie anschließend auf "Create health check".
Health Check anlegen
Sobald der Health Check die festgelegten Parameter erfüllt, erscheint er mit dem grünen Status "Healthy".
Health Check einsatzbereit
Wechseln Sie in Route 53 zur Hosted Zone von www.doyouneedk8s.com. Wählen Sie den CNAME-Record aus und stellen Sie unter Routing Policy die Option "Failover" ein.
Failover record type: Secondary
Health Check ID: der zuvor erstellte Domain-Health-Check.
Record ID: der Load Balancer in US-WEST-2, der beim Start des Spiels in der US-Oregon-Region angelegt wurde. Speichern Sie den Eintrag.
Jetzt geht es ans Testen. Provozieren Sie denselben Ausfall wie in Schritt 7 – diesmal läuft das Spiel weiter. Zur Veranschaulichung habe ich auf der Spielseite einen abweichenden Text hinterlegt, sodass klar zu erkennen ist, dass das Spiel jetzt aus der DR-Region ausgeliefert wird.
DR-Failover erfolgreich
Fazit:
Route 53 ist ein ausgesprochen leistungsfähiges Werkzeug von AWS, um robuste DR- und Business-Continuity-Strategien aufzubauen. In diesem Artikel habe ich gezeigt, wie sich ein Failover umsetzen lässt – die Synchronisierung von Code-Updates zwischen Produktions- und DR-Cluster bleibt jedoch in Ihrer Verantwortung. Wenn Sie diese Failover-Strategie produktiv einsetzen, sollten Sie zudem regelmäßig im Wartungsfenster einen Sanity-Test durchführen, um sicherzugehen, dass Produktions- und DR-Anwendung einwandfrei funktionieren.