Kubernetes - Brendan Burns - E-Book

Kubernetes E-Book

Brendan Burns

0,0

Beschreibung

Einfach und schnell erklärt von den Kubernetes-Mitbegründern persönlich

  • alles, was Sie über Kubernetes wissen müssen
  • für Einsteiger und Admins ohne Kubernetes-Vorkenntnisse
  • aktualisierte und erweiterte Auflage

Kubernetes vereinfacht das Bauen, Deployen und Warten skalierbarer, verteilter Systeme in der Cloud radikal. Dieser praktische Leitfaden zeigt Ihnen, wie Kubernetes und die Container-Technologie dabei helfen können, in Bezug auf Schnelligkeit, Agilität, Zuverlässigkeit und Effizienz in ganz neue Bereiche vorzudringen.
Die Autoren Brendan Burns, Joe Beda und Kelsey Hightower haben bei Google und in anderen Firmen mit Kubernetes gearbeitet und erklären Ihnen, wie sich dieses System in den Lebenszyklus einer verteilten Anwendung einfügt. Sie werden lernen, wie Sie Tools und APIs einsetzen, um skalierbare, verteilte Systeme zu automatisieren – egal ob es sich um Online-Services, Systeme zum maschinellen Lernen oder ein Cluster aus Raspberry Pis handelt.
- Lernen Sie die Herausforderungen verteilter Systeme kennen, die Sie mit Kubernetes angehen können.
- Tauchen Sie ein in die containerisierte Anwendungsentwicklung und nutzen Sie dabei zum Beispiel Docker-Container.
- Erstellen Sie Container im Docker-Image-Format mit Kubernetes und lassen Sie sie über die Docker-Runtime ausführen.
- Begutachten Sie die zentralen Konzepte und API-Objekte von Kubernetes, die notwendig sind, um Anwendungen produktiv laufen zu lassen.
- Rollen Sie neue Softwareversionen zuverlässig ohne Downtime oder Fehler aus.
- Lernen Sie aus Beispielen zum Entwickeln und Deployen realer Anwendungen in Kubernetes.

"In nur wenigen Jahren hat sich Kubernetes an die Spitze einer weitreichenden Revolution in der Anwendungsentwicklung gesetzt. Es löst seit langem bestehende Probleme in Anwendungsentwicklung und -management auf eine saubere und trotzdem sehr leistungsfähige Art und Weise. Brendan, Joe und Kelsey waren zentrale Mitspieler beim Auslösen und Vorantreiben dieser Revolution. Ihr Buch dient als Grundlage, um die Technologie Kubernetes, aber auch die dahinterstehenden Kräfte bei der Transformation zu verstehen."
Eric Brewer, Vice President, Google

Sie lesen das E-Book in den Legimi-Apps auf:

Android
iOS
von Legimi
zertifizierten E-Readern
Kindle™-E-Readern
(für ausgewählte Pakete)

Seitenzahl: 329

Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:

Android
iOS
Bewertungen
0,0
0
0
0
0
0



Brendan Burns begann seine Karriere mit einem kurzen Einsatz in der Software-Branche, bevor er sich mit einem PhD in Robotik auf die Bewegungsplanung für menschenähnliche Roboterarme konzentrierte. Darauf folgte eine kurze Zeit als Informatik-Professor. Schließlich kehrte er nach Seattle zurück und kam zu Google, wo er an der Web-Suchinfrastruktur mit einem Schwerpunkt auf Low-Latency Indexing arbeitete. Dort gründete er auch zusammen mit Joe Beda und Craig McLuckie das Kubernetes-Projekt. Brendan Burns ist aktuell Director of Engineering bei Microsoft Azure.

Joe Beda begann seine Karriere bei Microsoft am Internet Explorer (er war jung und naiv). Während der sieben Jahre bei Microsoft und der zehn Jahre bei Google hat Joe Beda an GUI-Frameworks, Echtzeit-Sprache und Chat, Telefonie, maschinellem Lernen für Anzeigen und Cloud Computing gearbeitet. Vor allem aber hat er bei Google die Google Compute Engine aus der Taufe gehoben und zusammen mit Brendan Burns und Craig McLuckie Kubernetes geschaffen. Zusammen mit McLuckie gründete Beda das Start-up Heptio, das sie an VMware verkauften und bei dem er nun Principal Engineer ist. Auf Seattle als seine Heimat ist er sehr stolz.

Kelsey Hightower ist Principal Developer Advocate bei Google, wo er an deren Cloud-Plattform arbeitet. Er half bei der Entwicklung und dem Verbessern vieler Google-Cloud-Produkte – unter anderem bei Googles Kubernetes Engine, Cloud Functions und dem API Gateway von Apigees. Hightower verbrachte einen Großteil seiner Zeit mit Executives und Entwicklern aus vielen Fortune-1000-Unternehmen und half ihnen dabei, mithilfe der Technologien und Plattformen von Google ihre eigenen Geschäfte voranzubringen. Er trägt viel zu Open-Source-Projekten bei und betreut Projekte, die Software-Entwickler und Operations-Professionals beim Aufbauen und Ausliefern von Cloud-Native-Anwendungen helfen. Hightower ist bekannter Autor und Keynote-Sprecher und war der erste Gewinner des CNCF Top Ambassador Awards aufgrund seiner Unterstützung beim Aufsetzen der Kubernetes-Community. Er ist Mentor und Technical Advisor und hilft Gründern dabei, ihre Visionen Realität werden zu lassen.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.plus

Brendan Burns · Joe Beda · Kelsey Hightower

Kubernetes

Eine kompakte Einführung

2., aktualisierte und erweiterte Auflage

Brendan Burns

Joe Beda

Kelsey Hightower

Übersetzung: Thomas Demmig

Lektorat: Sandra Bollenbacher

Copy-Editing: Petra Heubach-Erdmann, Düsseldorf

Satz: Birgit Bäuerlein

Herstellung: Stefanie Weidner

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print    978-3-86490-803-3

PDF     978-3-96910-048-6

ePub   978-3-96910-049-3

mobi   978-3-96910-050-9

2., aktualisierte und erweiterte Auflage 2021

Translation Copyright für die deutschsprachige Ausgabe © 2021

dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Authorized German translation of the English edition of Kubernetes: Up and Running, 2nd Edition ISBN 9781492046530 © 2019 Brendan Burns, Joe Beda, and Kelsey Hightower

This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected]

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag noch Übersetzer können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Für Robin, Julia, Ethan und alle, die Cookies gekauft hatten, damit ich mir in der dritten Klasse einen Commodore 64 leisten konnte.

– Brendan Burns

Für meinen Vater, durch den ich Computer lieben lernte, indem er Lochkarten und Punktmatrix-Banner mit nach Hause brachte.

– Joe Beda

Für Klarissa und Kelis, durch die ich auf dem Teppich bleibe. Und für meine Mutter, die mich ein strenges Arbeitsethos gelehrt hat und mir zeigte, wie ich Widerstände überwinden kann.

– Kelsey Hightower

Inhaltsverzeichnis

Vorwort

1Einführung

1.1Schnelligkeit

1.1.1Der Wert der Immutabilität

1.1.2Deklarative Konfiguration

1.1.3Selbstheilende Systeme

1.2Ihren Service und Ihre Teams skalieren

1.2.1Entkoppeln

1.2.2Einfaches Skalieren für Anwendungen und Cluster

1.2.3Entwicklungs-Teams mit Microservices skalieren

1.2.4Konsistenz und Skalierung durch Separation of Concerns

1.3Abstrahieren Sie Ihre Infrastruktur

1.4Effizienz

1.5Zusammenfassung

2Container erstellen und ausführen

2.1Container-Images

2.1.1Das Docker-Image-Format

2.2Anwendungs-Images mit Docker bauen

2.2.1Dockerfiles

2.2.2Die Image-Größe optimieren

2.2.3Sicherheit von Images

2.3Multistage Image Build

2.4Images in einer Remote-Registry ablegen

2.5Die Docker Container Runtime

2.5.1Container mit Docker ausführen

2.5.2Die kuard-Anwendung erforschen

2.5.3Den Ressourcen-Einsatz begrenzen

2.6Aufräumen

2.7Zusammenfassung

3Ein Kubernetes-Cluster deployen

3.1Kubernetes auf einem öffentlichen Cloud-Provider installieren

3.1.1Google Kubernetes Engine

3.1.2Kubernetes mit dem Azure Kubernetes Service installieren

3.1.3Kubernetes auf den Amazon Web Services installieren

3.1.4Kubernetes mit minikube lokal installieren

3.2Kubernetes in Docker ausführen

3.3Kubernetes auf dem Raspberry Pi ausführen

3.4Der Kubernetes-Client

3.4.1Den Cluster-Status prüfen

3.4.2Worker-Knoten in Kubernetes auflisten

3.5Cluster-Komponenten

3.5.1Kubernetes-Proxy

3.5.2Kubernetes-DNS

3.5.3Kubernetes-UI

3.6Zusammenfassung

4Häufige kubectl-Befehle

4.1Namensräume

4.2Kontexte

4.3Objekte der Kubernetes-API anzeigen

4.4Kubernetes-Objekte erstellen, aktualisieren und löschen

4.5Objekte mit einem Label und Anmerkungen versehen

4.6Debugging-Befehle

4.7Autovervollständigen von Befehlen

4.8Alternative Möglichkeiten zur Kommunikation mit Ihrem Cluster

4.9Zusammenfassung

5Pods

5.1Pods in Kubernetes

5.2In Pods denken

5.3Das Pod-Manifest

5.3.1Einen Pod erstellen

5.3.2Ein Pod-Manifest schreiben

5.4Pods starten

5.4.1Pods auflisten

5.4.2Pod-Details

5.4.3Einen Pod löschen

5.5Auf Ihren Pod zugreifen

5.5.1Port-Forwarding einsetzen

5.5.2Mehr Informationen aus Logs erhalten

5.5.3Befehle in Ihrem Container mit exec ausführen

5.5.4Dateien von und auf Container kopieren

5.6Health-Checks

5.6.1Liveness-Probe

5.6.2Readiness-Probe

5.6.3Arten von Health-Checks

5.7Ressourcen-Management

5.7.1Ressourcen-Anforderungen: Minimal notwendige Ressourcen

5.7.2Den Ressourcen-Einsatz durch Grenzen beschränken

5.8Daten mit Volumes persistieren

5.8.1Volumes in Pods definieren

5.8.2Volumes in Pods nutzen

5.8.3Daten auf Remote-Speicher persistieren

5.9Fügen Sie alles zusammen

5.10Zusammenfassung

6Labels und Anmerkungen

6.1Labels

6.1.1Labels anwenden

6.1.2Labels anpassen

6.1.3Label-Selektoren

6.1.4Label-Selektoren in API-Objekten

6.1.5Labels in der Architektur von Kubernetes

6.2Anmerkungen

6.2.1Anmerkungen definieren

6.3Aufräumen

6.4Zusammenfassung

7Service-Discovery

7.1Was ist Service-Discovery?

7.2Das Service-Objekt

7.2.1Service-DNS

7.2.2Readiness-Checks

7.3Über das Cluster hinausschauen

7.4Cloud-Integration

7.5Weitere Details

7.5.1Endpunkte

7.5.2Manuelle Service-Discovery

7.5.3kube-proxy und Cluster-IPs

7.5.4Umgebungsvariablen zur Cluster-IP

7.6Mit anderen Umgebungen verbinden

7.7Aufräumen

7.8Zusammenfassung

8HTTP Load Balancing mit Ingress

8.1Ingress-Spec versus Ingress-Controller

8.2Contour installieren

8.2.1DNS konfigurieren

8.2.2Eine lokale hosts-Datei konfigurieren

8.3Ingress verwenden

8.3.1Einfachste Anwendung

8.3.2Hostnamen verwenden

8.3.3Pfade verwenden

8.3.4Aufräumen

8.4Fortgeschrittenere Themen und Probleme mit Ingress

8.4.1Mehrere Ingress-Controller laufen lassen

8.4.2Mehrere Ingress-Objekte

8.4.3Ingress und Namensräume

8.4.4Path Rewriting

8.4.5TLS

8.5Alternative Ingress-Implementierungen

8.6Die Zukunft von Ingress

8.7Zusammenfassung

9ReplicaSets

9.1Reconciliation-Schleifen

9.2Die Verbindung zwischen Pods und ReplicaSets

9.2.1Bestehende Container übernehmen

9.2.2Container in Quarantäne stecken

9.3Mit ReplicaSets designen

9.4Spezifikation eines ReplicaSets

9.4.1Pod-Templates

9.4.2Labels

9.5Ein ReplicaSet erstellen

9.6Ein ReplicaSet untersuchen

9.6.1Ein ReplicaSet über einen Pod finden

9.6.2Eine Gruppe von Pods für ein ReplicaSet finden

9.7ReplicaSets skalieren

9.7.1Imperatives Skalieren mit kubectl scale

9.7.2Deklaratives Skalieren mit kubectl appy

9.7.3Ein ReplicaSet automatisch skalieren

9.8ReplicaSets löschen

9.9Zusammenfassung

10Deployments

10.1Ihr erstes Deployment

10.1.1Deployment-Interna

10.2Deployments erstellen

10.3Deployments verwalten

10.4Deployments aktualisieren

10.4.1Ein Deployment skalieren

10.4.2Ein Container-Image aktualisieren

10.4.3Rollout-History

10.5Deployment-Strategien

10.5.1Recreate-Strategie

10.5.2RollingUpdate-Strategie

10.5.3Rollouts verlangsamen, um die Service-Qualität sicherzustellen

10.6Ein Deployment löschen

10.7Ein Deployment überwachen

10.8Zusammenfassung

11DaemonSets

11.1Der DaemonSet-Scheduler

11.2DaemonSets erstellen

11.3DaemonSets auf bestimmte Knoten beschränken

11.3.1Knoten mit Labels versehen

11.3.2Knoten-Selektoren

11.4Ein DaemonSet aktualisieren

11.4.1Rollierendes Update eines DaemonSet

11.5Ein DaemonSet löschen

11.6Zusammenfassung

12Jobs

12.1Das Job-Objekt

12.2Job-Muster

12.2.1Einmalig

12.2.2Parallelism

12.2.3Work-Queues

12.3CronJobs

12.4Zusammenfassung

13ConfigMaps und Secrets

13.1ConfigMaps

13.1.1ConfigMaps erstellen

13.1.2Eine ConfigMap verwenden

13.2Secrets

13.2.1Secrets erstellen

13.2.2Secrets konsumieren

13.2.3Private Docker-Registries

13.3Namensbeschränkungen

13.4ConfigMaps und Secrets managen

13.4.1Ausgabe

13.4.2Erstellen

13.4.3Aktualisieren

13.5Zusammenfassung

14Role-Based Access Control für Kubernetes

14.1Role-Based Access Control

14.1.1Identität in Kubernetes

14.1.2Rollen und Role Bindings verstehen

14.1.3Rollen und Role Bindings in Kubernetes

14.2Techniken zur Arbeit mit RBAC

14.2.1Die Autorisierung mit can-i testen

14.2.2RBAC in der Versionsverwaltung managen

14.3Fortgeschrittene Techniken

14.3.1Cluster-Rollen aggregieren

14.3.2Gruppen für Bindings verwenden

14.4Zusammenfassung

15Storage-Lösungen in Kubernetes integrieren

15.1Externe Services importieren

15.1.1Services ohne Selektoren

15.1.2Grenzen für externe Services: Health-Checking

15.2Zuverlässige Singletons ausführen

15.2.1Ein MySQL-Singleton ausführen

15.2.2Dynamisches Volume-Provisioning

15.3Kubernetes-eigenes Storage mit StatefulSets

15.3.1Eigenschaften von StatefulSets

15.3.2Manuell replizierte MongoDB mit StatefulSets

15.3.3Das MongoDB-Cluster automatisch erstellen

15.3.4Persistente Volumes und StatefulSets

15.3.5Zum Abschluss: Readiness-Proben

15.4Zusammenfassung

16Kubernetes erweitern

16.1Was bedeutet das Erweitern von Kubernetes?

16.2Erweiterungspunkte

16.3Patterns für Custom Resources

16.3.1Just Data

16.3.2Compiler

16.3.3Operator

16.3.4Der Einstieg

16.4Zusammenfassung

17Reale Anwendungen deployen

17.1Jupyter

17.2Parse

17.2.1Voraussetzungen

17.2.2Den Parse-Server bauen

17.2.3Den Parse-Server deployen

17.2.4Parse testen

17.3Ghost

17.3.1Ghost konfigurieren

17.4Redis

17.4.1Redis konfigurieren

17.4.2Einen Redis-Service erstellen

17.4.3Redis deployen

17.4.4Mit unserem Redis-Cluster experimentieren

17.5Zusammenfassung

18Organisieren Sie Ihre Anwendung

18.1Leitprinzipien

18.1.1Dateisysteme als Source of Truth

18.1.2Die Rolle des Code Reviews

18.1.3Feature Gates und Guards

18.2Ihre Anwendung in der Versionsverwaltung managen

18.2.1Struktur im Dateisystem

18.2.2Regelmäßige Versionen managen

18.3Ihre Anwendung für Entwicklung, Testen und Deployment strukturieren

18.3.1Ziele

18.3.2Verlauf eines Releases

18.4Ihre Anwendung durch Templates parametrisieren

18.4.1Mit Helm und Templates parametrisieren

18.4.2Dateisystem-Layout zur Parametrisierung

18.5Ihre Anwendung weltweit deployen

18.5.1Architekturen für ein weltweites Deployment

18.5.2Ein weltweites Deployment implementieren

18.5.3Dashboards und Monitoring für weltweite Deployments

18.6Zusammenfassung

Index

Vorwort

Kubernetes: Eine Widmung

Kubernetes möchte jedem Sysadmin danken, der um 3 Uhr in der Früh geweckt wurde, um einen Prozess neu zu starten. Jedem Entwickler, der Code in die Produktivumgebung geschoben hat, um dann festzustellen, dass er dort nicht wie auf dem eigenen Laptop lief. Jedem Systemarchitekten, der unabsichtlich einen Lasttest gegen den Produktivservice laufen ließ, weil irgendein Hostname nicht angepasst wurde. Dieser Schmerz, diese unfreundlichen Arbeitszeiten und diese verrückten Fehler haben die Entwicklung von Kubernetes inspiriert. Kurz: Kubernetes will das Bauen, Deployen und Warten verteilter Systeme radikal vereinfachen. Es wurde durch die jahrzehntelange Erfahrung beim Bauen zuverlässiger Systeme inspiriert und ist von Grund auf so entworfen, dass sein Einsatz vielleicht nicht euphorisch macht, aber zumindest erfreut. Wir hoffen, Sie haben an diesem Buch Spaß!

Wer dieses Buch lesen sollte

Ob Sie mit verteilten Systemen noch keine Erfahrung haben oder schon seit Jahren Cloud-native Systeme deployen – Container und Kubernetes können Ihnen dabei helfen, in Bezug auf Geschwindigkeit, Agilität, Zuverlässigkeit und Effizienz in ganz neue Bereiche vorzustoßen. Dieses Buch beschreibt den Cluster-Orchestrierer Kubernetes und die Anwendung seiner Tools und APIs, um die Entwicklung, Auslieferung und Wartung verteilter Anwendungen zu verbessern. Es wird zwar keine Erfahrung mit Kubernetes vorausgesetzt, aber um den größtmöglichen Nutzen aus diesem Buch zu ziehen, sollten Sie mit dem Bauen und Deployen von serverbasierten Anwendungen vertraut sein. Wenn Sie Konzepte wie Load Balancer und Network Storage kennen, ist das nützlich, aber nicht zwingend erforderlich. Genauso ist Erfahrung mit Linux, Linux-Containern und Docker zwar nicht essenziell, aber sie hilft Ihnen, um das Buch möglichst gut einsetzen zu können.

Warum wir dieses Buch geschrieben haben

Wir haben mit Kubernetes seit seinen Anfängen zu tun. Es war wirklich erstaunlich, seine Entwicklung von einer Spielerei, die vor allem experimentell genutzt wurde, hin zu einer zentralen, produktionsreifen Infrastruktur zu beobachten, die produktive Anwendung im großen Maßstab in vielen Bereichen betreibt. Auf diesem Weg wurde immer deutlicher, dass ein Buch mit den zentralen Konzepten von Kubernetes und der Motivation hinter der Entwicklung dieser Konzepte für die aktuelle Cloud-native Anwendungsentwicklung ein wichtiger Beitrag wäre. Wir hoffen, dass Sie mit dem Lesen dieses Buches nicht nur lernen, wie Sie zuverlässige und skalierbare Anwendungen auf Basis von Kubernetes bauen, sondern auch Einblicke in die zentralen Herausforderungen verteilter Systeme erlangen, die zu dessen Entwicklung geführt haben.

Warum wir dieses Buch aktualisiert haben

In den Jahren seit dem Erscheinen der ersten Auflage dieses Buches ist das Ökosystem von Kubernetes gewachsen und hat sich weiterentwickelt. Es gab viele neue Releases von Kubernetes selbst und viele Tools und Patterns für den Einsatz von Kubernetes wurden zu De-facto-Standards. Mit dieser Neuauflage haben wir Informationen zum HTTP Load Balancing, zur Role-Based Access Control (RBAC), zum Erweitern der Kubernetes-API, das Organisieren Ihrer Anwendung unter Versionsverwaltung und vieles mehr ergänzt. Auch haben wir die bestehenden Kapitel auf den neuesten Stand gebracht, um die Änderungen und die Weiterentwicklung von Kubernetes widerzuspiegeln. Wir gehen fest davon aus, dieses Buch in ein paar Jahren erneut überarbeiten zu müssen (und freuen uns darauf), wenn Kubernetes weiter seinen Weg geht.

Ein Wort zu aktuellen Cloud-nativen Anwendungen

Von den ersten Programmiersprachen über die objektorientierte Programmierung bis hin zur Entwicklung der Virtualisierung und Cloud-Infrastruktur ist die Geschichte der Informatik auch eine Geschichte der Entwicklung von Abstraktionen, die Komplexität verbergen und Sie in die Lage versetzen, immer ausgefeiltere Anwendungen zu bauen. Trotzdem ist das Entwickeln zuverlässiger, skalierbarer Anwendungen immer noch eine viel größere Herausforderung, als es sein sollte. In den letzten Jahren hat sich gezeigt, dass Container und zugehörige Orchestrierungs-APIs wie Kubernetes zu einer wichtigen Abstraktion wurden, die die Entwicklung zuverlässiger, skalierbarer und verteilter Systeme radikal vereinfacht hat. Auch wenn Container und Orchestrierer immer noch auf dem Weg in den Mainstream sind, ermöglichen sie es Entwicklern schon, Anwendungen mit einer Schnelligkeit, Agilität und Zuverlässigkeit zu bauen, die vor ein paar Jahren noch als unerreichbare Zukunftsmusik gegolten hätten.

Was Sie in diesem Buch finden

Dieses Buch ist wie folgt organisiert. Kapitel 1 umreißt auf allgemeinem Niveau die Vorteile von Kubernetes, ohne allzu sehr in die Details zu gehen. Wenn Kubernetes für Sie neu ist, hilft Ihnen dieses Kapitel, zu verstehen, warum Sie den Rest des Buches lesen sollten.

Kapitel 2 liefert eine detaillierte Einführung in Container und die containerisierte Anwendungsentwicklung. Wenn Sie noch nie mit Docker gespielt haben, wird dieses Kapitel eine nützliche Einführung sein. Sind Sie schon ein Docker-Experte, wird es sich für Sie eher um ein Review handeln.

Kapitel 3 behandelt das Deployen von Kubernetes. Während sich ein Großteil dieses Buches darum dreht, wie Sie Kubernetes einsetzen, brauchen Sie ein lauffähiges Cluster, bevor Sie loslegen können. Das Betreiben eines Clusters für eine Produktiv-Umgebung liegt außerhalb des Rahmens dieses Buches, aber in diesem Kapitel stellen wir ein paar einfache Wege vor, ein Cluster so aufzusetzen, dass Sie verstehen können, wie Sie Kubernetes einsetzen. Kapitel 4 beschreibt eine Auswahl von gebräuchlichen Befehlen, die zur Interaktion mit Kubernetes-Clustern eingesetzt werden.

Ab Kapitel 5 kümmern wir uns um die Details des Deployens einer Anwendung mit Kubernetes. Wir beschreiben Pods (Kap. 5), Labels und Anmerkungen (Kap. 6), Services (Kap. 7), Ingress (Kap. 8) und ReplicaSets (Kap. 9). Diese bilden die Grundlagen für das Deployen Ihres Service in Kubernetes. Dann wenden wir uns Deployments zu (Kap. 10), die den Lebenszyklus einer kompletten Anwendung verbinden.

Als Nächstes geht es um speziellere Objekte in Kubernetes: DaemonSets (Kap. 11), Jobs (Kap. 12) sowie ConfigMaps und Secrets (Kap. 13). Diese Kapitel sind zwar für viele produktive Anwendungen wichtig, aber wenn Sie Kubernetes gerade erst kennenlernen, können Sie sie überspringen und sich später mit ihnen beschäftigen, wenn Sie mehr Erfahrung und Expertise erlangt haben. In Kapitel 14 stellen wir dann die Role-Based Access Control (RBAC) vor.

Nun wenden wir uns dem Integrieren von Storage in Kubernetes (Kap. 15) und dem Erweitern von Kubernetes zu (Kap. 16). Zum Schluss stellen wir noch Beispiele für das Entwickeln und Deployen realer Anwendungen in Kubernetes vor (Kap. 17) und beschreiben, wie Sie Ihre Anwendungen unter Versionskontrolle organisieren können (Kap. 18).

Online-Ressourcen

Sie sollten Docker (https://docker.com) installieren. Auch werden Sie sich mit der zugehörigen Dokumentation vertraut machen wollen, wenn Sie das noch nicht getan haben.

Genauso sollten Sie das Befehlszeilen-Tool kubectl (https://kubernetes.io) installieren und dem Slack-Channel Kubernetes beitreten (https://slack.kubernetes.io), wo Sie eine große Community vorfinden, die nahezu rund um die Uhr zum Reden und Beantworten von Fragen bereitsteht.

Wenn Sie schließlich mehr Erfahrung gesammelt haben, können Sie sich auch mit dem Open-Source-Repository von Kubernetes auf GitHub vertraut machen (https://github.com/kubernetes/kubernetes).

Konventionen in diesem Buch

Die folgenden typografischen Konventionen werden in diesem Buch genutzt:

Kursiv

Für neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen.

Nichtproportionalschrift

Für Programmlistings, aber auch für Codefragmente in Absätzen, wie zum Beispiel Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter.

fette Nichtproportionalschrift

Für Befehle und anderen Text, der genau so vom Benutzer eingegeben werden sollte.

kursive Nichtproportionalschrift

Für Text, der vom Benutzer durch eigene Werte ersetzt werden sollte.

Tipp

Dieses Symbol steht für einen Tipp, Vorschlag oder allgemeinen Hinweis.

Warnung

Dieses Symbol steht für eine Warnung oder Vorsichtsmaßnahme.

Der Download und Einsatz von Codebeispielen

Die aktuellen Codebeispiele zu diesem Buch finden Sie zum Herunterladen auf:

https://dpunkt.de/produkt/kubernetes-2

Dieses Buch ist dazu da, Ihnen beim Erledigen Ihrer Arbeit zu helfen. Im Allgemeinen dürfen Sie die Codebeispiele aus diesem Buch in Ihren eigenen Programmen und der dazugehörigen Dokumentation verwenden. Sie müssen uns dazu nicht um Erlaubnis fragen, solange Sie nicht einen beträchtlichen Teil des Codes reproduzieren. Beispielsweise benötigen Sie keine Erlaubnis, um ein Programm zu schreiben, in dem mehrere Codefragmente aus diesem Buch vorkommen. Wollen Sie dagegen eine CD-ROM mit Beispielen aus Büchern vom dpunkt.verlag verkaufen oder verteilen, benötigen Sie eine Erlaubnis. Eine Frage zu beantworten, indem Sie aus diesem Buch zitieren und ein Codebeispiel wiedergeben, benötigt keine Erlaubnis. Eine beträchtliche Menge Beispielcode aus diesem Buch in die Dokumentation Ihres Produkts aufzunehmen, bedarf hingegen einer Erlaubnis.

Wir freuen uns über Zitate, verlangen diese aber nicht. Ein Zitat enthält Titel, Autor, Verlag und ISBN. Beispiel: »Kubernetes von Brendan Burns, Joe Beda und Kelsey Hightower. Copyright 2021 dpunkt.verlag GmbH, 978-3-86490-803-3.«

Wenn Sie glauben, dass Ihre Verwendung von Codebeispielen über die übliche Nutzung hinausgeht oder außerhalb der oben vorgestellten Nutzungsbedingungen liegt, kontaktieren Sie uns bitte unter [email protected]

Wie Sie uns erreichen

Mit Anmerkungen, Fragen oder Verbesserungsvorschlägen zu diesem Buch können Sie sich jederzeit an den Verlag wenden:

[email protected]

Bitte beachten Sie, dass über unsere E-Mail-Adresse kein Software-Support angeboten wird.

Danksagungen

Wir möchten uns bei allen bedanken, die zum Entstehen dieses Buches beigetragen haben. Dazu gehören unsere Lektorin Virginia Wilson und all die tollen Leute bei O’Reilly, aber auch die technischen Korrektoren, die so viel Feedback geliefert und das Buch damit deutlich verbessert haben. Schließlich möchten wir uns noch bei allen Lesern der ersten Auflage bedanken, die sich die Zeit genommen haben, Fehler einzusenden, die wir in der zweiten Auflage beheben konnten. Vielen Dank an alle!

1Einführung

Kubernetes ist ein Open-Source-Orchestrierer für das Deployen containerisierter Anwendungen. Es wurde ursprünglich von Google entwickelt und ist durch ein Jahrzehnt Erfahrung beim Deployen skalierbarer, zuverlässiger Systeme in Containern über anwendungsorientierte APIs inspiriert.1

Seit seiner Premiere im Jahr 2014 hat sich Kubernetes zu einem der weltweit größten und erfolgreichsten Open-Source-Projekte gemausert. Es wurde zur Standard-API für das Erstellen Cloud-nativer Anwendungen und ist für so gut wie jede öffentliche Cloud verfügbar. Kubernetes bietet eine gut getestete Infrastruktur für verteilte Systeme, die für Cloud-native Entwickler in allen Maßstäben passt – von einem Cluster aus Raspberry Pis bis hin zu einem Rechenzentrum voller leistungsfähiger, moderner Rechner. Es liefert die Software, die notwendig ist, um zuverlässige, skalierbare verteilte Systeme zu bauen und zu deployen.

Sie fragen sich vielleicht, was wir meinen, wenn es um »zuverlässige, skalierbare verteilte Systeme« geht. Mehr und mehr Services werden über das Netzwerk per API bereitgestellt. Diese APIs werden oft durch ein verteiltes System bedient, also den diversen Elementen, die die API implementieren und auf verschiedenen Rechnern laufen, die über das Netz verbunden sind und ihre Aktionen per Netzwerk-Kommunikation koordinieren. Weil wir uns in allen Aspekten unseres täglichen Lebens zunehmend auf diese APIs verlassen (zum Beispiel, den Weg zum nächsten Krankenhaus zu finden), müssen diese Systeme ausgesprochen zuverlässig sein. Sie dürfen keine Ausfälle haben, auch dann nicht, wenn ein Teil des Systems abstürzt oder anderweitig stehen bleibt. Auch müssen sie selbst während Software-Rollouts oder anderen Wartungsvorgängen weiterhin verfügbar sein. Und weil schließlich mehr und mehr Teile der Welt online gehen und solche Services nutzen, müssen diese gut skalierbar sein, damit ihre Kapazität mit der stetig wachsenden Nutzung mithalten kann, ohne dass das dahinterliegende verteilte System radikal umgeplant werden muss.

Abhängig davon, wann und warum Sie dieses Buch in Ihren Händen halten, besitzen Sie vermutlich unterschiedlich viel Erfahrung mit Containern, verteilten Systemen und Kubernetes. Vielleicht planen Sie, Ihre Anwendung mithilfe der Infrastruktur einer öffentlichen Cloud zu bauen, in eigenen Data Centers oder in einer hybriden Umgebung. Aber unabhängig von Ihrer Erfahrung hoffen wir, dass Sie mit diesem Buch Kubernetes so gut wie möglich nutzen können.

Es gibt viele Gründe, warum die Leute Container und Container-APIs wie Kubernetes verwenden, aber wir sind der Meinung, dass sie alle auf einen dieser Vorteile zurückgeführt werden können:

Schnelligkeit

Skalierbarkeit (sowohl der Software als auch der Teams)

Abstrahieren Ihrer Infrastruktur

Effizienz

In den folgenden Abschnitten beschreiben wir, wie Kubernetes Ihnen dabei helfen kann, alle diese Features umzusetzen.

1.1Schnelligkeit

Die Schnelligkeit ist bei so gut wie jeder aktuellen Software-Entwicklung von zentraler Bedeutung. Die Softwarebranche hat sich von verpackten CDs oder DVDs hin zu Software entwickelt, die als webbasierte Services über das Netz bereitgestellt wird, die stündlich Aktualisierungen erfahren. Diese sich verändernde Landschaft sorgt dafür, dass der Unterschied zwischen Ihnen und Ihrer Konkurrenz oft die Schnelligkeit ist, mit der Sie neue Komponenten und Features entwickeln und deployen können oder mit der es Ihnen möglich ist, auf von anderen entwickelte Innovationen zu reagieren.

Es sei aber darauf hingewiesen, dass Schnelligkeit nicht einfach die reine Geschwindigkeit ist. Während Ihre Anwender immer nach iterativen Verbesserungen Ausschau halten, sind sie trotzdem mehr an einem äußerst zuverlässigen Service interessiert. Früher war es in Ordnung, wenn ein Service jede Nacht um Mitternacht zu Wartungszwecken offline war. Aber heute erwarten alle Anwender durchgehende Uptime, auch wenn sich die Software, die das Ganze betreibt, fortlaufend ändert.

Konsequenterweise wird die Schnelligkeit nicht daran gemessen, wie viele Features Sie pro Stunde oder pro Tag liefern können, sondern wie viele Dinge Sie liefern können, während der Service weiterhin hochverfügbar ist.

Dafür können Container und Kubernetes die Werkzeuge liefern, die Sie benötigen, um sich schnell bewegen zu können, während Ihre Services verfügbar bleiben. Die zentralen Konzepte, die das ermöglichen, sind:

Immutabilität

deklarative Konfiguration

Online-Systeme, die sich selbst heilen

Diese Ideen arbeiten alle zusammen, um die Schnelligkeit, mit der Sie zuverlässig Software deployen können, radikal zu verbessern.

1.1.1Der Wert der Immutabilität

Container und Kubernetes unterstützen Entwickler dabei, verteilte Systeme zu bauen, die sich an den Prinzipien der immutablen Infrastruktur orientieren. Bei einer solchen immutablen (unveränderlichen) Infrastruktur ändert sich ein Artefakt, sobald es einmal im System erzeugt wurde, nicht mehr durch die Anwender.

Klassisch wurden Computer- und Software-Systeme als mutable (änderbare) Infrastruktur betrachtet. Dabei werden Änderungen als inkrementelle Updates auf ein bestehendes System angewendet. Diese Updates können alle auf einmal vorgenommen werden oder auf einen langen Zeitraum verteilt sein. Ein System-Upgrade per apt-get update ist ein gutes Beispiel für ein Update eines mutablen Systems. Durch die Ausführung von apt werden nacheinander aktualisierte Binaries heruntergeladen, über die ältere Binaries kopiert und inkrementelle Anpassungen an Konfigurationsdateien vorgenommen werden. Bei einem mutablen System ist der aktuelle Status der Infrastruktur nicht als einzelnes Artefakt repräsentiert, sondern als Ansammlung inkrementeller Updates und Änderungen. Bei vielen Systemen kommen diese inkrementellen Updates nicht nur durch System-Updates zustande, sondern auch über Eingriffe durch den Nutzer. Zudem ist es in jedem von einem großen Team betreuten System sehr wahrscheinlich, dass diese Änderungen von vielen verschiedenen Leuten vorgenommen werden und sehr gerne nirgendwo dokumentiert wurden.

Im Gegensatz dazu wird bei einem immutablen System nicht eine Folge inkrementeller Updates und Änderungen angewendet, sondern es wird ein neues, vollständiges Image gebaut, und beim Update in einem einzigen Schritt das gesamte alte Image durch das neue ersetzt. Es gibt keine inkrementellen Änderungen. Wie Sie sich vorstellen können, ist das ein deutlicher Unterschied zum eher klassischen Wert des Konfigurations-Managements.

Um das in der Welt der Container konkreter zu machen, schauen Sie sich diese beiden verschiedenen Wege an, Ihre Software zu aktualisieren:

Sie können sich an einem Container anmelden, einen Befehl ausführen, um Ihre neue Software herunterzuladen, den alten Server abschießen und den neuen starten.

Sie können ein neues Container-Image bauen, es in eine Container-Registry schieben, den bestehenden Container abschießen und einen neuen starten.

Auf den ersten Blick mögen diese beiden Ansätze kaum unterscheidbar sein. Warum sorgt dann das Bauen eines neuen Containers für eine verbesserte Zuverlässigkeit?

Der entscheidende Unterschied ist das Artefakt, das Sie erstellen, und die Aufzeichnung, die beim Erstellen entsteht. Diese Aufzeichnung erleichtert es, die exakten Unterschiede in einer neuen Version zu verstehen. Geht etwas schief, können Sie herausfinden, was sich geändert hat und wie sich das korrigieren lässt.

Zudem sorgt das Bauen eines neuen Images statt des Anpassens eines bestehenden dafür, dass das alte Image immer noch verfügbar ist, sodass Sie dieses für ein Rollback nutzen können, wenn ein Fehler auftritt. Haben Sie im Gegensatz dazu Ihr neues Binary über ein bestehendes kopiert, ist solch ein Rollback nahezu unmöglich.

Immutable Container-Images bilden den Kern von allem, was Sie in Kubernetes bauen. Es ist möglich, im Notfall laufende Container anzupassen, aber das ist ein Antipattern, das nur in extremen Fällen eingesetzt werden sollte, wenn es keine anderen Optionen gibt (zum Beispiel, wenn es die einzige Möglichkeit ist, ein unternehmenskritisches Produktiv-System kurzfristig zu reparieren). Und selbst dann müssen die Änderungen später über ein deklaratives Konfigurations-Update dokumentiert werden, nachdem der Brand gelöscht wurde.

1.1.2Deklarative Konfiguration

Immutabilität geht über die Container in Ihrem Cluster hinaus. Sie bezieht sich auch auf die Art und Weise, wie Sie Ihre Anwendung in Kubernetes beschreiben. Alles in Kubernetes ist ein deklaratives Konfigurations-Objekt, das den gewünschten Status des Systems repräsentiert. Es ist dann die Aufgabe von Kubernetes, sicherzustellen, dass der aktuelle Status der Wirklichkeit mit dem gewünschten Status übereinstimmt.

So wie bei mutabler und immutabler Infrastruktur ist die deklarative Konfiguration eine Alternative zur imperativen Konfiguration, bei der der Status der Welt durch das Ausführen einer Folge von Anweisungen beschrieben wird, statt den gewünschten Status zu deklarieren. Während imperative Befehle Aktionen definieren, definieren deklarative Konfigurationen einen Status.

Um diese beiden Ansätze zu verstehen, schauen Sie sich die Aufgabe an, drei Instanzen einer Software zu erzeugen. Bei einem imperativen Vorgehen würde die Konfiguration sagen: »Führe A aus, führe B aus, führe C aus.« Die entsprechende deklarative Konfiguration würde lauten: »Anzahl an Instanzen gleich drei.«

Da der Status der Welt beschrieben wird, muss eine deklarative Konfiguration nicht ausgeführt werden, um sie zu verstehen. Ihre Auswirkung ist konkret deklariert. Da die Auswirkungen einer deklarativen Konfiguration auch ohne Ausführen verstanden werden können, ist sie weniger fehleranfällig. Zudem können die klassischen Tools der Softwareentwicklung, wie Versionsverwaltung, Code-Review und Unit-Tests, bei deklarativen Konfigurationen auf eine Art und Weise eingesetzt werden, wie dies bei imperativen Anweisungen nie möglich wäre. Die Idee, deklarative Konfiguration unter Versionsverwaltung zu stellen, wird oft als »Infrastruktur als Code« bezeichnet.

Die Kombination aus einem deklarativen Status in einem Versionierungssystem und den Fähigkeiten von Kubernetes, in der Realität diesen deklarativen Status zu erreichen, macht das Rollback einer Änderung ausgesprochen einfach. Es wird einfach der vorige deklarative Status des Systems gewählt. Bei imperativen Systemen ist das meist unmöglich, denn die imperativen Anweisungen beschreiben, wie Sie von Punkt A nach Punkt B gelangen, aber nur sehr selten sind die umgekehrten Anweisungen für den Rückweg enthalten.

1.1.3Selbstheilende Systeme

Kubernetes ist ein selbstheilendes Online-System. Erhält es eine Konfiguration für einen gewünschten Status, nimmt es nicht nur einmalig die Schritte vor, um den aktuellen Status in den gewünschten Status zu überführen. Es achtet auch kontinuierlich darauf, dass der aktuelle Status und der gewünschte Status weiterhin übereinstimmen. Das heißt, Kubernetes initialisiert nicht nur Ihr System, sondern schützt es auch vor Fehlern oder Störungen, die es eventuell destabilisieren und die Zuverlässigkeit beeinträchtigen.

Bei einer klassischeren Reparatur durch Operatoren gibt es eine Reihe von manuellen Maßnahmen oder Eingriffe durch einen Menschen als Reaktion auf eine Warnung. Diese imperative Reparatur ist teurer (da dazu meist jemand Bereitschaftsdienst machen muss, um die Reparatur anzustoßen). Zudem ist sie im Allgemeinen langsamer, da ein Mensch oft erst aufwachen und sich anmelden muss, um reagieren zu können. Zudem ist sie weniger zuverlässig, da die imperative Folge von Reparationsschritten all die Probleme imperativen Managements mit sich bringt, die im vorigen Abschnitt beschrieben wurden. Selbstheilende Systeme wie Kubernetes reduzieren gleichzeitig die Last für die Operatoren und verbessern die Gesamtzuverlässigkeit des Systems, indem erprobte Reparaturen schneller durchgeführt werden.

Als Beispiel für dieses selbstheilende Verhalten nutzen wir wieder unseren gewünschten Status mit drei laufenden Instanzen in Kubernetes. Dabei legt es nicht nur diese Instanzen an, es stellt auch fortlaufend sicher, dass es immer genau drei Instanzen gibt. Erstellen Sie manuell eine vierte Instanz, wird Kubernetes eine zerstören, um die Anzahl wieder auf drei zu verringern. Beenden Sie manuell eine Instanz, erzeugt Kubernetes eine, um den gewünschten Status zu erreichen.

Selbstheilende Online-Systeme verbessern die Entwickler-Schnelligkeit, weil die Zeit und Energie, die Sie sonst für Operations und Wartung aufgewendet haben, nun für das Entwickeln und Testen neuer Features genutzt werden kann.

Für eine ausgefeiltere Form der Selbstheilung gab es jüngst deutliche Verbesserungen am Operator-Paradigma für Kubernetes. Dabei ist eine komplexere Logik zum Warten, Skalieren und Heilen einer bestimmten Software (zum Beispiel MySQL) in einer Operator-Anwendung verpackt, die als Container in einem Cluster läuft. Der Code im Operator ist dafür verantwortlich, den Status gezielter und ausgefeilter zu erkennen und Probleme zu beheben, als das mit den generischen Selbstheilungs-Fähigkeiten von Kubernetes möglich ist. Solche »Operatoren« werden später noch behandelt.

1.2Ihren Service und Ihre Teams skalieren

Wenn Ihr Produkt wächst, ist es unvermeidlich, dass Sie sowohl Ihre Software als auch das Team skalieren müssen, das diese entwickelt. Glücklicherweise kann Kubernetes dabei helfen, beide Ziele zu erreichen. Es nutzt dazu eine entkoppelte Architektur.

1.2.1Entkoppeln

In einer entkoppelten Architektur ist jede Komponente von anderen Komponenten durch definierte APIs und Service-Load-Balancer getrennt. APIs und Load Balancer isolieren jedes Teil des Systems von den anderen. APIs dienen als Puffer zwischen dem Implementierer und dem Konsumenten und die Load Balancer liefern den Puffer zwischen den laufenden Instanzen jedes Service.

Das Entkoppeln von Komponenten über Load Balancer erleichtert das Skalieren des Programms, das hinter Ihrem Service steckt, weil das Erhöhen der Größe (und damit der Kapazität) des Programms erreicht werden kann, ohne dass eine der anderen Schichten Ihres Service angepasst oder umkonfiguriert werden muss.

Das Entkoppeln von Servern über APIs erleichtert das Skalieren des Entwicklungsteams, weil sich jedes Team auf einen einzelnen, kleineren Microservice mit einer verständlichen Oberfläche konzentrieren kann. Knackige APIs zwischen den Microservices beschränken die Menge an teamübergreifendem Kommunikationsoverhead, der notwendig ist, um Software zu bauen und zu deployen. Dieser Kommunikationsoverhead ist häufig der größte beschränkende Faktor, wenn man Teams skaliert.

1.2.2Einfaches Skalieren für Anwendungen und Cluster

Wenn Sie ganz konkret Ihren Service skalieren müssen, sorgt die immutable, deklarative Natur von Kubernetes dafür, dass dieses Skalieren trivial zu implementieren ist. Weil Ihre Container immutabel sind und die Anzahl der Instanzen einfach eine Zahl in einer deklarativen Konfiguration ist, geht es beim Hochskalieren Ihres Service schlicht darum, eine Zahl in einer Konfigurationsdatei zu ändern, diesen neuen deklarativen Status Kubernetes mitzuteilen und es sich dann um den Rest kümmern zu lassen. Alternativ können Sie auch ein Autoscaling einrichten und das Ganze von Kubernetes erledigen lassen.

Natürlich wird bei dieser Art von Skalierung davon ausgegangen, dass es in Ihrem Cluster Ressourcen gibt, die genutzt werden können. Manchmal müssen Sie aber auch das Cluster selbst skalieren. Auch hier hilft Kubernetes. Weil viele Maschinen in einem Cluster identisch mit anderen sind und die Anwendung selbst von den Maschinendetails durch die Container entkoppelt ist, geht es beim Hinzufügen von Ressourcen zum Cluster nur darum, eine neue Maschine der gleichen Klasse mit einem Image zu versehen und sie in das Cluster einzuhängen. Das lässt sich über ein paar einfache Befehle oder ein vorgefertigtes Image erreichen.

Eine der Herausforderungen beim Skalieren von Rechner-Ressourcen ist die Vorhersage der Verwendung. Lassen Sie Ihr Cluster auf einer Infrastruktur aus echten Rechnern laufen, wird die Zeit zum Bereitstellen einer neuen Maschine in Tagen oder Wochen gemessen. Sowohl bei einer »echten« wie auch bei einer Cloud-Infrastruktur ist die Vorhersage zukünftiger Kosten schwierig, weil es schwerfällt, das Wachstum und die Skalierungsanforderungen bestimmter Anwendungen zu prognostizieren.

Kubernetes kann das Vorhersagen zukünftiger Kosten vereinfachen. Um das zu verstehen, stellen Sie sich das Vergrößern von den drei Teams A, B und C vor. Aus Erfahrung wissen Sie, dass das Wachstum jedes Teams sehr variabel ist und sich daher schlecht vorhersagen lässt. Provisionieren Sie für jeden Service individuelle Maschinen, haben Sie keine andere Wahl, als Ihre Vorhersagen auf der maximal zu erwartenden Wachstumsrate für jeden Service basieren zu lassen, da die Rechner für das eine Team nicht für ein anderes Team eingesetzt werden können. Nutzen Sie stattdessen Kubernetes, um die Teams von den spezifischen Rechnern zu entkoppeln, können Sie das Wachstum basierend auf dem Gesamtwachstum aller drei Services vorhersagen. Durch das Kombinieren von drei variablen Wachstumsraten zu einer einzigen Rate reduzieren Sie statistisches Rauschen und sorgen für eine zuverlässigere Vorhersage des zu erwartenden Wachstums. Zudem bedeutet das Entkoppeln spezifischer Maschinen von den Teams, dass diese auch Anteile der Rechner mit anderen teilen können und damit den Overhead noch weiter verringern, der mit dem Vorhersagen der Wachstumsanforderungen von Rechenressourcen verbunden ist.

1.2.3Entwicklungs-Teams mit Microservices skalieren

Wie sich in einer Reihe von Untersuchungen gezeigt hat, ist die ideale Teamgröße das »Zwei-Pizza-Team« – etwa sechs bis acht Personen –, weil diese Gruppengröße häufig zu einer guten Wissensverteilung, schnellen Entscheidungen und einem teamweiten Verständnis für die Aufgaben führt. Größere Teams tendieren dazu, mit Hierarchien, schlechter Sichtbarkeit und Machtkämpfen zu hadern, was ihre Agilität und ihren Erfolg einschränkt.

Für viele Projekte sind aber deutlich mehr Ressourcen notwendig, um erfolgreich zu sein und die Ziele zu erreichen. Daher gibt es einen Konflikt zwischen der idealen Teamgröße für gute Agilität und der notwendigen Teamgröße für das Erreichen der Produktziele.

Die übliche Lösung für diese Spannung ist das Entwickeln in entkoppelten, serviceorientierten Teams, die jeweils einen einzelnen Microservice bauen. Jedes kleine Team ist für das Design und die Auslieferung eines Service verantwortlich, der von anderen kleinen Teams konsumiert wird. Das Zusammenführen all dieser Services bildet dann schließlich die Implementierung der Schnittstelle des Gesamtprodukts.

Kubernetes stellt eine Reihe von Abstraktionen und APIs bereit, die es leicht machen, diese entkoppelte Microservice-Architektur zu bauen.

Pods

– Gruppen von Containern – können von verschiedenen Teams entwickelte Container-Images zu einer einzelnen deploybaren Einheit verbinden.

Kubernetes-

Services

bieten Load Balancing, Naming und Discovery, um einen Microservice von anderen zu isolieren.

Namensräume

bieten Isolation und Zugriffskontrolle, sodass jeder Microservice steuern kann, inwieweit andere Services mit ihm interagieren können.

Ingress

-Objekte dienen als einfach zu nutzendes Frontend, das mehrere Microservices zu einer einzelnen externalisierten API kombinieren kann.

Und schließlich sorgt das Entkoppeln des Anwendungs-Container-Image und der Maschine dafür, dass verschiedene Microservices auf derselben Maschine laufen können, ohne sich gegenseitig ins Gehege zu kommen, was den Overhead und die Kosten der Microservice-Architektur verringert. Die Healthchecking- und Rollout-Features von Kubernetes garantieren ein konsistentes Vorgehen beim Anwendungs-Rollout und eine Zuverlässigkeit, die sicherstellt, dass eine Zunahme von Microservice-Teams nicht auch zu einer Zunahme unterschiedlicher Vorgehensweisen beim Lebenszyklus für die Service-Erstellung und in Operations führt.

1.2.4Konsistenz und Skalierung durch Separation of Concerns

Neben der Konsistenz, die Kubernetes in Operations mitbringt, sorgt das Entkoppeln und die Separation of Concerns, die durch den Kubernetes-Stack entsteht, für eine deutlich höhere Konsistenz bei den unteren Schichten Ihrer Infrastruktur. So kann Operations viele Maschinen mit einem kleinen, fokussierten Team verwalten. Sie haben schon viel über das Entkoppeln von Anwendungs-Containern und der Maschine beziehungsweise dem Betriebssystem (OS) gelesen, aber ein wichtiger Aspekt dieser Trennung ist, dass die Orchestrierungs-API für die Container zu einem klaren Vertrag wird, der die Verantwortlichkeiten von Anwendungs-Operator und Cluster-Orchestrierungs-Operator aufteilt. Wir nennen dies die »Not my monkey, not my circus«-Linie. Der Anwendungs-Entwickler verlässt sich auf das Service-Level Agreement (SLA) der Container-Orchestrierungs-API, ohne sich um die Details zu kümmern, wie dieses SLA erreicht wird. Genauso konzentriert sich der Techniker, der für die Zuverlässigkeit der Container-Orchestrierungs-API verantwortlich ist, darauf, das SLA der Orchestrierungs-API zu erreichen, ohne sich um die Anwendungen zu kümmern, die darauf laufen.

Dieses Entkoppeln der Verantwortung sorgt dafür, dass ein kleines Team, das ein Kubernetes-Cluster betreut, für die Unterstützung Hunderter oder gar Tausender von Teams verantwortlich sein kann, die Anwendungen in diesem Cluster laufen lassen (Abb. 1–1). Genauso kann ein kleines Team für Dutzende (oder mehr) Cluster zuständig sein, die auf der ganzen Welt verteilt sind. Es ist wichtig, darauf hinzuweisen, dass das gleiche Entkoppeln von Containern und OS es den für die Zuverlässigkeit des OS verantwortlichen Technikern ermöglicht, sich auf das SLA des OS für die einzelnen Maschinen zu konzentrieren. Das führt zu einer weiteren Trennlinie bei der Verantwortung – die Kubernetes-Operatoren bauen auf das SLA des OS und die OS-Operatoren kümmern sich nur darum, dieses SLA zu erfüllen. Auch hier kann so ein kleines Team von OS-Experten eine Flotte mit Tausenden von Maschinen betreuen.

Natürlich liegt ein Team – selbst ein kleines –, das sich nur um ein Betriebssystem kümmert, außerhalb der Möglichkeiten vieler Organisationen. In dieser Situation ist ein gemanagtes Kubernetes-as-a-Service (KaaS) von einem öffentlichen Cloud-Provider eine großartige Alternative. Mit zunehmender Verbreitung von Kubernetes sind auch immer mehr Angebote für KaaS entstanden – heutzutage wird es auf nahezu jeder öffentlichen Cloud angeboten. Natürlich hat der Einsatz von KaaS auch seine Grenzen, da der Operator Entscheidungen zum Aufbau und zur Konfiguration des Kubernetes-Clusters für Sie trifft. So sind beispielsweise auf vielen KaaS-Plattformen Alpha-Features abgeschaltet, weil sie das gemanagte Cluster destabilisieren können.

Abb. 1–1Eine Möglichkeit, wie die verschiedenen Operations-Teams durch APIs entkoppelt sind

Neben einem vollständig gemanagten Kubernetes-Service gibt es ein wachsendes Ökosystem aus Firmen und Projekten, die dabei helfen, Kubernetes zu installieren und zu warten. Das Spektrum der Lösungen bewegt sich dabei von »auf die harte Tour« bis zu einem vollständig gemanagten Service.

Die Entscheidung, KaaS zu verwenden oder selbst zu managen (oder einen Weg dazwischen zu wählen), ist daher eine, die jede Organisation abhängig von den Fähigkeiten und Anforderungen ihrer Situation selbst treffen muss. Häufig bietet KaaS für eine kleine Organisation eine leicht einsetzbare Lösung, durch die sie ihre Zeit und Energie auf das Bauen von Software konzentrieren kann, mit der sie ihre eigene Arbeit unterstützt, statt sich auch noch um das Managen eines Clusters kümmern zu müssen. Für eine größere Organisation, die sich ein eigenes Team für das Managen ihres Kubernetes-Clusters leisten kann, mag solch ein Team sinnvoll sein, da sie so mehr Flexibilität in Bezug auf Leistungsfähigkeit und Operations erhält.

1.3Abstrahieren Sie Ihre Infrastruktur