Produktion Kubernetes

Kapitel 1. Ein Weg zur Produktion

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Im Laufe der Jahre hat sich Kubernetes in den Unternehmen weltweit durchgesetzt. Die Popularität von Kubernetes wurde zweifellos durch die zunehmende Verbreitung von Container-Workloads und Microservices beschleunigt. Wenn Betriebs-, Infrastruktur- und Entwicklungsteams an diesem Wendepunkt ankommen, an dem sie diese Arbeitslasten erstellen, ausführen und unterstützen müssen, wenden sich viele an Kubernetes als Teil der Lösung. Kubernetes ist ein relativ junges Projekt im Vergleich zu anderen, großen Open-Source-Projekten wie Linux. Wie viele Kunden, mit denen wir zusammenarbeiten, zeigen, stehen die meisten Nutzer von Kubernetes noch ganz am Anfang. Während viele Unternehmen bereits Kubernetes einsetzen, gibt es nur sehr wenige, die es in die Produktion geschafft haben, und noch weniger, die in großem Maßstab arbeiten. In diesem Kapitel werden wir die Voraussetzungen für die Reise schaffen, die viele Ingenieurteams mit Kubernetes antreten. Insbesondere werden wir einige wichtige Überlegungen anstellen, die wir bei der Festlegung eines Weges zur Produktion berücksichtigen.

Kubernetes definieren

Ist Kubernetes eine Plattform? Eine Infrastruktur? Eine Anwendung? Es gibt viele Vordenker, die dir ihre genaue Definition von Kubernetes geben können. Anstatt zu diesem Haufen von Meinungen beizutragen, sollten wir unsere Energie darauf verwenden, die Probleme zu klären, die Kubernetes löst. Sobald wir das definiert haben, werden wir untersuchen, wie wir auf diesen Funktionen aufbauen können, um produktive Ergebnisse zu erzielen. Der ideale Zustand von "Produktions-Kubernetes" bedeutet, dass wir einen Zustand erreicht haben, in dem die Arbeitslasten erfolgreich den Produktionsverkehr bedienen.

Der Name Kubernetes kann ein bisschen wie ein Oberbegriff sein. Ein kurzer Blick auf GitHub zeigt, dass die Organisation kubernetes (zum Zeitpunkt der Erstellung dieses Artikels) 69 Repositories umfasst. Dann gibt es noch kubernetes-sigs mit etwa 107 Projekten. Und wir wollen gar nicht erst von den Hunderten von Projekten der Cloud Native Compute Foundation (CNCF) anfangen, die in dieser Landschaft mitspielen! In diesem Buch beziehen wir uns bei Kubernetes ausschließlich auf das Kernprojekt. Was ist also das Kernprojekt? Das Kernprojekt ist im Repository kubernetes/kubernetes enthalten. Hier befinden sich die wichtigsten Komponenten, die wir in den meisten Kubernetes-Clustern finden. Wenn wir einen Cluster mit diesen Komponenten betreiben, können wir die folgenden Funktionen erwarten:

• Zeitplannungsprogramm für Arbeitslasten auf vielen Hosts

• Bereitstellung einer deklarativen, erweiterbaren API für die Interaktion mit dem System

• Bereitstellung einer CLI, kubectl, für Menschen, die mit dem API-Server interagieren

• Abgleich vom aktuellen Zustand der Objekte mit dem gewünschten Zustand

• Bereitstellung einer Basisdienst-Abstraktion zur Unterstützung der Weiterleitung von Anfragen an und vonArbeitslasten

• Mehrere Schnittstellen zur Unterstützung von steckbaren Netzwerken, Speicherungen und mehr

Diese Fähigkeiten machen Kubernetes zu dem, was das Projekt selbst behauptet, nämlich zu einem produktionsreifen Container-Orchestrator. Einfacher ausgedrückt: Kubernetes ermöglicht es uns, Container-Workloads auf mehreren Hosts auszuführen und zu planen. Behalte diese primäre Fähigkeit im Hinterkopf, wenn wir tiefer eintauchen. Im Laufe der Zeit wollen wir zeigen, dass diese Fähigkeit zwar grundlegend ist, aber nur ein Teil unseres Weges zur Produktion.

Die wichtigsten Komponenten

Welches sind die Komponenten, die die von uns behandelten Funktionen bereitstellen? Wie wir bereits erwähnt haben, befinden sich die Kernkomponenten im kubernetes/kubernetes Repository. Viele von uns nutzen diese Komponenten auf unterschiedliche Weise. Wer z. B. verwaltete Dienste wie die Google Kubernetes Engine (GKE) nutzt, findet wahrscheinlich jede Komponente auf den Hosts. Andere laden vielleicht Binärdateien aus Repositories herunter oder erhalten signierte Versionen von einem Anbieter. Unabhängig davon kann jeder eine Kubernetes-Version aus dem Repository kubernetes/kubernetes herunterladen. Nach dem Herunterladen und Entpacken einer Version können die Binärdateien mit dem Befehl cluster/get-kube-binaries.sh abgerufen werden. Dadurch wird deine Zielarchitektur automatisch erkannt und die Server- und Client-Komponenten werden heruntergeladen. Schauen wir uns das im folgenden Code an und erkunden dann die wichtigsten Komponenten:

$ ./cluster/get-kube-binaries.sh

Kubernetes release: v1.18.6
Server: linux/amd64  (to override, set KUBERNETES_SERVER_ARCH)
Client: linux/amd64  (autodetected)

Will download kubernetes-server-linux-amd64.tar.gz from https://dl.k8s.io/v1.18.6
Will download and extract kubernetes-client-linux-amd64.tar.gz
Is this ok? [Y]/n

In den heruntergeladenen Serverkomponenten, die wahrscheinlich unter server/kubernetes-server-${ARCH}.tar.gz gespeichert sind, findest du die wichtigsten Elemente, aus denen ein Kubernetes-Cluster besteht:

API-Server

Der wichtigste Interaktionspunkt für alle Kubernetes-Komponenten und Nutzer. Hier werden Objekte geholt, hinzugefügt, gelöscht und verändert. Der API-Server delegiert den Status an ein Backend, in der Regel etcd.

kubelet

Der On-Host-Agent, der mit , dem API-Server, kommuniziert, um den Status eines Knotens zu melden und zu erfahren, welche Arbeitslasten auf ihm geplant werden sollen. Er kommuniziert mit der Container-Laufzeitumgebung des Hosts (z. B. Docker), um sicherzustellen, dass die für den Knoten geplanten Arbeitslasten gestartet und funktionsfähig sind.

Controller Manager

Eine Reihe von Controllern, die in einer einzigen Binärdatei gebündelt sind und den Abgleich vieler Kernobjekte in Kubernetes übernehmen. Wenn ein gewünschter Zustand deklariert wird, z. B. drei Replikate in einem Deployment, kümmert sich ein Controller um die Erstellung neuer Pods, um diesen Zustand zu erfüllen.

Zeitplannungsprogramm

Legt fest, wo die Arbeitslasten ausgeführt werden sollen, und zwar auf der Grundlage dessen, was es für den optimalen Knoten hält. Für diese Entscheidung verwendet es Filter und Scoring.

Kube Proxy

Implementiert Kubernetes-Dienste, die virtuelle IPs bereitstellen, die zu Backend-Pods geleitet werden können. Dies wird durch einen Paketfiltermechanismus auf einem Host wie iptables oder ipvs erreicht.

Diese Liste ist zwar nicht vollständig, aber es sind die wichtigsten Komponenten, aus denen die besprochenen Kernfunktionen bestehen. Abbildung 1-1 zeigt, wie diese Komponenten zusammenspielen.

Hinweis

Kubernetes-Architekturen haben viele Varianten. In vielen Clustern laufen zum Beispiel kube-apiserver, kube-scheduler und kube-controller-manager als Container. Das bedeutet, dass auf der Control-Plane auch eine Container-Runtime, ein Kubelet und ein Kube-Proxy laufen können. Diese Überlegungen zum Einsatz werden im nächsten Kapitel behandelt.

Abbildung 1-1. Die Hauptkomponenten, aus denen der Kubernetes-Cluster besteht. Die gestrichelten Grenzen stellen Komponenten dar, die nicht zum Kern von Kubernetes gehören.

Über die Orchestrierung hinaus - Erweiterte Funktionalität

Es gibt Bereiche, in denen Kubernetes mehr tut als nur Workloads zu orchestrieren. Wie bereits erwähnt, programmiert die Komponente kube-proxy Hosts, um eine virtuelle IP (VIP) für Arbeitslasten bereitzustellen. Dadurch werden interne IP-Adressen eingerichtet und an einen oder mehrere zugrunde liegende Pods weitergeleitet. Dieses Anliegen geht weit über das Ausführen und Planen von containerisierten Workloads hinaus. Anstatt dies als Teil von Kubernetes zu implementieren, hätte das Projekt theoretisch eine Service-API definieren und ein Plug-in für die Implementierung der Service-Abstraktion verlangen können. Bei diesem Ansatz müssten die Nutzer/innen zwischen einer Vielzahl von Plug-ins im Ökosystem wählen, anstatt sie alsKernfunktionalität zu implementieren.

Viele Kubernetes-APIs, wie Ingress und NetworkPolicy, arbeiten nach diesem Modell. Die Erstellung eines Ingress-Objekts in einem Kubernetes-Cluster garantiert zum Beispiel nicht, dass eine Aktion durchgeführt wird. Mit anderen Worten: Die API existiert zwar, ist aber keine Kernfunktionalität. Die Teams müssen sich überlegen, mit welcher Technologie sie diese API implementieren wollen. Für Ingress verwenden viele einen Controller wie ingress-nginx, der im Cluster läuft. Er implementiert die API, indem er Ingress-Objekte liest und NGINX-Konfigurationen für NGINX-Instanzen erstellt, die auf Pods zeigen. ingress-nginx ist jedoch nur eine von vielen Optionen. Das Projekt Contour implementiert die gleiche Ingress-API, programmiert aber stattdessen Instanzen von envoy, dem Proxy, der Contour zugrunde liegt. Dank dieses Plug-in-Modells stehen den Teams eine Vielzahl von Optionen zur Verfügung.

Kubernetes-Schnittstellen

Um diese Idee des Hinzufügens von Funktionen zu erweitern, sollten wir uns nun mit Schnittstellen beschäftigen. Kubernetes-Schnittstellen ermöglichen es uns, die Kernfunktionalität anzupassen und darauf aufzubauen. Wir betrachten eine Schnittstelle als eine Definition oder einen Vertrag darüber, wie mit etwas interagiert werden kann. In der Softwareentwicklung entspricht dies der Idee, Funktionen zu definieren, die Klassen oder Strukturen implementieren können. In Systemen wie Kubernetes setzen wir Plug-ins ein, die diese Schnittstellen erfüllen und Funktionen wie die Vernetzung bereitstellen.

Ein konkretes Beispiel für diese Schnittstelle/Plug-in-Beziehung ist das Container Runtime Interface (CRI). In den Anfängen von Kubernetes wurde nur eine einzige Container-Runtime unterstützt: Docker. Obwohl Docker auch heute noch in vielen Clustern eingesetzt wird, gibt es ein wachsendes Interesse an Alternativen wie containerd oder CRI-O. Abbildung 1-2 veranschaulicht diese Beziehung mit diesen beiden Container-Laufzeiten.

Abbildung 1-2. Zwei Workload-Knoten, auf denen zwei verschiedene Container-Laufzeiten laufen. Das Kubelet sendet in der CRI definierte Befehle wie CreateContainer und erwartet, dass die Runtime die Anfrage erfüllt und antwortet.

In vielen Schnittstellen werden Befehle wie CreateContainerRequest oder PortForwardRequest als Remote Procedure Calls (RPCs) ausgegeben. Im Fall von CRI läuft die Kommunikation über GRPC und das Kubelet erwartet Antworten wie CreateContainerResponse und PortForwardResponse. In Abbildung 1-2 siehst du auch zwei verschiedene Modelle, um CRI zu erfüllen. CRI-O wurde von Grund auf als eine Implementierung von CRI entwickelt. Daher gibt das Kubelet diese Befehle direkt an es aus. containerd unterstützt ein Plug-in, das als Zwischenglied zwischen dem Kubelet und seinen eigenen Schnittstellen fungiert. Unabhängig von der genauen Architektur geht es darum, dass die Container-Laufzeit ausgeführt wird, ohne dass das Kubelet für jede mögliche Laufzeit wissen muss, wie dies geschieht. Dieses Konzept macht die Schnittstellen so mächtig für die Architektur, den Aufbau und die Bereitstellung von Kubernetes-Clustern.

Im Laufe der Zeit wurden sogar einige Funktionen aus dem Kernprojekt zugunsten dieses Plug-in-Modells entfernt. Dabei handelt es sich um Dinge, die in der Vergangenheit "in-tree", d.h. innerhalb der kubernetes/kubernetes Codebasis, existierten. Ein Beispiel dafür ist die Integration von Cloud-Providern (CPI). Die meisten CPIs wurden traditionell in Komponenten wie dem kube-controller-manager und dem kubelet integriert. Diese Integrationen kümmerten sich in der Regel um Aufgaben wie die Bereitstellung von Load Balancern oder die Offenlegung von Cloud-Provider-Metadaten. Manchmal, insbesondere vor der Einführung des Container Storage Interface (CSI), stellten diese Anbieter auch Blockspeicher bereit und machten ihn für die in Kubernetes laufenden Workloads verfügbar. Das ist eine Menge Funktionalität für Kubernetes, ganz zu schweigen davon, dass sie für jeden möglichen Anbieter neu implementiert werden muss! Als bessere Lösung wurde die Unterstützung in ein eigenes Schnittstellenmodell ausgelagert, z. B. kubernetes/cloud-provider, das von mehreren Projekten oder Anbietern implementiert werden kann. Dies minimiert nicht nur den Wildwuchs in der Kubernetes-Codebasis, sondern ermöglicht auch die Verwaltung der CPI-Funktionen außerhalb der Kubernetes-Kerncluster. Dazu gehören gängige Verfahren wie Upgrades oder das Patchen von Sicherheitslücken.

Heute gibt es mehrere Schnittstellen, die Anpassungen und zusätzliche Funktionen in Kubernetes ermöglichen. Im Folgenden findest du eine übersichtliche Liste, auf die wir in den Kapiteln von näher eingehen werden:

• Das Container Networking Interface (CNI) ermöglicht es Netzwerkanbietern zu definieren, wie sie Dinge von IPAM bis zum eigentlichen Paketrouting erledigen.

• Das Container Storage Interface (CSI) ermöglicht es Anbietern von Speicherung, Anfragen für Workloads innerhalb eines Clusters zu erfüllen. Es wird häufig für Technologien wie Ceph, vSAN und EBS eingesetzt.

• Das Container Runtime Interface (CRI) ermöglicht eine Vielzahl von Laufzeiten, darunter Docker, containerd und CRI-O. Es hat auch die Verbreitung weniger traditioneller Laufzeiten ermöglicht, wie z. B. Firecracker, das KVM nutzt, um eine minimale VM bereitzustellen.

• Das Service Mesh Interface (SMI) ist eine der neueren Schnittstellen für das Kubernetes-Ökosystem. Sie soll die Konsistenz bei der Definition von Dingen wie Verkehrsrichtlinien, Telemetrie und Management verbessern.

• Das Cloud-Provider Interface (CPI) ermöglicht es Anbietern wie VMware, AWS, Azure und anderen, Integrationspunkte für ihre Cloud-Dienste mit Kubernetes-Clustern zu schreiben.

• Die Open Container Initiative Runtime Spec. (OCI) standardisiert Container-Images und stellt sicher, dass ein Container-Image, das mit einem Tool erstellt wurde, in jeder OCI-kompatiblen Container-Laufzeitumgebung ausgeführt werden kann, wenn es den Anforderungen entspricht. Diese Spezifikation ist nicht direkt mit Kubernetes verknüpft, hat aber den Wunsch nach steckbaren Container-Runtimes (CRI) unterstützt.

Kubernetes zusammenfassen

Jetzt haben wir uns auf den Umfang von Kubernetes konzentriert. Es ist ein Container-Orchestrator mit ein paar zusätzlichen Funktionen hier und da. Außerdem kann es durch Plug-ins für Schnittstellen erweitert und angepasst werden. Kubernetes kann für viele Unternehmen, die eine elegante Lösung für den Betrieb ihrer Anwendungen suchen, eine wichtige Grundlage sein. Aber lass uns einen Schritt zurückgehen. Wenn wir die aktuellen Systeme, mit denen die Anwendungen in deinem Unternehmen laufen, durch Kubernetes ersetzen würden, wäre das dann genug? Für viele von uns steckt viel mehr in den Komponenten und Maschinen, die unsere aktuelle "Anwendungsplattform" ausmachen.

In der Vergangenheit haben wir viel Leid erlebt, wenn Unternehmen eine "Kubernetes"-Strategie verfolgen - oder wenn sie davon ausgehen, dass Kubernetes eine adäquate Antriebsfunktion für die Modernisierung ihrer Softwareentwicklung und -ausführung ist. Kubernetes ist eine Technologie, eine großartige Technologie, aber sie sollte nicht im Mittelpunkt stehen, wenn es darum geht, eine moderne Infrastruktur, Plattform und/oder Software zu entwickeln. Wir entschuldigen uns, wenn das offensichtlich erscheint, aber du wärst überrascht, wie viele leitende oder hochrangige Architekten, mit denen wir sprechen, glauben, dass Kubernetes allein die Antwort auf ihre Probleme ist, während sich ihre Probleme in Wirklichkeit um die Anwendungsbereitstellung, die Softwareentwicklung oder organisatorische/personelle Fragen drehen. Kubernetes ist am besten als ein Teil des Puzzles zu sehen, der es dir ermöglicht, Plattformen für deine Anwendungen bereitzustellen. Wir haben uns mit der Idee einer Anwendungsplattform beschäftigt, die wir als Nächstes untersuchen werden.

Anwendungsplattformen definieren

Auf unserem Weg zur Produktion ist es wichtig, dass wir die Idee einer Anwendungsplattform berücksichtigen. Wir definieren eine Anwendungsplattform als einen praktikablen Ort, um Arbeitslasten auszuführen. Wie bei den meisten Definitionen in diesem Buch ist auch hier die Art und Weise, wie dies erreicht wird, von Unternehmen zu Unternehmen unterschiedlich. Die angestrebten Ergebnisse sind vielfältig und für verschiedene Bereiche des Unternehmens wünschenswert, z. B. zufriedene Entwickler, geringere Betriebskosten und schnellere Rückkopplungsschleifen bei der Bereitstellung von Software, um nur einige zu nennen. Bei der Anwendungsplattform treffen wir oft auf die Schnittstelle zwischen Anwendungen und Infrastruktur. Aspekte wie die Entwicklererfahrung (devx) sind in diesem Bereich typischerweise ein wichtiger Grundsatz.

Anwendungsplattformen gibt es in vielen Formen und Größen. Einige abstrahieren die zugrundeliegenden Aspekte wie IaaS (z. B. AWS) oder den Orchestrator (z. B. Kubernetes) weitgehend. Heroku ist ein gutes Beispiel für dieses Modell. Damit kannst du ein Projekt, das in Sprachen wie Java, PHP oder Go geschrieben wurde, mit einem einzigen Befehl in die Produktion überführen. Neben deiner App laufen viele Plattformdienste, die du sonst selbst betreiben müsstest. Dazu gehören die Sammlung von Metriken, Datendienste und Continuous Delivery (CD). Außerdem kannst du damit hochverfügbare Workloads betreiben, die sich leicht skalieren lassen. Verwendet Heroku Kubernetes? Betreibt es seine eigenen Rechenzentren oder läuft es auf AWS? Wen interessiert das? Für Heroku-Nutzer sind diese Details nicht wichtig. Wichtig ist, dass sie diese Aufgaben an einen Anbieter oder eine Plattform delegieren können, damit die Entwickler mehr Zeit für die Lösung von Geschäftsproblemen haben. Dieser Ansatz ist nicht nur bei Cloud-Diensten zu finden. OpenShift von RedHat folgt einem ähnlichen Modell, bei dem Kubernetes eher ein Implementierungsdetail ist und Entwickler und Plattformbetreiber mit einer Reihe von Abstraktionen darüber interagieren.

Warum nicht hier aufhören? Wenn Plattformen wie Cloud Foundry, OpenShift und Heroku diese Probleme für uns gelöst haben, warum sich dann mit Kubernetes herumschlagen? Ein großer Kompromiss bei vielen vorgefertigten Anwendungsplattformen ist die Notwendigkeit, sich an ihre Weltsicht anzupassen. Indem du die Verantwortung für das zugrunde liegende System delegierst, nimmst du dir eine große Last von den Schultern. Wenn aber die Plattform bei Themen wie Service Discovery oder Secret Management nicht den Anforderungen deiner Organisation entspricht, hast du möglicherweise nicht die nötige Kontrolle, um dieses Problem zu lösen. Außerdem gibt es das Problem der Anbieter- oder Meinungsbindung. Mit den Abstraktionen kommen auch die Meinungen darüber, wie deine Anwendungen gestaltet, verpackt und eingesetzt werden sollten. Das bedeutet, dass der Wechsel zu einem anderen System nicht unbedingt trivial ist. Es ist zum Beispiel wesentlich einfacher, Arbeitslasten zwischen Google Kubernetes Engine (GKE) und Amazon Elastic Kubernetes Engine (EKS) zu verschieben als zwischen EKS und Cloud Foundry.

Das Spektrum an Ansätzen

An diesem Punkt ist klar, dass es mehrere Ansätze gibt, um eine erfolgreiche Anwendungsplattform zu schaffen. Gehen wir zur Veranschaulichung von einigen großen Annahmen aus und bewerten wir die theoretischen Kompromisse zwischen den Ansätzen. Für ein durchschnittliches Unternehmen, mit dem wir arbeiten, z. B. ein mittleres bis großes Unternehmen, zeigt Abbildung 1-3 eine willkürliche Bewertung der Ansätze.

Im Quadranten unten links sehen wir die Bereitstellung von Kubernetes-Clustern selbst, die einen relativ geringen technischen Aufwand erfordert, vor allem wenn verwaltete Dienste wie EKS die Kontrollebene für dich übernehmen. Diese sind weniger produktionsbereit, weil die meisten Unternehmen feststellen werden, dass mehr Arbeit auf Kubernetes zu leisten ist. Es gibt jedoch Anwendungsfälle, wie z. B. Teams, die dedizierte Cluster für ihre Workloads nutzen, für die Kubernetes ausreichen kann.

Abbildung 1-3. Die Vielzahl an Optionen, die Entwicklern eine Anwendungsplattform bieten.

Unten rechts befinden sich die etablierteren Plattformen, die ein durchgängiges Entwicklererlebnis bieten. Cloud Foundry ist ein großartiges Beispiel für ein Projekt, das viele Probleme der Anwendungsplattform löst. Beim Betrieb von Software in Cloud Foundry geht es eher darum, sicherzustellen, dass die Software in ihre Ansichten passt. Bei OpenShift hingegen, das für die meisten weitaus produktiver ist als Kubernetes, gibt es mehr Entscheidungspunkte und Überlegungen, wie du es einrichten kannst. Ist diese Flexibilität ein Vorteil oder ein Ärgernis? Das ist eine wichtige Überlegung für dich.

Oben rechts schließlich haben wir den Aufbau einer Anwendungsplattform auf Kubernetes. Im Vergleich zu den anderen ist dies zweifelsohne der größte technische Aufwand, zumindest aus Sicht der Plattform. Wenn du jedoch die Erweiterbarkeit von Kubernetes nutzt, kannst du etwas schaffen, das auf deine Entwickler-, Infrastruktur- und Geschäftsanforderungen abgestimmt ist.

Anpassung der organisatorischen Anforderungen an die Bedürfnisse des Unternehmens

Was in dem Diagramm in Abbildung 1-3 fehlt, ist eine dritte Dimension, eine Z-Achse, die zeigt, wie gut der Ansatz auf deine Anforderungen abgestimmt ist. Schauen wir uns eine andere visuelle Darstellung an. Abbildung 1-4 zeigt, wie dies aussehen könnte, wenn man die Ausrichtung der Plattform auf die Bedürfnisse des Unternehmens betrachtet.

Abbildung 1-4. Die zusätzliche Komplexität der Anpassung dieser Optionen an deine organisatorischen Bedürfnisse ist die Z-Achse.

In Bezug auf die Anforderungen, Funktionen und Verhaltensweisen, die du von einer Plattform erwartest, ist der Aufbau einer Plattform fast immer am besten geeignet. Oder zumindest am ehesten in der Lage, sich anzupassen. Das liegt daran, dass du alles bauen kannst! Wenn du Heroku intern auf Kubernetes neu implementieren möchtest, ist das mit kleinen Anpassungen der Funktionen technisch möglich. Allerdings solltest du das Kosten-Nutzen-Verhältnis mit den anderen Achsen (x und y) abwägen. Machen wir diese Übung konkreter, indem wir die folgenden Anforderungen an eine Plattform der nächsten Generation betrachten:

• Die Vorschriften verlangen, dass du hauptsächlich vor Ort arbeitest

• Sie müssen Ihre Baremetal-Flotte zusammen mit Ihrem vSphere-aktiviertenRechenzentrum unterstützen

• die wachsende Nachfrage von Entwicklern nachContaineranwendungen unterstützen wollen

• Du brauchst Wege, um Self-Service-API-Mechanismen zu entwickeln, die dich von der "ticketbasierten" Infrastrukturbereitstellung wegbringen.

• Sicherstellen wollen, dass die APIs, auf denen du aufbaust, herstellerunabhängig sind und nicht zu einem Lock-in führen, weil es dich in der Vergangenheit Millionen gekostet hat, diese Art vonSystemen abzulösen

• die bereit sind, für den Enterprise-Support für eine Vielzahl von Produkten im Stack zu zahlen, aber nicht bereit sind, sich auf Modelle festzulegen, bei denen der gesamte Stack pro Knoten, Core oder Anwendungsinstanz lizenziert wird

Wir müssen unseren technischen Reifegrad, unsere Bereitschaft, Teams aufzubauen und zu befähigen, und die verfügbaren Ressourcen kennen, um zu entscheiden, ob der Aufbau einer Anwendungsplattform ein sinnvolles Unterfangen ist.

Anwendungsplattformen zusammenfassen

Zugegeben, was eine Anwendungsplattform ist, bleibt ziemlich grau. Wir haben uns auf eine Reihe von Plattformen konzentriert, von denen wir glauben, dass sie den Teams eine Erfahrung bieten, die weit über die reine Workload-Orchestrierung hinausgeht. Wir haben auch dargelegt, dass Kubernetes angepasst und erweitert werden kann, um ähnliche Ergebnisse zu erzielen. Wenn wir unsere Überlegungen über die Frage "Wie bekomme ich Kubernetes?" hinaus erweitern und uns mit Fragen wie "Wie sieht der aktuelle Entwicklungsworkflow, die Probleme und Wünsche der Entwickler aus?" beschäftigen, werden Plattform- und Infrastrukturteams mit dem, was sie aufbauen, erfolgreicher sein. Wenn du dich auf Letzteres konzentrierst, ist es viel wahrscheinlicher, dass du den richtigen Weg zur Produktion einschlägst und eine nicht triviale Akzeptanz erreichst. Letztendlich wollen wir die Anforderungen an die Infrastruktur, die Sicherheit und die Entwickler erfüllen, um sicherzustellen, dass unsere Kunden - in der Regel Entwickler - eine Lösung erhalten, die ihren Bedürfnissen entspricht. Oftmals wollen wir nicht einfach eine "mächtige" Engine anbieten, auf der jeder Entwickler seine eigene Plattform aufbauen muss, wie in Abbildung 1-5 scherzhaft dargestellt.

Abbildung 1-5. Wenn Entwickler ein durchgängiges Erlebnis wünschen (z. B. ein fahrbares Auto), dürfen sie nicht erwarten, dass ein Motor ohne Rahmen, Räder und mehr ausreicht.

Aufbau von Anwendungsplattformen auf Kubernetes

Jetzt haben wir Kubernetes als ein Teil des Puzzles auf unserem Weg zur Produktion identifiziert. Da liegt die Frage nahe: "Fehlt Kubernetes dann nicht einfach etwas?" Der Grundsatz der Unix-Philosophie "Jedes Programm soll nur eine Sache gut machen" ist ein überzeugendes Ziel für das Kubernetes-Projekt. Wir glauben, dass die besten Funktionen von Kubernetes die sind, die es nicht hat! Vor allem, nachdem wir mit Einheitsplattformen, die versuchen, alle Probleme der Welt für dich zu lösen, verbrannt wurden. Kubernetes hat sich auf brillante Weise darauf konzentriert, ein großartiger Orchestrator zu sein und gleichzeitig klare Schnittstellen zu definieren, auf denen es aufgebaut werden kann. Das kann man mit dem Fundament eines Hauses vergleichen.

Ein gutes Fundament sollte strukturell solide sein, darauf gebaut werden können und geeignete Schnittstellen für die Verlegung von Versorgungsleitungen zum Haus bieten. Ein Fundament allein ist zwar wichtig, aber es ist selten ein bewohnbarer Ort für unsere Anwendungen. Normalerweise brauchen wir eine Art Zuhause, das auf dem Fundament steht. Bevor wir uns mit dem Aufbau auf einem Fundament wie Kubernetes befassen, betrachten wir eine bereits eingerichtete Wohnung, wie in Abbildung 1-6 dargestellt.

Abbildung 1-6. Eine Wohnung, die bezugsfertig ist. Ähnlich wie bei Plattform-as-a-Service-Angeboten wie Heroku. Illustration von Jessica Appelbaum.

Diese Option ist, ähnlich wie bei unseren Beispielen wie Heroku, ohne zusätzliche Arbeit nutzbar. Es gibt sicherlich Möglichkeiten, die Erfahrung im Inneren anzupassen, aber viele Bedenken sind für uns gelöst. Solange wir mit dem Mietpreis einverstanden sind und bereit sind, uns an die nicht verhandelbaren Meinungen zu halten, können wir vom ersten Tag an erfolgreich sein.

Um auf Kubernetes zurückzukommen, das wir mit einem Fundament verglichen haben, können wir nun versuchen, ein bewohnbares Haus darauf zu bauen, wie in Abbildung 1-7 dargestellt.

Abbildung 1-7. Ein Haus bauen. Ähnlich wie beim Aufbau einer Anwendungsplattform, für die Kubernetes die Grundlage ist. Illustration von Jessica Appelbaum.

Zu den Kosten für Planung, Entwicklung und Wartung können wir bemerkenswerte Plattformen bauen, um Workloads in Unternehmen auszuführen. Das bedeutet, dass wir die vollständige Kontrolle über jedes Element des Outputs haben. Das Haus kann und sollte auf die Bedürfnisse der zukünftigen Mieter (unserer Anwendungen) zugeschnitten sein. Schauen wir uns nun die verschiedenen Ebenen und Überlegungen an, die dies möglich machen.

Von ganz unten anfangen

Zuerst müssen wir ganz unten anfangen, bei der Technologie, die Kubernetes erwartet. In der Regel handelt es sich dabei um ein Rechenzentrum oder einen Cloud-Provider, der Rechenleistung, Speicherung und Netzwerke zur Verfügung stellt. Einmal eingerichtet, kann Kubernetes darauf gestartet werden. Innerhalb weniger Minuten kannst du einen Cluster auf der zugrunde liegenden Infrastruktur betreiben. Es gibt mehrere Möglichkeiten, Kubernetes zu booten, und wir werden sie in Kapitel 2 ausführlich behandeln.

Ausgehend von der Existenz von Kubernetes-Clustern müssen wir als Nächstes einen konzeptionellen Fluss betrachten, um zu bestimmen, was wir darauf aufbauen sollen. Die wichtigsten Knotenpunkte sind in Abbildung 1-8 dargestellt.

Abbildung 1-8. Ein Ablauf, den unsere Teams auf ihrem Weg zur Produktion mitKubernetes durchlaufen können.

Wenn es Kubernetes gibt, kannst du damit rechnen, dass du schnell Fragen wie diese bekommst:

• "Wie stelle ich sicher, dass der Datenverkehr von Workload zu Workload vollständig verschlüsselt ist?

• "Wie stelle ich sicher, dass der ausgehende Datenverkehr über ein Gateway läuft, das eine einheitliche Quell-CIDR garantiert?

• "Wie stelle ich Self-Service-Tracing und Dashboards für Anwendungen bereit?"

• "Wie kann ich Entwicklerinnen und Entwickler an Bord lassen, ohne dass sie zu Kubernetes-Experten werden?"

Diese Liste kann endlos sein. Oft müssen wir entscheiden, welche Anforderungen wir auf der Plattformebene und welche wir auf der Anwendungsebene lösen wollen. Der Schlüssel dazu ist, die bestehenden Arbeitsabläufe genau zu verstehen, um sicherzustellen, dass das, was wir entwickeln, den aktuellen Erwartungen entspricht. Wenn wir diese Funktionen nicht erfüllen können, welche Auswirkungen hat das auf die Entwicklungsteams? Als Nächstes können wir mit dem Aufbau einer Plattform auf Kubernetes beginnen. Dabei ist es wichtig, dass wir mit Entwicklungsteams zusammenarbeiten, die bereit sind, frühzeitig einzusteigen und die Erfahrungen zu verstehen, um auf der Grundlage von schnellem Feedback fundierte Entscheidungen zu treffen. Nach dem Erreichen der Produktion sollte dieser Fluss nicht aufhören. Die Plattformteams sollten nicht erwarten, dass die gelieferte Umgebung eine statische Umgebung ist, die die Entwickler/innen jahrzehntelang nutzen werden. Um erfolgreich zu sein, müssen wir uns ständig mit unseren Entwicklungsgruppen austauschen, um zu verstehen, wo es Probleme gibt oder wo Funktionen fehlen, die die Entwicklungsgeschwindigkeit erhöhen könnten. Ein guter Anfang ist die Überlegung, welches Maß an Interaktion mit Kubernetes wir von unseren Entwicklern erwarten sollten. Das ist die Idee, wie viel oder wie wenig wir abstrahieren sollten.

Das Spektrum der Abstraktion

In der Vergangenheit haben wir oft Sprüche gehört wie: "Wenn deine Anwendungsentwickler wissen, dass sie Kubernetes benutzen, hast du fehlgeschlagen!" Das kann ein guter Ansatz sein, um die Interaktion mit Kubernetes zu betrachten, vor allem, wenn du Produkte oder Dienstleistungen entwickelst, bei denen die zugrunde liegende Orchestrierungstechnologie für den Endnutzer bedeutungslos ist. Vielleicht baust du ein Datenbankmanagementsystem (DBMS), das mehrere Datenbanktechnologien unterstützt. Ob Shards oder Instanzen einer Datenbank über Kubernetes, Bosh oder Mesos laufen, spielt für deine Entwickler/innen wahrscheinlich keine Rolle! Es ist jedoch gefährlich, diese Philosophie pauschal aus einem Tweet in die Erfolgskriterien deines Teams zu übernehmen. Wenn wir Teile von Kubernetes überlagern und Plattformdienste aufbauen, um unsere Kunden besser bedienen zu können, müssen wir viele Entscheidungen treffen, um zu bestimmen, wie angemessene Abstraktionen aussehen. Abbildung 1-9 veranschaulicht dieses Spektrum.

Abbildung 1-9. Die verschiedenen Enden des Spektrums. Angefangen bei der Bereitstellung eines eigenen Kubernetes-Clusters für jedes Team bis hin zur vollständigen Abstraktion von Kubernetes von deinen Nutzern über ein Platform-as-a-Service (PaaS)-Angebot.

Das kann eine Frage sein, die Plattformteams nachts wach hält. Die Bereitstellung von Abstraktionen ist ein großer Vorteil. Projekte wie Cloud Foundry bieten ein umfassendes Entwicklererlebnis - ein Beispiel dafür ist, dass wir im Rahmen eines einzigen cf push eine Anwendung erstellen, bereitstellen und für den Produktionsverkehr nutzen können. Da dieses Ziel und diese Erfahrung im Vordergrund stehen, gehen wir davon aus, dass Cloud Foundry die Unterstützung für Kubernetes weiter ausbaut und dieser Übergang eher ein Implementierungsdetail als eine Änderung des Funktionsumfangs ist. Ein weiteres Muster, das wir sehen, ist der Wunsch, mehr als Kubernetes in einem Unternehmen anzubieten, ohne dass die Entwickler explizit zwischen verschiedenen Technologien wählen müssen. Einige Unternehmen haben zum Beispiel einen Mesos- und einen Kubernetes-Footprint. Sie bauen dann eine Abstraktion auf, die eine transparente Auswahl von Workloads ermöglicht, ohne die Anwendungsentwickler damit zu belasten. Außerdem verhindern sie so, dass sie sich an eine bestimmte Technologie binden. Ein Kompromiss bei diesem Ansatz besteht darin, Abstraktionen auf zwei Systemen aufzubauen, die unterschiedlich funktionieren. Dies erfordert einen erheblichen technischen Aufwand und Reifegrad. Außerdem werden die Entwickler zwar von der Last befreit, mit Kubernetes oder Mesos umgehen zu können, aber sie müssen stattdessen wissen, wie sie ein abstrahiertes, unternehmensspezifisches System nutzen können. In der modernen Ära von Open Source sind Entwickler/innen aus allen Bereichen weniger begeistert davon, Systeme zu erlernen, die sich nicht zwischen verschiedenen Unternehmen übertragen lassen. Ein weiterer Fallstrick, den wir beobachtet haben, ist die Besessenheit von Abstraktion, die dazu führt, dass wichtige Funktionen von Kubernetes nicht offengelegt werden können. Mit der Zeit kann dies zu einem Katz-und-Maus-Spiel werden, bei dem du versuchst, mit dem Projekt Schritt zu halten und möglicherweise deine Abstraktion so kompliziert wie das System zu machen, das sie abstrahiert.

Am anderen Ende des Spektrums stehen Plattformgruppen, die den Entwicklungsteams Self-Service-Cluster anbieten wollen. Auch das kann ein tolles Modell sein. Allerdings liegt die Verantwortung für die Kubernetes-Reife bei den Entwicklungsteams. Verstehen sie, wie Deployments, ReplicaSets, Pods, Services und Ingress APIs funktionieren? Haben sie ein Gespür dafür, wie sie Millicpus einstellen und wie Overcommit von Ressourcen funktioniert? Wissen sie, wie man sicherstellt, dass Workloads, die mit mehr als einem Replikat konfiguriert sind, immer auf verschiedenen Knoten geplant werden? Wenn ja, ist dies die perfekte Gelegenheit, um das Over-Engineering einer Anwendungsplattform zu vermeiden und stattdessen die Anwendungsteams von der Kubernetes-Schicht aufwärts arbeiten zu lassen.

Dieses Modell, bei dem die Entwicklungsteams ihre eigenen Cluster besitzen, ist etwas weniger verbreitet. Selbst wenn ein Team über Kubernetes-Kenntnisse verfügt, ist es unwahrscheinlich, dass es sich die Zeit für die Bereitstellung von Funktionen nehmen möchte, um herauszufinden, wie es den Lebenszyklus seines Kubernetes-Clusters verwalten kann, wenn es Zeit für ein Upgrade ist. Kubernetes bietet so viele Möglichkeiten, aber für viele Entwicklungsteams ist es unrealistisch zu erwarten, dass sie neben der Softwareentwicklung auch noch Kubernetes-Experten werden. Wie du in den nächsten Kapiteln sehen wirst, muss Abstraktion keine binäre Entscheidung sein. An verschiedenen Punkten können wir fundierte Entscheidungen darüber treffen, wo Abstraktionen sinnvoll sind. Wir werden herausfinden, wo wir den Entwicklern das richtige Maß an Flexibilität bieten und gleichzeitig ihre Arbeitsabläufe vereinfachen können.

Festlegen der Plattformdienste

Wenn du auf Kubernetes aufbaust, ist es wichtig zu entscheiden, welche Funktionen in die Plattform integriert und welche auf der Anwendungsebene gelöst werden sollten. In der Regel ist dies etwas, das von Fall zu Fall beurteilt werden sollte. Nehmen wir zum Beispiel an, dass jeder Java-Microservice eine Bibliothek implementiert, die gegenseitiges TLS (mTLS) zwischen den Diensten ermöglicht. Dies bietet Anwendungen ein Konstrukt für die Identität von Arbeitslasten und die Verschlüsselung von Daten über das Netzwerk. Als Plattformteam müssen wir diese Nutzung genau verstehen, um zu entscheiden, ob wir sie auf Plattformebene anbieten oder implementieren sollten. Viele Teams versuchen, dieses Problem zu lösen, indem sie eine Technologie namens "Service Mesh" in den Cluster implementieren. Wenn wir uns mit Kompromissen befassen, kommen wir zu folgenden Überlegungen.

Vorteile der Einführung eines Dienstnetzes:

• Java-Anwendungen müssen keine Bibliotheken mehr bündeln, um mTLS zu ermöglichen.

• Nicht-Java-Anwendungen können an demselben mTLS/Verschlüsselungssystem teilnehmen.

• Geringere Komplexität für die Anwendungsteams, die es zu lösen gilt.

Nachteile der Einführung eines Servicenetzes:

• Der Betrieb eines Servicenetzes ist keine triviale Aufgabe. Es ist ein weiteres verteiltes System mit einer hohen Betriebskomplexität.

• Service Meshes führen oft Funktionen ein, die weit über Identität und Verschlüsselung hinausgehen.

• Die Identitäts-API des Netzes lässt sich möglicherweise nicht mit demselben Backend-System integrieren, das von den bestehenden Anwendungen verwendet wird.

Wenn wir diese Vor- und Nachteile abwägen, können wir zu dem Schluss kommen, ob es sich lohnt, dieses Problem auf Plattformebene zu lösen. Entscheidend ist, dass wir nicht jedes Anwendungsproblem in unserer neuen Plattform lösen müssen und dies auch nicht anstreben sollten. Auch das ist eine Gratwanderung, die du bei der Lektüre der vielen Kapitel in diesem Buch berücksichtigen musst. Es werden verschiedene Empfehlungen, bewährte Methoden und Anleitungen gegeben, aber wie bei allem, solltest du sie anhand der Prioritäten deines Unternehmens bewerten.

Die Bausteine

Zum Abschluss dieses Kapitels wollen wir die wichtigsten Bausteine, die dir beim Aufbau einer Plattform zur Verfügung stehen, konkret benennen. Dazu gehören alle grundlegenden Komponenten bis hin zu optionalen Plattformdiensten, die du implementieren möchtest.

Die Komponenten in Abbildung 1-10 sind für verschiedene Zielgruppen von unterschiedlicher Bedeutung.

Abbildung 1-10. Viele der wichtigsten Bausteine, die zur Einrichtung einerAnwendungsplattform gehören.

Einige Komponenten wie das Containernetzwerk und die Container-Runtime sind für jeden Cluster erforderlich, denn ein Kubernetes-Cluster, der keine Workloads ausführen oder mit ihnen kommunizieren kann, wäre nicht sehr erfolgreich. Bei einigen Komponenten wirst du wahrscheinlich feststellen, dass es Unterschiede gibt, ob sie überhaupt implementiert werden sollten. Zum Beispiel ist die Verwaltung von Geheimnissen vielleicht kein Plattformdienst, den du implementieren willst, wenn die Anwendungen ihre Geheimnisse bereits von einer externenLösung zur Verwaltung von Geheimnissen beziehen.

Einige Bereiche, wie z. B. die Sicherheit, fehlen eindeutig in Abbildung 1-10. Das liegt daran, dass Sicherheit keine Funktion ist, sondern eher ein Ergebnis der Art und Weise, wie du alles von der IAAS-Schicht aufwärts implementierst. Sehen wir uns diese Schlüsselbereiche auf einer hohen Ebene an, wobei wir im Laufe des Buches noch viel tiefer in sie eintauchen werden.

IAAS/Datacenter und Kubernetes

IAAS/Datacenter und Kubernetes bilden die grundlegende Schicht, die wir in diesem Kapitel schon oft erwähnt haben. Wir wollen diese Schicht nicht trivialisieren, denn ihre Stabilität steht in direktem Zusammenhang mit der unserer Plattform. In modernen Umgebungen verbringen wir jedoch viel weniger Zeit damit, die Architektur unserer Racks zu bestimmen, um Kubernetes zu unterstützen, und viel mehr Zeit damit, zwischen einer Vielzahl von Bereitstellungsoptionen und Topologien zu entscheiden. Im Wesentlichen müssen wir entscheiden, wie wir Kubernetes-Cluster bereitstellen und verfügbar machen wollen.

Container-Laufzeit

Die Container-Laufzeitumgebung erleichtert das Lebenszyklusmanagement unserer Workloads auf jedem Host. Dies wird in der Regel mit einer Technologie umgesetzt, die Container verwalten kann, z. B. CRI-O, containerd und Docker. Die Möglichkeit, zwischen diesen verschiedenen Implementierungen zu wählen, verdanken wir dem Container Runtime Interface (CRI). Neben diesen gängigen Beispielen gibt es spezialisierte Laufzeiten, die besondere Anforderungen erfüllen, wie z. B. den Wunsch, einen Workload in einer Micro-VM auszuführen.

Container-Vernetzung

Die von uns gewählte Container-Vernetzung richtet sich in der Regel an das IP-Adressen-Management (IPAM) von Workloads und an Routing-Protokolle, die die Kommunikation erleichtern. Zu den gängigen Technologien gehören Calico oder Cilium, die auf das Container Networking Interface (CNI) zurückgehen. Durch das Einbinden einer Container-Netzwerktechnologie in den Cluster kann das Kubelet IP-Adressen für die von ihm gestarteten Workloads anfordern. Einige Plug-ins gehen so weit, dass sie Dienstabstraktionen auf dem Pod-Netzwerk implementieren.

Integration der Speicherung

Die Speicherintegration deckt ab, was wir tun, wenn die Speicherung auf dem Host einfach nicht ausreicht. In modernen Kubernetes-Systemen übertragen immer mehr Unternehmen zustandsabhängige Arbeitslasten auf ihre Cluster. Diese Workloads erfordern ein gewisses Maß an Sicherheit, dass der Status auch bei Anwendungsausfällen oder Umplanungen erhalten bleibt. Die Speicherung kann über gängige Systeme wie vSAN, EBS, Ceph und viele andere erfolgen. Die Möglichkeit, zwischen verschiedenen Backends zu wählen, wird durch das Container Storage Interface (CSI) erleichtert. Ähnlich wie bei CNI und CRI sind wir in der Lage, ein Plug-in in unserem Cluster einzusetzen, das den von der Anwendung angeforderten Speicherplatz bereitstellen kann.

Service-Routing

Service-Routing ist die Erleichterung des Datenverkehrs zu und von den Workloads, die wir in Kubernetes ausführen. Kubernetes bietet eine Service-API, die aber in der Regel nur ein Sprungbrett für die Unterstützung von funktionsreicheren Routing-Funktionen ist. Das Service-Routing baut auf dem Container-Networking auf und schafft übergeordnete Funktionen wie Layer-7-Routing, Verkehrsmuster und vieles mehr. In vielen Fällen werden diese Funktionen mit einer Technologie namens Ingress Controller implementiert. Auf der tieferen Ebene des Service-Routings gibt es eine Vielzahl von Service-Meshes. Diese Technologie ist voll ausgestattet mit Mechanismen wie Service-to-Service mTLS, Beobachtbarkeit und Unterstützung für Anwendungsmechanismen wie CircuitBreaking.

Geheimes Management

Secret Management umfasst die Verwaltung und Verteilung sensibler Daten, die von Workloads benötigt werden. Kubernetes bietet eine Secrets-API, über die mit sensiblen Daten interagiert werden kann. Allerdings verfügen viele Cluster von Haus aus nicht über die von vielen Unternehmen geforderten robusten Funktionen zur Verwaltung und Verschlüsselung von Geheimnissen. Hier geht es vor allem um Defense in Depth. Auf einer einfachen Ebene können wir sicherstellen, dass die Daten verschlüsselt werden, bevor sie gespeichert werden (Verschlüsselung im Ruhezustand). Auf einer fortgeschritteneren Ebene können wir die Integration mit verschiedenen Technologien zur Verwaltung von Geheimnissen, wie Vault oder Cyberark, anbieten.

Identität

Die Identität umfasst die Authentifizierung von Menschen und Workloads. Eine häufige Frage, die sich Cluster-Administratoren zu Beginn stellen, ist die nach der Authentifizierung von Benutzern gegenüber einem System wie LDAP oder dem IAM-System eines Cloud-Providers. Aber nicht nur Menschen, sondern auch Workloads möchten sich identifizieren, um vertrauensfreie Netzwerkmodelle zu unterstützen, bei denen die Identifizierung von Workloads viel schwieriger ist. Dies kann durch die Einbindung eines Identitätsanbieters und die Verwendung von Mechanismen wie mTLS zur Verifizierung eines Workloads erleichtert werden.

Autorisierung/Zulassungskontrolle

Die Autorisierung ist der nächste Schritt, nachdem wir die Identität eines Menschen oder eines Workloads überprüfen können. Wenn Nutzer oder Workloads mit dem API-Server interagieren, wie gewähren oder verweigern wir ihnen den Zugriff auf Ressourcen? Kubernetes bietet eine RBAC-Funktion mit Kontrollen auf Ressourcen-/Verb-Ebene, aber wie sieht es mit einer benutzerdefinierten Logik für die Autorisierung innerhalb unserer Organisation aus? Bei der Zugangskontrolle können wir einen Schritt weiter gehen, indem wir eine Validierungslogik entwickeln, die von einer statischen Liste von Regeln bis hin zum dynamischen Aufruf anderer Systeme reichen kann, um die korrekte Autorisierungsantwort zu bestimmen.

Software-Lieferkette

Die Software-Lieferkette umfasst den gesamten Lebenszyklus der Software vom Quellcode bis zur Laufzeit. Dazu gehören auch die gemeinsamen Anliegen rund um Continuous Integration (CI) und Continuous Delivery (CD). Oft sind die Pipelines, die sie in diesen Systemen einrichten, der Hauptinteraktionspunkt der Entwickler. Wenn die CI/CD-Systeme gut mit Kubernetes funktionieren, kann das für den Erfolg deiner Plattform entscheidend sein. Neben CI/CD geht es auch um die Speicherung von Artefakten, ihre Sicherheit im Hinblick auf Schwachstellen und die Gewährleistung der Integrität der Images, die in deinem Cluster ausgeführt werden.

Beobachtbarkeit

Beobachtbarkeit ist der Oberbegriff für alle Dinge, die uns helfen zu verstehen, was mit unseren Clustern passiert. Das gilt sowohl für die System- als auch für die Anwendungsebene. Normalerweise denken wir, dass Beobachtbarkeit drei Schlüsselbereiche umfasst. Das sind Logs, Metriken und Tracing. Bei der Protokollierung werden die Protokolldaten von den Workloads auf dem Host an ein Backend-Zielsystem weitergeleitet. Von diesem System aus können wir die Protokolle in einer konsumierbaren Weise zusammenfassen und analysieren. Bei den Metriken geht es um die Erfassung von Daten, die einen bestimmten Zustand zu einem bestimmten Zeitpunkt darstellen. Oft werden diese Daten in einem System zur Analyse zusammengefasst oder ausgewertet. Tracing ist vor allem deshalb so beliebt, weil wir die Interaktionen zwischen den verschiedenen Diensten, aus denen unsere Anwendungen bestehen, verstehen wollen. Die gesammelten Trace-Daten können in ein aggregiertes System eingespeist werden, in dem die Lebensdauer einer Anfrage oder einer Antwort über eine Art Kontext- oder Korrelations-ID angezeigt wird.

Abstraktionen für Entwickler

Entwicklerabstraktionen sind die Werkzeuge und Plattformdienste, die wir bereitstellen, damit Entwickler mit unserer Plattform erfolgreich sind. Wie bereits erwähnt, gibt es ein breites Spektrum an Abstraktionsansätzen. Einige Unternehmen entscheiden sich dafür, die Nutzung von Kubernetes für die Entwicklungsteams völlig transparent zu machen. Andere Unternehmen entscheiden sich dafür, viele der mächtigen Knöpfe, die Kubernetes bietet, offenzulegen und jedem Entwickler viel Flexibilität zu geben. Die Lösungen konzentrieren sich auch auf das Onboarding der Entwickler und stellen sicher, dass sie Zugang und sichere Kontrolle über eine Umgebung erhalten, die sie in der Plattform nutzen können.

Zusammenfassung

In diesem Kapitel haben wir uns mit Ideen beschäftigt, die Kubernetes, Anwendungsplattformen und sogar den Aufbau von Anwendungsplattformen auf Kubernetes umfassen. Wir hoffen, dass wir dich zum Nachdenken über die verschiedenen Bereiche angeregt haben, in die du einsteigen kannst, um besser zu verstehen, wie du auf diesem großartigen Workload-Orchestrator aufbauen kannst. Im weiteren Verlauf des Buches werden wir in diese Schlüsselbereiche eintauchen und dir Einblicke, Anekdoten und Empfehlungen geben, die deine Sichtweise auf den Aufbau von Plattformen erweitern. Lass uns loslegen und den Weg zur Produktion einschlagen!