ALLES, WAS DU ÜBER

DEN BETRIEB EINES

KUBERNETES-CLUSTERS
WISSEN MUSST
Managed Kubernetes 101 Guide

INHALT
Der Einstieg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Runtime. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Service Proxy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Service Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Message Streaming . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Continuous Integration & Delivery . . . . . . . . . . . . . 12
App Definition & Image Build. . . . . . . . . . . . . . . . . . 14

EINLEITUNG
Die Komplexität des Aufbaus eines eigenen Kubernetes ist so ziemlich jedem
bekannt. Eine Kubernetes-Installation allein reicht in der Regel nicht aus, denn
der Teufel steckt im Detail: die Verwaltung aller Bestandteile eines Clusters.
Unser Booklet soll insbesondere Software- und Systemarchitekten Schritt
für Schritt zeigen, welche Erweiterungen für Kubernetes existieren und einen
allgemeinen Einblick in die jeweiligen Themenbereiche geben.
 1
tainer Runtime. Als Beispiel ist Docker wohl der bekannteste Vertreter. Darüber hi-
naus verwaltet Kubernetes beliebige Anwendungen in einem separaten Netzwerk-
segment. Kubernetes liefert bereits CoreDNS mit etcd als Coordination and Service
Discovery und Flannel als Netzwerkdienst. Während CoreDNS und etcd die IP-Ver-
DER EINSTIEG waltung gut handhaben und die meisten Funktionen von Kubernetes beherrschen,
handelt es sich bei Flannel um ein einfaches Overlay-Netzwerk, sodass Plugins mit
weiteren, besonders sicherheitsspezifischen Funktionen empfohlen werden. Canal
bzw. Calico sind hier bekannte Vertreter.
Mit den drei Basis Tools, z. B. Canal, CoreDNS und Docker, ist Kubernetes vor-
erst lauffähig, aber für einen Anwendungsbetrieb in Kubernetes fehlt noch die eine
oder andere Schicht. Hier sind weitere Komponenten notwendig, die Schritt für
Schritt installiert, konfiguriert und in Ihr eigenes Service Lifecycle Management in-
Ein Kubernetes macht noch keinen Cluster – oder – Let’s start the Architecture tegriert werden können.
Mesh! Beginnen wir mit einem Zitat von [Link]: „Kubernetes ist eine por-
table, erweiterbare Open-Source-Plattform zur Verwaltung von containerisierten Welche Tools sind die praktikabelsten?
Arbeitslasten und Services, die sowohl die deklarative Konfiguration als auch die Mit jedem zusätzlichen Tool erhöht sich natürlich der Betriebsaufwand. Und da je-
Automatisierung erleichtert.“1 des einzelne ein größeres Themenspektrum abbildet, drängt sich die Frage auf, ab
wann sich Kubernetes im Eigenbetrieb nicht mehr lohnt. Darüber hinaus stellt sich
Ziel ist es also, eine Plattform für das Workload- und Service-Management zu auch vielen die spannende Frage, wie viel von der in der Software eingebauten Lo-
schaffen, die unabhängig vom Betriebssystem läuft und mit Tools von Drittanbie- gik auf einen individuellen Dienst übertragbar ist und damit das selbstgeschriebene
tern erweitert werden kann. Der Vorteil soll dabei sein, dass die Erstellung und Nut- Programm verschlankt werden kann.
zung von Konfigurationen und Automatisierungen erleichtert wird. Hier beginnt Die Cloud Native Computing Foundation, kurz CNCF, hat einen guten Überblick
also der Anspruch; die großen Vorteile und die kleinen Einschränkungen. Kuberne- darüber gegeben, welche Werkzeuge es in einer typischen Cloud-Umgebung gibt,
tes ist eine Plattform zur Verwaltung, nicht zur Ausführung von Anwendungen. Um und für jeden Anwendungsbereich die praktikabelsten Tools vorgestellt. Ähnlich
die betrieblichen Bedürfnisse abzudecken, wird zusätzliche Software für andere wie bei der CNCF werden wir uns die einzelnen Schichten genauer ansehen: Lauf-
Komponenten benötigt. zeit, Orchestration & Management, App-Definition & Entwicklung und schließlich
die Bereitstellung. Da die Landschaft trotz Portabilität je nach Betriebssystem sehr
Kubernetes – Die Plattform zur Verwaltung von Anwendungen unterschiedlich sein kann, werden die Themen auf Linux-Basis erklärt. Eine Win-
In seiner Grundstruktur braucht Kubernetes, abgesehen von den Abhängigkeiten dows-basierte Sicht ist nicht Bestandteil.
für die Installation von Kubelet, auf jedem Server im Cluster eine sogenannte Con-
1
Quelle: [Link]
2
 2
Die drei Komponenten sind stellvertretend mit containerd als Container Runtime,
Quobyte als Cloud Storage und Canal als Cloud Network präsentiert. Wie funk-
tioniert also die Verwaltung von Containern? Kubernetes hat sich für verschie-
dene Lösungen geöffnet, die eine standardisierte Schnittstelle namens Container
RUNTIME Runtime Interface (CRI) verwenden. Die Container Runtime läuft getrennt von der
eigentlichen Containerverwaltung und bietet über diese Schnittstelle eine externe
Steuerung. Da diese Schnittstelle auch gewartet werden muss, ist dies die erste
Komponente, die in das Kubernetes-Lifecycle-Management integriert ist. Der be-
kannteste Vertreter ist Containerd, das ursprünglich mit Docker verwoben war und
später eigenständig wurde.
Seit der Einführung von Kubernetes wurden jedoch auch andere Container-
Laufzeiten eingeführt. CoreOS versuchte sich mit rkt zu etablieren, RedHat über-
Dieses Kapitel erklärt Euch die Komponenten aus dem CNCF-Layer “Runtime”, die nahm CoreOS und nennt es jetzt podman und andere wiederum versuchen sich an
die Grundlage für das bekannte Container-Orchestrierungs-Tool bilden. Es existie- lxd. Damit die Runtime von Kubernetes genutzt werden kann, benötigt man ein CRI.
ren viele verschiedene Basiskomponenten auf der Ebene “Runtime”. Ein mögliches Das Zwischenspiel auf Interface-Ebene ermöglicht eine präzise Steuerung, kann
Zielbild könnte so aussehen: auf der anderen Seite aber zu einem großen Aufwand in der Einarbeitung und Aus-
wahl führen. Es ist aber nur eine von mehreren Kommunikationsschichten, die viel
Aufmerksamkeit erfordert. Es wird also schon sehr komplex bei der Wahl und dem
Betrieb einer geeigneten Container-Runtime für Kubernetes.

Containerd ist die am weitesten verbreitete Lösung. Sie ist Cloud-tauglich, be-
Iaas Components
(Storage, Network, Runtime) triebssicher und seit über drei Jahren mit einem offiziellen Release 1.0.0 auf dem
Markt.

Be persistent in an ephemeral world

Die größte Veränderung in einem containerisierten Umfeld ist die Volatilität der
Anwendungen. Um den zusätzlichen Aufwand von Datenpersistenz in diesem Um-
feld zu umgehen, ist meist der Ansatz von “Ephemeral Apps” der passendste. Dabei
werden Daten nicht zusammen mit den Applikationen gespeichert, sondern auf

3
zentrale Umgebungen ausgelagert. Die Liste an Entscheidungen wird also auch hier benötigt. Im VM-Kontext könntest Du mit solch einer Anzahl schnell auf verschie-
größer: Ein Load Balancer, der alle Verbindungen neu aufbaut? Alles klar. Ein Daten- dene Engpässe stoßen, von denen einer auch die Containerisierung betrifft: die
bank-Managementsystem, die eine existierende Datenbank jedes mal neu einliest? Allokation. Jedem Container wird eine IP zugewiesen, und es wäre für jedes Netz-
Moment Mal! Natürlich ist das eine grobe Verallgemeinerung, aber es ist norma- werk eine echte Herausforderung, die Flut von IPs und vor allem die regelmäßige
lerweise die erste Änderung in mancher Software-Logik, den man meist nicht er- Neuzuweisung zu bewältigen.
wartet. Um diesen Engpass zu vermeiden, wendet Kubernetes das Prinzip der internen
Kubernetes bietet auch die Möglichkeit, Deine Daten länger zu speichern, als ein IP-Zuweisung an und umgeht damit die Veröffentlichung einer jeden Komponente
Container lebt. Ähnlich wie bei der Container Runtime sprechen wir zunächst von im restlichen Netzwerk. Mit einem geeigneten Werkzeug wird ein dediziertes Sub-
CSI – einem Container Storage Interface. Diese Schnittstelle wird ebenfalls von ver- netz erzeugt. Dieses Netz wird durch ein geeignetes Netzwerkmanagement-Tool
schiedenen Anbietern bereitgestellt. Kubernetes wird mit einer Standard-CSI ge- erstellt und verwaltet. IPTables und IP-in-IP-Prinzipien werden verwendet, um das
liefert, für den Fall, dass Du die Möglichkeit haben möchtest, lokale Pfade an einen Routing zwischen den einzelnen Kubernetes-Knoten sicherzustellen. Für simples
Knoten anzubinden – in einer Welt des Wandels, in der jeder Knoten einen anderen Routing kann man die Komponente flannel verwenden. Für eine erweiterte Netz-
ersetzen kann, nicht die „Best Practice“-Lösung. Dennoch ist es durchaus machbar. werkeinstellung innerhalb des Kubernetes-Subnetzes ist Calico eine geeignete
Die Entscheidung nach einem guten CSI ist in der Fülle nicht leicht: rook-ceph Wahl.
als bereits etabliertes verteiltes Speicherwerkzeug, StorageOS für schnelle Read-
IOPS? Da die Speicherverwaltung eines der sensibelsten Themen in der IT ist, sind flannel + calico = Canal
auch die Softwarelösungen komplex aufgebaut und bieten verschiedene Features, Der Hauptunterschied zwischen flannel und Calico ergibt sich dabei im benutzten
die jedoch in der Standardinstallation womöglich deaktiviert sind, um die Sensibili- Netzwerk-Layer, im Prinzip der Data Encapsulation und des damit einhergehenden
tät deutlich zu machen. Dies wiederum bedeutet, dass viel Zeit für die Einarbeitung Routings. Besonders im Hinblick auf Performance wird für eine bessere Trennung
und Konfiguration aufgewendet werden muss und einige Mitarbeiter bestenfalls zwischen Netzwerk und Policies das Kollaborationsprojekt Canal (Calico + Flannel
bereits Erfahrung im Storage-Management haben müssen. = Canal) empfohlen, bei dem das Netzwerk Overlay flannel und die Policy-Kompo-
nenten von Calico genutzt werden.
Social Networking – the technical way Allein die Planung des passenden Netzwerksegments für das Subnetz kann
Nun könntest Du mit wenigen Befehlen bereits mit Hilfe eines Installationspro- schnell zu Fehlern führen. Manchmal können sogar das Cloud-Betriebssystem und
gramms, wie kubeadm oder kubespray, Kubernetes installieren. Aber schauen wir die integrierte Überwachung der erzeugten VMs Probleme verursachen. Der größ-
uns erst einmal an, welche Drittsoftware nach der Installation gestartet wird. Da te Aufwand ist jedoch in den Netzwerkrichtlinien zu sehen. Wie bei jeder guten
eines der Grundprinzipien der Containerisierung darin besteht, einen Prozess pro Konfiguration ist auch hier ein sehr großer Aufwand zu leisten. Dabei helfen nur
Container zu starten, werden zwangsläufig mehr als nur einige wenige Container viele Best Practices und Netzwerkadministratoren mit Erfahrung.

4
 3
schränkt, anstatt auf die gesamte Applikation in einer einzelnen Laufzeitumge-
bung. Sie wird auf der anderen Seite aber auch in der Menge größer und damit
unübersichtlich. Änderungen müssen mit mehr Bedacht eingepflegt werden, um
sicherzustellen, dass bei einer Änderung – technisch wie menschlich – alle Nutzer
SERVICE PROXY und Abhängigkeiten bedacht werden.

Call all the things – die verschiedenen Service-Typen

Kommen wir zum ersten Thema mit Außenwirkung: Der Service Proxy. Endlich ein-
mal eine Anwendung installieren. Die ganze Vorarbeit mit Lorbeeren schmücken.
Doch wie erreichen wir das? Wie im Kapitel Runtime bereits angesprochen, erzeugt
Kubernetes ein Subnetz, in dem die interne Erreichbarkeit der Services gewähr-

Das Layer “Orchestration & Management” ist der Einstiegspunkt für die meis-
ten Anwender. Während die Runtime für den Betrieb von container-basierten
Umgebungen wichtig ist, bildet dieses Layer die Grundlage für den Betrieb von
Applikationen.
Die Erklärungen zu den einzelnen Komponenten des Layers “Orchestration &
Management” sind sehr komplex, weswegen wir die einzelnen Komponenten er-
klären werden. In diesem Kapitel schauen wir uns, neben der generellen Idee hinter
zentralen Microservices, den Service Proxy einmal genauer an.

Zentrale Komponenten im dezentralen Umfeld

In Kubernetes können zentrale Komponenten für standardisierte Aufgaben in der
Software-Architektur eingesetzt werden. So kann z. B. mit einem Service Proxy
oder einem Service Mesh eine Software eingesetzt werden, welche globale Funk-
tionsanforderungen erfüllt.
Die Verteilung von zentralen Aufgaben auf einzelne Komponenten ist dann er-
strebenswert, wenn man dem Prinzip des “Separation of Concerns” fokussieren
möchte. Es führt zu dedizierten Laufzeiten für Funktionen, welches den Micro-
service-Gedanken aufgreift und die Ausfallzeiten auf einzelne Komponenten be-

5
 leistet wird. Eine externe Erreichbarkeit ist aber, abgesehen vom Kubernetes API Der Service vom Typ External Name dient dazu, Kubernetes-interne Aufrufe auf ex-
Server, noch nicht vorhanden. Kubernetes klassifiziert die Erreichbarkeit von Pods terne Services weiterzuleiten. Das ist z. B. für Authentifizierungssysteme, die nicht
über den Typ eines Services: auf Kubernetes gehostet werden sollen, sinnvoll. Ein Service vom Typ ClusterIP ist
der Standardeintrag für die Erreichbarkeit von Diensten innerhalb von Kubernetes.
ExternalName, Sie besitzen einen Cluster-internen DNS-Eintrag der durch die Komponente “Co-
NodePort, ordination & Service Discovery” gemanagt wird.
LoadBalancer und
ClusterIP. Interessanter für Dich sind aber die Typen NodePort und Load Balancer. Beide bie-
ten die Möglichkeit, einen direkten Aufruf von außen auf die Anwendung möglich
Eine Übersicht könnte so aussehen: zu machen. Der Unterschied ist tatsächlich in der Vererbung zu finden: Ein Load Ba-
lancer-Service, ist ein erweiterter Service vom Type NodePort, und ein NodePort-
Service ein erweiterter Service vom Typ ClusterIP. Während aber der NodePort sich
Worker Node IP: 3xxxxx Cloud Provider ELB
weiterhin den Grundressourcen des Kubernetes Clusters bedient (die IP ist in dem
NodePort LoadBalancer Fall eine beliebige VM-IP einer Node von Kubernetes), kann ein Load Balancer-Ser-
vice durch eine FloatingIP selbstständiger agieren. Dafür wird meist ein tatsäch-
Local Kubernetes Kube-DNS DNS CNAME Record licher Load Balancer eingesetzt.

ClusterIP ExternalName Making the LoadBalancer an Ingress

Service Damit nicht zu viele LoadBalancer erzeugt werden müssen (wer will schon für jede
Applikation ein dedizierte IP?) kannst Du bereits hier eine zentrale Komponente
wählen. Hier kommen die sogenannten Ingress-Controller ins Spiel. Ein Ingress
kann als ein Konfigurationseintrag in einem Reverse Proxy für Services gesehen
[Link] [Link] [Link] NodeIP werden. Auch hierfür gibt es Kubernetes-spezifische Ressourcen, die konfiguriert
Worker 1 30000 Worker 2 30000 Worker 3 30000 TargetPort werden können. Der Ingress ermöglicht es, als zentrale Instanz mit dezentralen
[Link] [Link] [Link] Pod IP Konfigurationselementen die Anfragen an Applikationen zu verteilen und benötigt
8080 8080 8080 Port nur eine Cluster-externe Ressource.
Nginx Nginx Nginx
80 80 80 Container
(C1) (C1) (C1) NGINX ist bereits als Webserver und Reverse Proxy bekannt und stellt bei Ku-
Port
Pod 1 Pod 1 Pod 1 bernetes ebenfalls eine Version names nginx-ingress-controller zur Verfügung. Der
Aufwand hier zeigt sich in der Bereitstellung von Floating IPs, am besten automati-
siert, und ist damit ebenfalls ein Thema aus dem Netzwerkbereich, der für einigen
Aufwand sorgen kann.

6
 4
kann, wenn es einmal umgesetzt wird. Wenn Du das als Grundlage ansiehst, ist die
Frage, ob ein Service Mesh sinnvoll wäre, dadurch bereits beantwortet.
Anders sieht es mit dem „Wann“ aus. Die Umstellung auf eine zentrale Kompo-
nente im Routing-Bereich kann jederzeit erfolgen. Effizient wird sie aber erst dann,
SERVICE MESH sobald die eigene Firmenkultur die Mitarbeitenden befähigt, diese Komponente
auch wirklich zu nutzen und selbst zu betreiben. Nicht zuletzt wird dabei auch die
vorangegangene Planung im Netzwerk und damit in der Entwicklung einmal in Fra-
ge gestellt: Benötige ich dann noch ein Service Proxy oder soll das applikationssei-
tig abgesichert sein? Welche Application Tasks werden zusätzlich ausgelagert und
wie kann ich in der komplexen Verteilung weiterhin einen Vorteil gegenüber dem
klassischen Betrieb beibehalten? Ein guter Ansatzpunkt ist die Prüfung der eigenen
Anforderungen nach dem Wechsel zu Kubernetes.
Ein Service Mesh ist eines der größeren Themen, die die Softwareentwicklung auf Wenn die eigenen erstellten Microservices immer weiter unterteilt werden, sta-
Kubernetes erwarten darf. Hierbei wird die Möglichkeit integriert, das „Netz“ von teless Services ihre „eigenen Container“ bekommen – dann kannst Du in einer Ana-
Microservices bzw. Pods in ihrer Kommunikation zu verwalten. Das Management lyse sehr schnell feststellen, dass ein Service-Mesh-Plugin viel Entwicklungsarbeit
von Netzrouten, dedizierte Zugriffskontrollen und Ausfall- bzw. Auslastungsme- abnimmt. Der Time-to-Market kann dann weiter reduziert werden und Fokus auf
chanismen sind hier einige Beispiele. die eigentliche Mehrwertgenerierung im eigenen Code erhöht werden. Außerdem
kann auch während des Debuggings die Fehlerquelle zielgerichteter ausgewiesen
Das Problem hierbei ist aber der Mehraufwand der entsteht. Um ein Service Mesh werden.
zu nutzen, ist es notwendig, selbsterstellte Software so aufzubauen, dass sich die
Aufgaben hierbei nicht überlappen. Sei es im Bereich des Routings, der Validierung
oder der Limitierung des Traffics: all diese Aufgaben kann ein Service Mesh über-
nehmen und sollten nicht mehr in den eigenen Applikationen vorkommen.
Auf der anderen Seite kannst Du dabei aber die Entwicklungsarbeiten somit
ausserhalb der Anwendung erbringen und damit gänzlich aus einem Team heraus-
nehmen oder sogar ein komplett eigenes Team damit beschäftigen.

Welche Frage der Service Mesh beantwortet

Der Ansatz des Service Mesh zeigt auf, wie kleinteilig Microservices werden kön-
nen. Es zeigt auch gleichzeitig, wie gut ein “Separation of Concern” funktionieren

7
 5
Service Mesh Traffic overview

Ingress
Gateway
MESSAGE
Frontend Backend Database
STREAMING
Proxy Proxy Proxy
Sidecar Sidecar Sidecar

Neben dem Service Mesh und dem Service Proxy ist Message Streaming die
dritte Komponente, die die Systemarchitektur Eures Application Stacks stark be-
Control Egress
Plane Gateway einflussen kann.

Was ist eine Message Queue?

Eine Message Queue dient zur asynchronen Verarbeitung von Nachrichten zwi-
schen einzelnen Diensten. Das unterstützt den generellen Ansatz von Microservice-
Welches Tool nehme ich denn nun? Architekturen und damit auch containerisierte Applikationen. Sie trennt Systeme,
die den Arbeitsablauf durch das Warten auf eine Antwort oder Verarbeiten von
Die bekanntesten Anbieter von Service Meshes sind im Vergleich zu manch an- Daten. So können viele Anfragen nacheinander abgearbeitet oder lange Verarbei-
derem Layer der CNCF überschaubar. Ob es am Ende Istio, Linkerd oder Consul tungsschritte separiert werden.
sein soll, entscheidet Deine Präferenz. Während Istio viele Features beherbergt, Besonders zu Beginn der Entwicklung weg von monolithischen Anwendungen,
ist Linkerd in der Performance besser und Consul als guter Allrounder empfeh- kann sie als erster Anlaufpunkt dienen, um neue Features kleinteiliger aufzusetzen
lenswert. In der Wartung ist besonders Istio durch seine Komplexität durch einen und dennoch mit bestehenden Systemen kommunizieren zu lassen.
größeren Aufwand nicht zu unterschätzen. Alle drei Komponenten arbeiten mit der
SideCar-Technologie. Consul hat darüber hinaus zusätzliche Agents auf jeder Node Wann ein Message Stream Sinn ergibt
vorgesehen. Während Message Queues also zwei Komponenten voneinander trennen und
Nachrichten annehmen und aktiv weiterleiten, wird bei einem Message Stream das

8
Ereignis der Datenbereitstellung in den Vordergrund gestellt. Eine direkte Kom- voneinander getrennt werden. Hierbei sollten mehrere, voneinander unabhängige
munikationsbeziehung zwischen den zwei Komponenten ist dabei nicht mehr aus- Instanzen eingeplant werden.
geschlossen. Die meisten Tools kombinieren dabei aber das Speichern von Daten Ist Message Streaming im Fokus, was besonders bei redundanten Setups eine
und die Verarbeitung der Ereignisse, um den Vorteil der Trennung beizubehalten. wichtige Rolle spielt, bieten sich Applikationen wie Kafka an. Diese sind auf eine
Das bedeutet, wenn eine Komponente ihre Daten an den Message Stream über- hohe Menge an Nachrichten und Ereignisse ausgelegt. Nachrichten und Ereignisse
gibt, werden sie ebendort veröffentlicht und der initiale Prozess ist abgeschlossen. anzunehmen und vorzuhalten ist der Hauptfokus in diesem Umfeld. Dabei wird die
Andere Microservices können dann auf diesen Stream zugreifen und die Daten ab- Applikation als Plattform angenommen und funktioniert besonders gut in größe-
holen. Die Datenweiterleitung erfolgt also passiv aus Sicht des Message Streams. ren, kombinierten Instanzen.
Damit verringert sich logischerweise die Zeit, die eine einzelne Komponente be- Wenn man die Datenverarbeitung in den Vordergrund stellt, ergibt sich ein Son-
nötigt eine Aufgabe abzuschließen. Es existieren dann zwar zwei Aufgaben, anstatt derfall der übrigens auch abgedeckt wird. Flink bietet eine Laufzeit für Micro-Bat-
einer, können dadurch aber in den meisten Fällen mehr Anfragen verarbeiten. Zu- ches, die zur Verarbeitung genutzt werden kann, bevor sie Nachrichten zur Ver-
sätzlich ist es möglich, jede einzelne Komponente individuell zu skalieren, anstatt fügung stellt. Streng genommen vereint das zwar zwei Aufgaben – das Annehmen
des kompletten Setups. Man spart also mit der erhöhten Komplexität Ressourcen. bzw. Weiterleiten von Nachrichten und beispielsweise deren Analyse – kann so
Die Tool-Vielfalt ermöglicht dabei verschiedene Herangehensweisen. In der Pra- aber zusätzliche Aufgaben übernehmen, ohne das Layer Streaming & Messaging
xis sind Message Queues und Message Streams nicht so hart getrennt wie in ihren gänzlich zu verlassen.
Definitionen. Die Ansätze gehen Hand in Hand und werden auch in der Umsetzung
zusammengefasst. Aber ist das schon alles?
Das interessante an Message Streams ist nicht nur die Trennung von Arbeitsschrit-
Erst die Queue, dann der Stream ten. Mithilfe des ereignisorientierten Ansatzes lassen sich nun einige andere As-
Entscheidend für die Toolwahl ist schlussendlich die Aufgabe. Wenn man das Prin- pekte leichter realisieren. Dabei sind Serverless Tasks besonders spannend. Durch
zip der Message Queue in den Fokus stellen möchte, bieten sich Tools wie RabbitMQ die Umwandlung von Nachrichten in Ereignisse wird es möglich, selbst das Starten
an. Diese sind als Allzweckwerkzeug am besten bei übersichtlichen Mengen an von Servern davon abhängig zu machen, ob und wieviele Ereignisse vorliegen.
Nachrichten gut geeignet. Dadurch können besonders langwierige Arbeitsschritte

9
 6
banken. Obwohl Redis auch Daten persistieren kann, liegt der Hauptvorteil der bei-
den darin, die Daten im RAM vorzuhalten, sogenanntes Caching. Es bietet damit
eine deutlich höhere Geschwindigkeit bei Abfragen. Das bedeutet am Ende aber
auch, dass sie bei einem Neustart keine Daten mehr enthalten und neu geladen
DATENBANKEN werden müssen.
In-Memory-Datenbanken lösen damit die erste Problematik der Abfrageoptimie-
rung. Die Verteilung der Daten auf mehrere In-Memory-Datenbanken fördert au-
ßerdem die Skalierbarkeit. Speziell bei Kubernetes-Clustern wird meist sogenann-
ter Distributed Storage genutzt. Dieser bietet eine hohe Bandbreite und ist für
parallele Zugriffe gedacht. Persistente Datenbanken, also MySQL oder PostgreSQL
benötigen für eine intensive Nutzung jedoch eher geringe Latenzen mit sequen-
tiellen Zugriffen. Dafür sind wiederum andere Storage-Typen geeignet.
Management-Systeme für Datenbanken erfreuen sich einer großen Beliebtheit. Wenn man In-Memory-Datenbanken in einer Systemarchitektur als Microser-
Durch die hohe Effizienz in der Speicherung, der Zugriffssteuerung als auch in der vice wahrnimmt, fehlen damit einige Features wie die persistente Speicherung, die
logischen Sortierung bilden sie den Status Quo im Bereich der Datenspeicherung. man sonst bei klassischen Datenbanksystemen ganz natürlich so vorfinden möch-
Dabei ist es irrelevant, ob es sich um relationale oder nicht-relationale Datenban- te. Wir haben also immer noch die Herausforderung der Datenspeicherung im per-
ken handelt. sistenten Umfeld.

Das Hauptziel ist die Sicherung der Daten für einen längeren Zeitraum. Ein Verlust Alles ist ein Cluster
der Daten wäre eine finanzielle Einbuße für Unternehmen. Aber auch der zeitlich Wenn nun der Neustart von Containern auf der Tagesordnung steht, benötigst Du
befristete Ausfall von Datenbanken ist bereits ein Szenario, was zu vermeiden ist. Anwendungen, die ebenjenes unterstützen. Dabei hilft generell ein Cluster-Setup,
Für ein Kubernetes-Setup, das mit flüchtigen Zuständen arbeitet, eine eher schlech- also ein redundantes Setup mit mehreren unabhängigen Instanzen. Die meisten
te Ausgangsposition. Durch die Nutzung wächst auch die Datenmenge. Daher sind Datenbanksysteme unterstützen diesen Ansatz bereits in einem Primary-Secon-
Optimierungen im Bereich der Abfragezeiten und -menge wichtig. Nähern wir uns dary-Prinzip, wo lediglich die Primary-Instanz Schreibrechte erhält. Bei einem Aus-
der Lösung einmal vom letzten Punkt aus. fall der Primary-Instanz wird automatisch eine Secondary-Instanz befördert und
übernimmt die Schreibrechte. So wird sichergestellt, dass die Applikation trotz des
Datenbanken und Microservices Ausfalls einzelner Instanzen innerhalb kürzester Zeit wieder zur Verfügung steht.
Neben den typischen Vertretern wie MySQL, PostgreSQL oder MongoDB sind auch Ein Ansatz mit mehreren Primary-Instanzen ist ebenfalls möglich. Dabei ist zu
Datenbanken wie Redis oder Memcached interessant. Der Hintergrund ist denkbar beachten, dass das ACID-Prinzip (Atomicity, Consistency, Isolation, Durability) mög-
einfach: Redis und Memcached gehören zu den sogenannten In-Memory-Daten- licherweise verletzt wird und ganz explizit beachtet werden muss.

10
Der Clusterbetrieb wird übrigens auf Kubernetes von einigen Herstellern Kubernetes-Job zur Erzeugung eines Datenbank-Dumps – auch für diesen Bereich
bereits mit sogenannten Operators unterstützt. Diese managen anhand der gibt es Methoden, die abseits des restlichen Systems die Arbeit vereinfachen.
Konfigurationseinstellungen den Datenbank-Cluster und erleichtern den Be- Damit werden die Daten auch außerhalb Deines Kubernetes-Clusters gesichert.
trieb mit Dingen wie Leader-Election, Lifecycle Management oder Skalierung. Diese Automatisierungen ermöglichen es dir, die Langzeitspeicherung da zu be-
treiben, wo es für Dich am günstigsten ist. Ein Datenbank-Dump kann verschlüsselt
Das Ops in DevOps auch gut in einem S3-kompatiblen Speicher abgelegt werden. Mit der verteilten He-
Der letzte und wichtigste Punkt ist die Aufgabe der Langzeitspeicherung und rangehensweise – In-Memory-Datenbanken, persistente Datenbanken als Cluster
des damit einhergehenden Betriebs. Darunter fallen auch Backup-Mechanis- und zusätzliche Tools für Langzeitspeicherung – kreieren wir aus einem Datenbank-
men. Das sind Tätigkeiten, die regelmäßig geprüft und nicht vernachlässigt wer- Layer drei neue. Ausfallzeiten werden dadurch weiter reduziert. Die Komplexität
den dürfen. Sei es nun Velero als eigenständige Backup-Komponente oder ein im Umfeld der Containerisierung steigt aber weiterhin. Die Entscheidung für eine
Datenbank auf Kubernetes liegt vor allem in der eigenen Betriebsfähigkeit.

Die Entscheidung für eine Datenbank auf Kubernetes

METAKUBE
Ist die Workload Kannst du den
für Kubernetes Ja Betrieb selbst Ja
geeignet? leisten?
Unterstützt Ja
der Hersteller Nein Nein
Kubernetes?
Nein
Gibt es Kannst du den
Operators für die Ja Betrieb selbst Ja
Datenbank? leisten? STACK

11
 7
Dies kann je nach Reifegrad die Entwicklungs- oder auch Produktivumgebung be-

CONTINUOUS
inhalten. Continuous Delivery und Continuous Deployment sind verschiedene Me-
thoden mit unterschiedlichen Zielstellungen. Sie können aber aufgrund ihrer Ähn-
lichkeit auch synonym verwendet werden, wie auch in diesem Kapitel.
INTEGRATION Dependency Change – und alles ändert sich

& DELIVERY Das interessanteste an CI/CD auf Kubernetes ist der Paradigmenwechsel. Die meis-
ten Applikationen für eine CI/CD-Pipeline unterstützen den deklarativen Ansatz.
Das bedeutet, dass die gängige imperative Praxis, eine Liste an Aufgaben abzuar-
beiten, weniger Bedeutung erhält. Deklaratives Arbeiten vergleicht zwei Zustände
miteinander: Den Ist- und den Soll-Zustand. Unterscheiden sich diese voneinander,
wird der Soll-Zustand hergestellt. Dadurch wird die Anpassung oder Installation
In diesem Kapitel steht das wohl größte Thema im Bereich Kubernetes an: von Komponenten nachvollziehbarer und berechenbar. Wenn beispielsweise eine
Continuous Integration & Delivery (CI/CD). Während die Toolwahl bei der CNCF Applikation skaliert werden muss, kann man das explizit durch die Angabe einer
Landscape dafür ähnlich groß ist, ist der dahinterliegende Workflow einer der Mindestanzahl von Pods erreichen. Dabei wird die vollständige Konfiguration vom
umfangreichsten. CI/CD führt alle Bausteine der CNCF Landscape zusammen. Repository mit der laufenden Konfiguration verglichen und entsprechend ange-
Die Zusammenführung aller Komponenten für das Gesamtsystem steht dabei im passt.
Fokus. Das betrifft dabei alle möglichen Elemente, zum Beispiel Konfigurationen im Be-
reich Netzwerk, Backup oder auch der Runtime. Das setzt voraus, dass alle zu ver-
Was bedeutet CI/CD? waltenden Abhängigkeiten bzw. Komponenten bekannt und prüfbar sind. Mit Hilfe
Continuous Integration (CI) behandelt die automatisierte Zusammenführung ver- dieser Vorgehensweise lassen sich verschiedene Methoden anwenden, um vor al-
schiedener Komponenten während der Softwareentwicklung. Dadurch wird sicher- lem die teamübergreifende Arbeit zu verbessern. Die Verknüpfung der Aufgaben
gestellt, dass auch bei mehreren Entwicklungen an der gleichen Applikation keine und der Teams steht dabei im Fokus.
Fehler entstehen. Aufwändige Pull oder Merge Requests können so vermieden
werden. Continuous Delivery (CD) kümmert sich im Anschluss um die automatische GitOps und die deklarative Programmierung
Bereitstellung einer neuen Version. Die Voraussetzung ist dabei, dass die Applika- Wie sieht nun die Umsetzung aus? Um die Zustände transparent zu vergleichen,
tion ohne weitere Änderung produktiv einsetzbar ist. benötigt man idealerweise eine “Single Source of Truth”. So kann man sicherstel-
Continuous Deployment ist der letzte Schritt zur Zusammenführung aller Kompo- len, dass jeder in der Lage ist, Unstimmigkeiten zu entdecken und nachzuvollzie-
nenten bzw. der Konfigurationen und derer Installation auf der Laufzeitumgebung. hen.

12
Was bietet sich besser dafür an, als ein Git-Repository? Als Applikation für ver- Wie am Ende all das zusammengeführt wird, entscheidet jedes Team für sich. Denn
teilte Softwareverwaltung bietet es die perfekte Grundvoraussetzung. Es bekam durch die einheitliche Nutzung von Git-Repositories, YAML-Configs und Kubernetes
sogar seinen eigenen Namen: GitOps. Der Vergleich mit der laufenden Instanz auf sind drei wichtige Pfeiler gesetzt, um einen transparenten und nachvollziehbaren
Kubernetes anhand der Konfigurationselemente – den Kubernetes-Objekten – ist Workflow für alle Nutzenden zu erstellen.
dadurch möglich. Das ermöglicht außerdem vollständige Umgebungen darüber zu
verwalten. Die typische Toolchain kann dann über ein oder mehrere Repositories
integriert werden. Die einzige Voraussetzung ist eine vollumfängliche API für jeden
Client der Toolchain.
Um nun die Aufgaben der Integration und der Delivery zu übernehmen, bieten 1/Code Build Config
change Git Container (CI) Container Updater
sich verschiedene Möglichkeiten. Sei es mit einer voll definierten Pipeline auf Git- Code Registry
lab, einer Workflow-Definition über ArgoCD oder der klassischen Abarbeitung im
Jenkins-Cluster: jede Software bietet verschiedene Vorteile für Dich als Anwender. Update image in staging config

Eine Frage des Prozesses, nicht der Software

Wie eingangs erwähnt, stellt sich aber nicht die Herausforderung in der Wahl einer 2/Merge Service
geeigneten Software. In der CI/CD zeigt sich, wie gut im Vorfeld alle Anforderungen Staging
to Prod Git
bedacht wurden. Hier spiegelt sich als weitere Methode die Adaption des “Shift- Config Deploy
Operator Deployment
Left-Testings” wider. In dieser Methode werden Erkenntnisse aus dem Betrieb
eines Systems bereits vor dem Deployment erfasst und analysiert. Dies bedeutet
Kubernetes Cluster
zwar mehr Arbeit während der Entwicklung, aber weniger Nacharbeiten im Regel-
betrieb. Und das wiederum weniger Aufwand bei Neuentwicklungen, Migrationen
oder anderen Arten der Anpassung.
Das ist schlussendlich auch das Ziel von CI/CD. Die vielen verschiedenen Me-
thoden und Erfahrungen sollen zusammengeführt werden und einfach anwendbar Ob ein Git Repository oder mehrere Git Repositories: Die gleichartige Vorgehens-
sein. Dabei sollte jede Tätigkeit automatisiert sein, um einen steten Fluss zwischen weise vereinfacht die Zusammenarbeit – und automatisiert sie sogar. Um das
Code-Entwicklung und Betrieb zu gewährleisten. Fehler sollen vor der Installation meiste aus einer CI/CD herauszuholen, sind wiederum vorhergehende Standards
auf produktiven Systemen erkannt und behoben werden. Jedes Element ist trans- zu etablieren. Da hilft der Themenbereich “App Definition & Image Build”, dem wir
parent und dokumentiert. uns im nächsten Kapitel widmen werden.

13
 8
chen Mehrwert zu liefern. In unseren Beispiel ist der Mehrwert durch eine Website
gegeben, die Dich alle geplanten Funktionen ausführen und speichern lassen.

APP DEFINITION Microservices können dann auch Applikationen sein, welche eigenständig lauffä-
hig sind. Der Unterschied zu den vorherigen Services liegt dabei in der Aufgabentei-
& IMAGE lung. Ein Backend-Service, welcher mit Hilfe eines Cache die Datenabfrage beschleu-
nigt, kann sich eines Microservice bedienen, welches diese Aufgabe übernimmt.
BUILDING Memcached und RabbitMQ wären je nach Anwendung also innerhalb einer Appli-
kation als eigenständige Applikation definierbar, obwohl sie Teil des Backend sind.

API
REST Gateway REST Account Account DB
API API Service
Im letzten Kapitel haben wir die Prinzipien der “Continuous Integration &
Delivery” vorgestellt. Heute runden wir den Layer mit dem Thema “App Defi-
nition and Development” aus der CNCF-Landscape ab.“App Definition & Image
Build” gehört größtenteils zu einer CI/CD Pipeline, konzentriert sich aber ins- REST Inventory
Inventory DB
besondere auf die Application Delivery. API Service

Applikation definieren Shopfront

WEB
Damit eine Applikation geliefert werden kann, muss zunächst einmal festgelegt WebApp

werden, was eine Applikation ist. Im Bereich der Containerisierung und der Auf- REST Account Shipping DB
teilung von Services in Microservices kann das schon einmal verwirrend werden. API Service

Zum Verständnis dieses Kapitels genügt, dass wir einen funktionsfähigen, allein-
stehenden Service mit einer konkreten Aufgabe als Applikation definieren. Eine
Darstellung der Inhalte einer Website wäre also eine einzelne Applikation. Dazu Warum das wichtig ist?
kommt eine Instanz zur Verarbeitung der Eingaben auf der Website, genau wie Die Definition einer Applikation verdeutlicht am Ende, wie die Application Delivery
eine Datenbank. Alle drei Instanzen – das Frontend, das Backend und die Daten- aussehen kann. Zeitgleich hebt es noch einmal die Bedeutung der Systemarchi-
bank – können unabhängig voneinander funktionieren und bilden zusammen tektur hervor. Denn ohne Architektur ist keine klare Tool-Wahl möglich. Mit der
einen Application Stack, um die Aufgaben zu verbinden und den schlussendli- Entscheidung die eben beschriebene Applikationen als verteiltes System mit Mic-

14
roservices auf Kubernetes zu betreiben, ist jetzt alles definiert was wir brauchen,
um die verschiedenen Tools einmal näher in Augenschein zu nehmen.
Anhand der Definition einer Applikation lässt sich übrigens auch die Aufgaben-   
teilung in der Softwareentwicklung gut beschreiben. Wenn man den Gedanken von Develop Your Define Your Containerize Deliver Your
Microservices verfolgt, können kleine Teams gezielter und umfangreicher jede be- Software Software Your Software Software
liebige Komponente entwickeln; abgesehen von gemeinsamen Schnittstellen auch
vollkommen unabhängig.

Die Toolchain beginnt jetzt

Sei es eine Schnittstellendefinition mit OpenAPI, die Erstellung von Containern mit
kaniko oder die Auflistung der Konfigurationsparameter von Applikationen mit Der Vorteil der hier dargestellten Toolchain ist insbesondere die Integration in
Helm – jedes Tool unterstützt Entwickler dabei, während der Code-Erstellung die andere Toolchains. So ist die Toolchain für die CI/CD-Pipeline mit ähnlichen Kom-
Applikation bereit für den Betrieb auf Kubernetes zu machen. Hier zeigt sich, wie ponenten möglich. Das erleichtert auch den Ansatz des Shift-Left-Testings. Damit
gut die vorgestellten Bestandteile der CNCF-Landscape ineinander greifen. Denn wird auch die Integration in die anderen Bereiche deutlich. Wenn man die Applica-
die Aufgaben aus der Entwicklung spiegeln den Bedarf der anderen Komponenten tion Delivery als Ausgangspunkt sieht, folgen daraus die anderen Themenbereiche.
wider. Es beginnt mit der Programmierung, geht über in die Testphase, behandelt
die Integration von bestehenden Tools und endet schlussendlich im Betrieb. Die Reihenfolge der Themen für Software-Entwickler sieht dann wie folgt aus:
1. Application Delivery & Image Build
Alles berücksichtigt? Los geht’s! 2. Continuous Integration & Delivery
Jedes Tool bringt seine eigenen Vorteile mit. Daher ist besonders in diesem Bereich 3. Database
die Nutzung mehrerer Tools für verschiedene Teilaufgaben zu empfehlen. Angefan- 4. Streaming & Messaging
gen mit der Cloud-Nativen-Entwicklungsumgebung Eclipse Che. Diese bietet die 5. Service Proxy oder Service Mesh
Möglichkeit, für jeden Entwickler bereits definierte Microservices in einem eigenen
Namespace auf Kubernetes zu starten und per Web-IDE Theia die Applikation zu Für Administratoren ist es umgekehrt:
entwickeln und zu deployen. Die Installation ist jedoch sehr umfangreich. Als lokale 1. Runtime
Umgebung kann Skaffold einen guten Ersatz darstellen. 2. Scheduling & Orchestration mit Kubernetes
Für die Definition von Deployment-Konfigurationen sind weiterhin Helm-Charts 3. Service Proxy oder Service Mesh
zu empfehlen. Für das Erstellen von Container-Images ist Kaniko zu empfehlen, 4. Database
welches auch ohne besondere Rechte in der Lage ist, Images zu erstellen. Die Ab- 5. Streaming & Messaging
lage aller Komponenten kann dann in einem git-Repository erfolgen. 6. Continuous Integration & Delivery

15
Der Einstieg in die Kubernetes-Welt Über den Autor
In diesem Booklet haben wir gezeigt, welche Herausforderungen im Umgang mit Sascha Siegl ist PreSales Consultant bei SysEleven und be-
Kubernetes warten und welche Tools beim Einstieg helfen. Zeitgleich sollte die schäftigt sich mit Anwendungsentwicklung und -manage-
Komplexität und die Vielfalt im Cloud-nativen Umfeld mit unseren Erfahrungen re- ment in containerisierten Umgebungen sowie der Planung
duziert werden. von Systemarchitekturen im Rahmen des Cloud-Native-
Umfelds. In den vergangenen Jahren hat er erfolgreich
Konzepte zur Einführung des Container-Orchestration-
Du startest gerade mit Kubernetes und hast Fragen oder benötigst Hilfe? Tools Kubernetes für Unternehmen erstellt. Als Befürworter
Melde Dich gern bei uns und wir erarbeiten zusammen eine Lösung. von Open-Source-Anwendungen hat er dabei sein Know-How über verschiedene
Tools und Ansätze mit in die individuelle Kundenlösung einfließen lassen.

Über SysEleven
SysEleven ist ein führender Cloud- und Kubernetes Service Provider, der sich auf
den Betrieb verteilter und geschäftskritischer Systeme sowie die schnelle Skalie-
rung von Workloads spezialisiert hat. Das Unternehmen unterstützt Organisatio-
nen, die ihre Transformation hin zu Cloud Native vollziehen wollen und Wert auf
Geschwindigkeit, Flexibilität und Autonomie legen.
Zum Leistungsportfolio besteht aus umfassenden Serviceleistungen – angefan-
gen von Konzeptberatung, den Aufbau von Test-Umgebungen über Trainings bis hin
zum Full-Managed-Betrieb. Herzstück des vertikalen Technologie-Stacks ist „Me-
taKube“, ein Managed-Kubernetes-Angebot, mit dem Organisationen webbasierte
Software-Produkte entwickeln und betreiben können.
SysEleven legt großen Wert auf Datenschutz und Digitale Souveränität. Alle
Lösungen werden deshalb ausschließlich in ISO27001-zertifizierten deutschen Re-
chenzentren gehostet und ermöglichen Kunden und Partnern die Einhaltung der
Datenschutzgrundverordnung (DSGVO).

16
SEEING IS BELIEVING
Lerne unsere Kubernetes-Lösung MetaKube kennen. Hier geht’s zum 30-tägigen Test:

[Link]/metakube-testen