In 10 Minuten zum Kubernetes Cluster auf AWS

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.

Kubernetes Architektur – https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/design/architecture.md

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:

1bz@cc $ kubectl exec shop-rf9eu env
2...
3MONGODB_PORT_27017_TCP=tcp://172.17.0.28:27017
4MONGODB_PORT_27017_TCP_ADDR=172.17.0.28
5MONGODB_PORT_27017_TCP_PORT=27017
6MONGODB_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:

1bz@cc $ export KUBERNETES_PROVIDER=aws && wget -q -O - https://get.k8s.io | bash
2…
3Kubernetes cluster is running.  The master is running at:
4 
5  https://54.194.131.40
6 
7The user name and password to use is located in /Users/berndzuther/.kube/config.
8 
9... calling validate-cluster
10Found 3 node(s).
11NAME                                        LABELS                                                             STATUS    AGE
12ip-172-20-0-79.eu-west-1.compute.internal   kubernetes.io/hostname=ip-172-20-0-79.eu-west-1.compute.internal   Ready     55s
13ip-172-20-0-80.eu-west-1.compute.internal   kubernetes.io/hostname=ip-172-20-0-80.eu-west-1.compute.internal   Ready     55s
14ip-172-20-0-81.eu-west-1.compute.internal   kubernetes.io/hostname=ip-172-20-0-81.eu-west-1.compute.internal   Ready     56s
15Validate output:
16NAME                 STATUS    MESSAGE              ERROR
17etcd-0               Healthy   {"health": "true"}   nil
18etcd-1               Healthy   {"health": "true"}   nil
19controller-manager   Healthy   ok                   nil
20scheduler            Healthy   ok                   nil
21Cluster validation succeeded
22Done, listing cluster services:
23 
24Kubernetes master is running at https://54.194.131.40
25Elasticsearch is running at https://54.194.131.40/api/v1/proxy/namespaces/kube-system/services/elasticsearch-logging
26Heapster is running at https://54.194.131.40/api/v1/proxy/namespaces/kube-system/services/heapster
27Kibana is running at https://54.194.131.40/api/v1/proxy/namespaces/kube-system/services/kibana-logging
28KubeDNS is running at https://54.194.131.40/api/v1/proxy/namespaces/kube-system/services/kube-dns
29KubeUI is running at https://54.194.131.40/api/v1/proxy/namespaces/kube-system/services/kube-ui
30Grafana is running at https://54.194.131.40/api/v1/proxy/namespaces/kube-system/services/monitoring-grafana
31InfluxDB is running at https://54.194.131.40/api/v1/proxy/namespaces/kube-system/services/monitoring-influxdb
32 
33Kubernetes binaries at /Users/berndzuther/development/kubernetes/cluster/
34You may want to add this directory to your PATH in $HOME/.profile
35Installation 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.

1bz@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.

1bz@cc $ git clone https://github.com/zutherb/AppStash.git appstash 
2Cloning into 'appstash'...
3remote: Counting objects: 16244, done.
4remote: Total 16244 (delta 0), reused 0 (delta 0), pack-reused 16244
5Receiving objects: 100% (16244/16244), 139.09 MiB | 540.00 KiB/s, done.
6Resolving deltas: 100% (6322/6322), done.
7Checking connectivity... done.
8bz@cc $ cd kubernetes/example/shop
9 
10bz@cc $ kubectl create -f redis.yml
11replicationcontroller "redis" created
12bz@cc $ kubectl create -f redis-service.yml
13service "redis" created
14bz@cc $ kubectl create -f cart.yml
15replicationcontroller "cart" created
16bz@cc $ kubectl create -f cart-service.yml
17service "cart" created
18bz@cc $ kubectl create -f mongodb.yml
19replicationcontroller "mongodb" created
20bz@cc $ kubectl create -f mongodb-service.yml
21service "mongodb" created
22bz@cc $ kubectl create -f product.yml
23replicationcontroller "product" created
24bz@cc $ kubectl create -f product-service.yml
25service "product" created
26bz@cc $ kubectl create -f navigation.yml
27replicationcontroller "navigation" created
28bz@cc $ kubectl create -f navigation-service.yml
29service "navigation" created
30bz@cc $ kubectl create -f shop.yml
31replicationcontroller "shop" created
32bz@cc $ kubectl create -f shop-service.yml
33service "shop" created
34bz@cc $ kubectl create -f catalog.yml
35replicationcontroller "catalog" created
36bz@cc $ kubectl create -f catalog-service.yml
37service "catalog" created
38 
39bz@cc $  kubectl get pods
40NAME               READY     STATUS       RESTARTS   AGE
41cart-5qy3o         1/1       Running            0              4m
42...
43catalog-m41a8      0/1       Pending            0              4m
44...‚
45mongodb-q2a04      1/1       Running            0              4m
46navigation-8c3d9   1/1       Running            1              4m
47...
48product-ozjig      1/1       Running            0              4m
49…
50redis-1n74h        1/1       Running            0              4m
51shop-5vrpi         0/1       Pending            0              4m
52...

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.

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.