In 10 Minuten zum Kubernetes Cluster auf AWS

Keine Kommentare

Kubernetes wird von Google entwickelt, um containerisierte Anwendungen über mehre Rechner hinweg zu betreiben. Es bietet verschiedene Funktionen für die Auslieferung, den Betrieb und die Skalierung von Anwendungen. Mittlerweile hat Google die Version 1.0 freigegeben, in der die jahrelange Erfahrung im Betrieb von Linux-Containern des Suchmaschine-Betreibers eingeflossen ist. Wie ich in meinem Artikel “Microservice-Deployment ganz einfach mit Kubernetes” zeige, eignet es sich außerdem hervorragend um eine verteilte Microservice-Anwendung auf mehreren Rechnern auszuführen. In diesem Artikel betrachten wir, wie wir ein Kubernetes-Cluster möglichst schnell mit Amazon Web Services (AWS) aufbauen können. Ziel ist: In 10 Minuten ein lauffähiges Kubernetes-Cluster zu erstellen, um ein erstes Deployment durchzuführen.

Überblick

Ein Kubernetes-Cluster besteht aus verschiedenen Komponenten. Es gibt Rechner, die Anwendungen ausführen. Diese Rechner werden als Nodes (früher Minion) bezeichnet. Außerdem gibt es das Kubernetes Control Plane, das auch Master bezeichnet wird und die Steuerung des Clusters übernimmt. Eine weitere wichtige Komponente ist das Kommandozeilen-Programm ”kubectl”, mit dem das Cluster von einem Clientrechner gesteuert wird und mit dem Deployments durchgeführt werden.

In der folgenden Architektur-Darstellung sind alle Komponenten eines Kubernetes-Clusters zu sehen. Zugeben wirkt es nicht so als ob ein Kubernetes-Cluster schneller installiert werden kann, als in München zum Flughafen zukommen. Doch genau das werden wir in diesem Artikel tun. Zunächst betrachten wir allerdings die einzelnen Komponenten ein bisschen genauer.

Auf jedem Node läuft ein Docker-Daemon. Docker ist verantwortlich für das Herunterladen von Image-Dateien, aus denen eine containerisierte Anwendung besteht, und deren Ausführung als einzelne Anwendungen innerhalb von verschiedenen Containern. Der Service, der Docker und den Master verbindet, wird Kublet genannt. Der Service muss auf jedem Node installiert werden. Der Kublet-Service kontrolliert je nachdem vom Master vorgeben Clusterzustand das Ausführen von Pods. Ein Pod ist eine einzeln auslieferbare Einheit, die aus einem oder mehren Docker-Containern bestehen kann. Alle Container, die sich in einem Pod befinden, laufen garantiert auf dem selben Node, was ermöglicht, dass sich diese Container ein gemeinsames Volume teilen können.

Neben dem Kublet-Service befindet sich auf jedem Node der sogenannte Kube-Proxy. Der Kube-Proxy ist ein Netzwerk-Proxy und Load Balancer. Als Ambassador sorgt der Proxy dafür, dass alle Service-Endpunkte auf jedem Knoten verfügbar sind und leitet Netzwerk-Pakete an die entsprechenden Docker Container weiter.

Aktuell werden die Service-Endpunkte entweder über DNS aufgelöst oder über Umgebungsvariablen den laufenden Container bekannt gemacht. Diese Variablen sind kompatibel zu den Docker-Links– oder Docker-Compose-Umgebungsvariablen. Das folgende Listing zeigt, wie diese grundsätzlich aussehen:

bz@cc $ kubectl exec shop-rf9eu env
...
MONGODB_PORT_27017_TCP=tcp://172.17.0.28:27017
MONGODB_PORT_27017_TCP_ADDR=172.17.0.28
MONGODB_PORT_27017_TCP_PORT=27017
MONGODB_PORT_27017_TCP_PROTO=tcp

Das Kubernetes Control Plane (auch Master) besteht aus mehren Komponenten, die alle auf einem Rechner installiert werden. Diese sollen aber in einer späteren Kubernetes-Version auch auf mehrere Knoten verteilt werden, um einen High-availability(HA)-Cluster zu realisieren.

Der gesamte Zustand des Clusters wird in Etcd gespeichert. Etcd ist ein hierarchischer, verteilter Key-Value-Store. In Etcd werden die Kubernetes-spezifischen Konfigurationen  gespeichert. Über so genannte Watches erfolgt die Koordination des Clusters.

Um mit dem Programm ”kubectl” auf das Cluster zuzugreifen, gibt es den Kubernetes API-Server. Der API-Server stellt die Kubernetes API bereit. Er verarbeitet alle REST-Operationen, validiert sie und aktualisiert die entsprechenden Objekte in Etcd. Um Pods auf den Nodes zu verteilen, gibt es den Scheduler. Der Scheduler benutzt die Kubernetes API. Alle anderen Cluster-Funktionen werden vom Kubernetes Controller Manager Server ausgeführt, der sich unter anderem um die Replication Controller kümmert.

Kubernetes-Installation auf AWS

AWS zählt zu den beliebtesten Cloud-Computing-Angeboten und bietet seinen Benutzern IT-Infrastruktur auf Knopfdruck zu erzeugen. Damit eignet sich AWS perfekt dafür, um den Aufbau eines Kubernetes-Clusters auszuprobieren.

Um ein Kubernetes-Cluster auf AWS zu installieren, sind folgende Vorbedingungen zu erfüllen:

  1. Sie benötigen einen AWS-Account, den Sie auf http://aws.amazon.com erstellen können,
  2. Installieren und konfigurieren Sie das AWS Command Line Interface,
  3. Außerdem benötigen Sie ein AWS Instanz Profil und Role mit EC2-Vollzugriff.

Um einen Cluster auf AWS zu installieren, empfiehlt Google das folgende Skript auszuführen. Vor der Ausführung sollte man die Umgebungsvariable KUBERNETES_PROVIDER entsprechend auf “aws” setzen:

bz@cc $ export KUBERNETES_PROVIDER=aws && wget -q -O - https://get.k8s.io | bash
…
Kubernetes cluster is running.  The master is running at:
 
  https://54.194.131.40
 
The user name and password to use is located in /Users/berndzuther/.kube/config.
 
... calling validate-cluster
Found 3 node(s).
NAME                                        LABELS                                                             STATUS    AGE
ip-172-20-0-79.eu-west-1.compute.internal   kubernetes.io/hostname=ip-172-20-0-79.eu-west-1.compute.internal   Ready     55s
ip-172-20-0-80.eu-west-1.compute.internal   kubernetes.io/hostname=ip-172-20-0-80.eu-west-1.compute.internal   Ready     55s
ip-172-20-0-81.eu-west-1.compute.internal   kubernetes.io/hostname=ip-172-20-0-81.eu-west-1.compute.internal   Ready     56s
Validate output:
NAME                 STATUS    MESSAGE              ERROR
etcd-0               Healthy   {"health": "true"}   nil
etcd-1               Healthy   {"health": "true"}   nil
controller-manager   Healthy   ok                   nil
scheduler            Healthy   ok                   nil
Cluster validation succeeded
Done, listing cluster services:
 
Kubernetes master is running at https://54.194.131.40
Elasticsearch is running at https://54.194.131.40/api/v1/proxy/namespaces/kube-system/services/elasticsearch-logging
Heapster is running at https://54.194.131.40/api/v1/proxy/namespaces/kube-system/services/heapster
Kibana is running at https://54.194.131.40/api/v1/proxy/namespaces/kube-system/services/kibana-logging
KubeDNS is running at https://54.194.131.40/api/v1/proxy/namespaces/kube-system/services/kube-dns
KubeUI is running at https://54.194.131.40/api/v1/proxy/namespaces/kube-system/services/kube-ui
Grafana is running at https://54.194.131.40/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana
InfluxDB is running at https://54.194.131.40/api/v1/proxy/namespaces/kube-system/services/monitoring-influxdb
 
Kubernetes binaries at /Users/berndzuther/development/kubernetes/cluster/
You may want to add this directory to your PATH in $HOME/.profile
Installation successful!

Der Installationsprozess dauert ungefähr 10 Minuten und nachdem das Kubernetes-Cluster vollständig hochgefahren und installiert ist, erscheint eine Meldung, die alle IP-Adressen vom Master, den installierten Komponenten und allen Nodes anzeigt. Die Authentifikationsdaten und Sicherheitstoken werden in der Datei ~/.kube/config gespeichert, die notwendig ist um das Kommandozeilen-Programm ”kubectl” zu verwenden.

Im Standard erstellt das Script eine Amazon Virtual Private Cloud (VPC) mit 4 Node in der Region us-west-2a (Oregon) mit EC2-Instanzen auf denen Ubuntu als Betriebsystem läuft. Diese Eigenschaften des Clusteres kann man mit Umgebungsvariablen überschreiben, die in der Datei config-default.sh definiert sind.

Um das Cluster wieder zu löschen, muss einfach nur der folgenden Befehl ausführt werden. Dann sind alle Objekte, wie EC2 Instanzen und Volumes, in AWS wieder gelöscht.

bz@cc $ KUBE_AWS_ZONE=eu-west-1c kubernetes/cluster/kube-down.sh

Zugriff auf das Kubernetes-Cluster

Um auf das Cluster zuzugreifen, empfiehlt Google das Programm ”kubectl” zu verwenden. Damit können Operationen wie das Ausführen von Pods oder das Erstellen von Services gesteuert werden. Das Programm benutzen wir als Nächstes, um eine Anwendung im Cluster zu deployen. Im folgenden Listing zeige ich, wie der Beispiel-Online-Shop deployt wird, den ich in meinem Artikel “Microservices und die Jagd nach mehr Konversion” beschreibe.

bz@cc $ git clone https://github.com/zutherb/AppStash.git appstash 
Cloning into 'appstash'...
remote: Counting objects: 16244, done.
remote: Total 16244 (delta 0), reused 0 (delta 0), pack-reused 16244
Receiving objects: 100% (16244/16244), 139.09 MiB | 540.00 KiB/s, done.
Resolving deltas: 100% (6322/6322), done.
Checking connectivity... done.
bz@cc $ cd kubernetes/example/shop
 
bz@cc $ kubectl create -f redis.yml
replicationcontroller "redis" created
bz@cc $ kubectl create -f redis-service.yml
service "redis" created
bz@cc $ kubectl create -f cart.yml
replicationcontroller "cart" created
bz@cc $ kubectl create -f cart-service.yml
service "cart" created
bz@cc $ kubectl create -f mongodb.yml
replicationcontroller "mongodb" created
bz@cc $ kubectl create -f mongodb-service.yml
service "mongodb" created
bz@cc $ kubectl create -f product.yml
replicationcontroller "product" created
bz@cc $ kubectl create -f product-service.yml
service "product" created
bz@cc $ kubectl create -f navigation.yml
replicationcontroller "navigation" created
bz@cc $ kubectl create -f navigation-service.yml
service "navigation" created
bz@cc $ kubectl create -f shop.yml
replicationcontroller "shop" created
bz@cc $ kubectl create -f shop-service.yml
service "shop" created
bz@cc $ kubectl create -f catalog.yml
replicationcontroller "catalog" created
bz@cc $ kubectl create -f catalog-service.yml
service "catalog" created
 
bz@cc $  kubectl get pods
NAME               READY     STATUS       RESTARTS   AGE
cart-5qy3o         1/1       Running            0              4m
...
catalog-m41a8      0/1       Pending            0              4m
...‚
mongodb-q2a04      1/1       Running            0              4m
navigation-8c3d9   1/1       Running            1              4m
...
product-ozjig      1/1       Running            0              4m
…
redis-1n74h        1/1       Running            0              4m
shop-5vrpi         0/1       Pending            0              4m
...

Wenn alle Pods den Status “Running” haben, was man mit dem Kommando “kubectl get pods” überprüfen kann, kann auf die Anwendung zugegriffen werden. Dazu müssen wir aber noch die Adresse ermitteln, über die wir auf die Anwendung zugreifen können. Dazu wird für den Calalog-Service in AWS ein Elastic Load Balancer (ELB) erstellt. Ein ELB leitet den Datenverkehr automatisch auf eine oder mehrere EC2-Instanzen um.

elb

Fazit

Wie wir anhand dieses Artikels sehen können, ist die Installation eines Kubernetes-Clusters denkbar einfach und das Cluster kann bei einer guten Internetleitung wirklich in 10 Minuten in Betrieb genommen werden. Google stellt alle Skripte bereit, um einen Cluster sofort starten zu können. Die benötigte IT-Infrastruktur bekommt man sehr einfach von der Cloud-Computing-Plattform AWS oder der Google Cloud Plattform. So kann man die Infrastruktur ganz einfach wieder entsorgen, sobald die Experimente abgeschlossen sind.

Bernd Zuther

Kampferprobter Projektveteran, der immer fokussiert auf die Lieferung von funktionierender Software in der vorgegebenen Zeit ist. Zu seinen stärksten Waffen gehören ein sicherer Umgang mit agilen Methoden wie Scrum und sein breit gestreutes IT-Wissen, das er gezielt dazu einsetzt, auch die schwierigsten Problemstellungen pragmatisch und einfach zu lösen.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.