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 |
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: hallo@dpunkt.de.
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
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
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ß!
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.
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.
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.
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.
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).
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).
Die folgenden typografischen Konventionen werden in diesem Buch genutzt:
Dieses Symbol steht für einen Tipp, Vorschlag oder allgemeinen Hinweis.
Dieses Symbol steht für eine Warnung oder Vorsichtsmaßnahme.
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 hallo@dpunkt.de.
Mit Anmerkungen, Fragen oder Verbesserungsvorschlägen zu diesem Buch können Sie sich jederzeit an den Verlag wenden:
hallo@dpunkt.de
Bitte beachten Sie, dass über unsere E-Mail-Adresse kein Software-Support angeboten wird.
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!
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:
In den folgenden Abschnitten beschreiben wir, wie Kubernetes Ihnen dabei helfen kann, alle diese Features umzusetzen.
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:
Diese Ideen arbeiten alle zusammen, um die Schnelligkeit, mit der Sie zuverlässig Software deployen können, radikal zu verbessern.
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:
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.
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.
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.
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.
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.
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.