Kubernetes Federation in Multi-Cloud-Umgebungen
Wolkenlenker
Ein Kubernetes-Cluster über Cloud-Grenzen hinweg verspricht auch Ausfälle ganzer Cloud-Regionen abzufangen. Ein Blick auf verschiedene Methoden, das praktisch umzusetzen.
Eine der häufigsten Anforderungen an den Betrieb einer Anwendung im Unternehmen ist Hochverfügbarkeit. In den vergangenen Jahren haben sich viele Konzepte herausgebildet, die den Zugriff auf eine Applikation von einer fehlerhaften Instanz auf eine funktionierende umschwenken. Zeitgleich hat an vielen Stellen ein Umzug von Diensten in die Cloud begonnen, sei es, um Kosten zu sparen oder weil man über die verschiedenen Regionen und Zonen der Cloud auch im Falle von Netzwerkproblemen in einem Datacenter erreichbar sein möchte.
Parallel dazu haben sich für einfacheres Deployment Container-Lösungen wie Kubernetes verbreitet. Sie versprechen hohe Verfügbarkeit etwa durch automatisches Neustarten von Anwendungen oder Load Balancing über mehrere Instanzen hinweg. Allerdings schützt der Einsatz von Kubernetes allein nicht vor dem Ausfall eines ganzen Rechenzentrums oder gar eines Cloud-Anbieters. Multi-Cloud, also der Betrieb mehrerer Kubernetes-Cluster verteilt über verschiedene Regionen beziehungsweise Anbieter, ist ein Ansatz, dieser Problematik beizukommen.
Kubernetes Federation – Multicluster von Haus aus
Einer der möglichen Wege zum verteilten und ausfallsicheren Betrieb eigener Anwendungen führt über kubefed – ein Kubernetes-Bordmittel. Mit dem Federation-Projekt beziehungsweise dem zugehörigen Kommandozeilentool kubefed lassen sich mehrere Kubernetes-Cluster an verschiedenen Standorten verbinden und so quasi als ein Cluster nutzen. Dennoch besteht weiterhin die Möglichkeit, die Cluster einzeln anzusprechen.
Bis zur Version 1.8 war die Federation-Komponente ein integraler Bestandteil von Kubernetes, danach gliederte man sie aus. Heute führt die hierfür gegründete Multicluster Special Interest Group sie als eigenständiges Projekt.
Wie Abbildung 1 zeigt, ist der Aufbau einer Federation denkbar einfach: Als Erstes muss man eine Control Plane in einen schon existierenden Kubernetes-Cluster ausrollen, also kubefed selbst. Es übernimmt in der Funktion als Control Plane die gesamte Steuerung der Verteilung der Deployments innerhalb der Cluster. Gleichzeitig überwacht es auch den Status der Deployments über alle verbundenen Cluster.
Die Control Plane benötigt gleichzeitig einen Nameservice, zum Beispiel Googles Cloud DNS oder Amazons Route 53. Sie braucht diesen, um die DNS-Einträge für die einzeln Services anzulegen beziehungsweise zu aktualisieren.
Listing 1: AWS- und GCE-Cluster in die Kubernetes Federation aufnehmen
$ kubefed2 join aws-cluster1 --cluster-context aws-cluster1 --host-cluster-context aws-cluster1 --add-to-registry --v=2 [...] [...] Creating service account in joining cluster: aws-cluster1 [...] [...] Created secret in host cluster named: aws-cluster1-229nv [...] Created secret in host cluster: aws-cluster1 [...] Cluster credentials secret created [...] Creating federated cluster resource [...] Created federated cluster resource $ kubefed2 join gce-cluster2 --cluster-context gce-cluster2 --host-cluster-context aws-cluster1 --add-to-registry --v=2 [...] [...] Creating service account in joining cluster: gce-cluster2 [...] [...] Created secret in host cluster named: gce-cluster2-j4wc6 [...] Created secret in host cluster: aws-cluster1 [...] Cluster credentials secret created [...] Creating federated cluster resource [...] Created federated cluster resource
kubefed steuert die Federation über seinen Namespace federation-system. Ist die Control Plane erst mal in Betrieb, kann man nun weitere Kubernetes-Cluster hinzufügen, im Beispiel dieses Artikels in Listing 1 sind das AWS (Amazon Web Services) beziehungsweise EKS (Amazon Elastic Container Service for Kubernetes) und GCE (Google Compute Engine) respektive GKE (Google Kubernetes Engine). Hat das für beide Cluster funktioniert, kann man sie sich mit dem Aufruf kubectl get clusters anzeigen lassen: