Architektonische Anwendungen für Kubernetes

Das Entwerfen und Ausführen von Anwendungen mit Blick auf Skalierbarkeit, Portabilität und Robustheit kann eine Herausforderung sein, insbesondere wenn die Systemkomplexität zunimmt. Die Architektur einer Anwendung oder eines Systems hat erhebliche Auswirkungen darauf, wie sie ausgeführt werden muss, was sie von ihrer Umgebung erwartet und wie eng sie mit verwandten Komponenten verbunden ist. Das Befolgen bestimmter Muster während der Entwurfsphase und das Befolgen bestimmter Betriebspraktiken können dazu beitragen, einige der häufigsten Probleme zu beheben, mit denen Anwendungen bei der Ausführung in stark verteilten Umgebungen konfrontiert sind.

Während Software-Entwurfsmuster und Entwicklungsmethoden Anwendungen mit den richtigen Skalierungseigenschaften erzeugen können, beeinflussen die Infrastruktur und die Umgebung den Betrieb des bereitgestellten Systems. Technologien wieDocker undKubernetes helfen Teams, Software zu verpacken und dann auf Plattformen verteilter Computer zu verteilen, bereitzustellen und zu skalieren. Wenn Sie lernen, wie Sie die Leistung dieser Tools optimal nutzen können, können Sie Anwendungen flexibler, kontrollierter und reaktionsschneller verwalten.

In diesem Handbuch werden einige der Prinzipien und Muster erläutert, die Sie möglicherweise anwenden möchten, um die Skalierung und Verwaltung Ihrer Workloads auf Kubernetes zu unterstützen. Während Kubernetes viele Arten von Workloads ausführen kann, können die von Ihnen getroffenen Entscheidungen die Benutzerfreundlichkeit und die bei der Bereitstellung verfügbaren Möglichkeiten beeinträchtigen. Die Art und Weise, wie Sie Ihre Anwendungen entwerfen und erstellen, Ihre Dienste in Containern verpacken und das Lebenszyklusmanagement sowie das Verhalten in Kubernetes konfigurieren, kann Ihre Erfahrung beeinflussen.

Bei der Erstellung von Software wirken sich viele Anforderungen auf die Muster und die Architektur aus, die Sie verwenden. Bei Kubernetes ist einer der wichtigsten Faktoren die Fähigkeit zuscale horizontally, die Anzahl der identischen Kopien Ihrer Anwendung anzupassen, um die Last zu verteilen und die Verfügbarkeit zu erhöhen. Dies ist eine Alternative zuvertical scaling, bei der versucht wird, dieselben Faktoren durch Bereitstellung auf Computern mit mehr oder weniger Ressourcen zu manipulieren.

Insbesondere istmicroservices ein Software-Entwurfsmuster, das sich gut für skalierbare Bereitstellungen in Clustern eignet. Entwickler erstellen kleine, zusammensetzbare Anwendungen, die über gut definierte REST-APIs über das Netzwerk kommunizieren, anstatt über größere Verbundprogramme, die über interne Programmiermechanismen kommunizieren. Durch die Zerlegung monolithischer Anwendungen in einzelne Einzelkomponenten kann jede Funktion unabhängig voneinander skaliert werden. Ein Großteil der normalerweise auf Anwendungsebene vorhandenen Komplexität und Zusammensetzung wird in den Betriebsbereich übertragen, wo sie von Plattformen wie Kubernetes verwaltet werden kann.

Über bestimmte Softwaremuster hinaus werdencloud native-Anwendungen unter Berücksichtigung einiger zusätzlicher Überlegungen entwickelt. Native Cloud-Anwendungen sind Programme, die einem Muster der Microservices-Architektur mit integrierter Ausfallsicherheit, Beobachtbarkeit und Verwaltungsfunktionen folgen, um sich an die von Clusterplattformen in der Cloud bereitgestellte Umgebung anzupassen.

Cloud-native Anwendungen werden beispielsweise mit Integritätsberichtsmetriken erstellt, um der Plattform die Verwaltung von Lebenszyklusereignissen zu ermöglichen, wenn eine Instanz fehlerhaft wird. Sie erstellen robuste Telemetriedaten (und stellen sie für den Export zur Verfügung), um Bediener auf Probleme aufmerksam zu machen und fundierte Entscheidungen zu treffen. Anwendungen sind so konzipiert, dass sie regelmäßige Neustarts und Fehler, Änderungen der Back-End-Verfügbarkeit und hohe Auslastung verarbeiten können, ohne Daten zu beschädigen oder nicht mehr zu reagieren.

Kubernetes verwendet Container, um isolierte, gepackte Anwendungen auf seinen Clusterknoten auszuführen. Um auf Kubernetes ausgeführt zu werden, müssen Ihre Anwendungen in einem oder mehreren Container-Images gekapselt und mit einer Container-Laufzeitumgebung wie Docker ausgeführt werden. Die Containerisierung Ihrer Komponenten ist zwar eine Voraussetzung für Kubernetes, hilft aber auch dabei, viele der Prinzipien der oben diskutierten Zwölf-Faktor-App-Methodik zu bekräftigen, was eine einfache Skalierung und Verwaltung ermöglicht.

Beispielsweise stellen Container eine Isolation zwischen der Anwendungsumgebung und dem externen Hostsystem bereit, unterstützen einen vernetzten, serviceorientierten Ansatz für die Kommunikation zwischen Anwendungen und nehmen die Konfiguration in der Regel über Umgebungsvariablen vor und legen Protokolle offen, die in Standardfehler und Standardausgabe geschrieben wurden. Die Container selbst fördern die prozessbasierte Parallelität und tragen zur Aufrechterhaltung der Entwicklungs- / Produktparität bei, indem sie unabhängig skalierbar sind und die Laufzeitumgebung des Prozesses bündeln. Diese Eigenschaften ermöglichen es, Ihre Anwendungen so zu packen, dass sie reibungslos auf Kubernetes laufen.

Während Ihre Anwendungen containerisiert sein müssen, um auf einem Kubernetes-Cluster ausgeführt zu werden, sindpods die kleinste Abstraktionseinheit, die Kubernetes direkt verwalten kann. Ein Pod ist ein Kubernetes-Objekt, das aus einem oder mehreren eng gekoppelten Containern besteht. Container in einem Pod teilen sich einen Lebenszyklus und werden zusammen als eine Einheit verwaltet. Beispielsweise werden die Container immer auf demselben Knoten geplant, gleichzeitig gestartet oder gestoppt und können Ressourcen wie Dateisysteme und IP-Speicher gemeinsam nutzen.

Zunächst kann es schwierig sein, den besten Weg zu finden, um Ihre Anwendungen in Container und Pods zu unterteilen. Daher ist es wichtig zu verstehen, wie Kubernetes mit diesen Komponenten umgeht und was jede Abstraktionsebene für Ihre Systeme bietet. Mit ein paar Überlegungen können Sie einige natürliche Punkte für die Verkapselung Ihrer Anwendung mit jeder dieser Abstraktionen identifizieren.

Eine Möglichkeit, einen effektiven Bereich für Ihre Container zu bestimmen, besteht darin, nach natürlichen Entwicklungsgrenzen zu suchen. Wenn Ihre Systeme mit einer Microservices-Architektur arbeiten, werden häufig gut konzipierte Container erstellt, um einzelne Funktionseinheiten darzustellen, die häufig in einer Vielzahl von Kontexten verwendet werden können. Diese Abstraktionsebene ermöglicht Ihrem Team, Änderungen an Container-Images freizugeben und diese neue Funktionalität dann in jeder Umgebung bereitzustellen, in der diese Images verwendet werden. Anwendungen können erstellt werden, indem einzelne Container zusammengestellt werden, die jeweils eine bestimmte Funktion erfüllen, jedoch möglicherweise nicht den gesamten Prozess alleine ausführen.

Im Gegensatz zu den oben genannten werden Pods normalerweise erstellt, indem Sie überlegen, welche Teile Ihres Systems am meisten von unabhängigenmanagementprofitieren können. Da Kubernetes Pods als kleinste Abstraktion für Benutzer verwendet, sind dies die primitivsten Einheiten, mit denen die Kubernetes-Tools und die API direkt interagieren und sie steuern können. Sie können Pods starten, stoppen und neu starten oder übergeordnete Objekte verwenden, die auf Pods basieren, um Funktionen für Replikation und Lebenszyklusverwaltung einzuführen. In Kubernetes können Sie die Container in einem Pod nicht unabhängig voneinander verwalten. Sie sollten daher keine Container gruppieren, die von einer separaten Verwaltung profitieren könnten.

Da sich viele Funktionen und Abstraktionen von Kubernetes direkt auf Pods beziehen, ist es sinnvoll, Elemente, die in einem einzigen Pod skaliert werden sollen, zu bündeln und diejenigen zu trennen, die unabhängig voneinander skaliert werden sollen. Wenn Sie beispielsweise Ihre Webserver von Ihren Anwendungsservern in verschiedenen Pods trennen, können Sie die einzelnen Ebenen nach Bedarf unabhängig voneinander skalieren. Das Bündeln eines Webservers und eines Datenbankadapters im selben Pod kann jedoch sinnvoll sein, wenn der Adapter wesentliche Funktionen bietet, die der Webserver für die ordnungsgemäße Funktion benötigt.

Während die Anwendungskonfigurationcanin Container-Images eingebettet wird, ist es am besten, Ihre Komponenten zur Laufzeit konfigurierbar zu machen, um die Bereitstellung in mehreren Kontexten zu unterstützen und eine flexiblere Verwaltung zu ermöglichen. Zur Verwaltung der Laufzeitkonfigurationsparameter bietet Kubernetes zwei Objekte mit den NamenConfigMaps undSecrets an.

ConfigMaps sind ein Mechanismus zum Speichern von Daten, die zur Laufzeit Pods und anderen Objekten ausgesetzt werden können. In ConfigMaps gespeicherte Daten können als Umgebungsvariablen dargestellt oder als Dateien im Pod angehängt werden. Durch das Entwerfen Ihrer Anwendungen zum Lesen von diesen Speicherorten können Sie die Konfiguration zur Laufzeit mithilfe von ConfigMaps einfügen und das Verhalten Ihrer Komponenten ändern, ohne das Container-Image neu erstellen zu müssen.

Secrets sind ein ähnlicher Kubernetes-Objekttyp, der zum sicheren Speichern vertraulicher Daten und zum gezielten Zugreifen auf Pods und andere Komponenten nach Bedarf verwendet wird. Geheimnisse sind eine bequeme Möglichkeit, vertrauliches Material an Anwendungen weiterzuleiten, ohne es in Ihrer normalen Konfiguration an leicht zugänglichen Stellen als Klartext zu speichern. Funktionell funktionieren sie ähnlich wie ConfigMaps, sodass Anwendungen mithilfe derselben Mechanismen Daten aus ConfigMaps und Secrets verwenden können.

Mit ConfigMaps und Secrets können Sie vermeiden, dass die Konfiguration direkt in die Kubernetes-Objektdefinitionen eingefügt wird. Sie können den Konfigurationsschlüssel anstelle des Werts zuordnen, sodass Sie die Konfiguration im Handumdrehen aktualisieren können, indem Sie die ConfigMap oder das Secret ändern. Dies gibt Ihnen die Möglichkeit, das aktive Laufzeitverhalten von Pods und anderen Kubernetes-Objekten zu ändern, ohne die Kubernetes-Definitionen der Ressourcen zu ändern.

Kubernetes bietet zahlreiche sofort einsatzbereite Funktionen zur Verwaltung der Lebenszyklen von Komponenten und zur Gewährleistung, dass Ihre Anwendungen immer funktionsfähig und verfügbar sind. Um diese Funktionen nutzen zu können, muss Kubernetes jedoch verstehen, wie der Zustand Ihrer Anwendung überwacht und interpretiert werden soll. Zu diesem Zweck können Sie mit Kubernetes die Sondenliveness undreadinessdefinieren.

Mithilfe von Liveness-Tests kann Kubernetes feststellen, ob eine Anwendung in einem Container aktiv ist und ausgeführt wird. Kubernetes kann in regelmäßigen Abständen Befehle im Container ausführen, um das grundlegende Anwendungsverhalten zu überprüfen, oder HTTP- oder TCP-Netzwerkanforderungen an einen bestimmten Speicherort senden, um festzustellen, ob der Prozess verfügbar ist und wie erwartet reagieren kann. Wenn eine Aktivitätsprüfung fehlschlägt, startet Kubernetes den Container neu, um zu versuchen, die Funktionalität innerhalb des Pods wiederherzustellen.

Bereitschaftstests sind ein ähnliches Tool, mit dem ermittelt wird, ob ein Pod für den Verkehr bereit ist. Anwendungen in einem Container müssen möglicherweise Initialisierungsprozeduren ausführen, bevor sie Clientanforderungen annehmen können, oder sie müssen möglicherweise neu geladen werden, wenn sie über eine neue Konfiguration benachrichtigt werden. Wenn ein Readiness-Test fehlschlägt, sendet Kubernetes vorübergehend keine Anforderungen mehr an den Pod, anstatt den Container neu zu starten. Auf diese Weise kann der Pod seine Initialisierungs- oder Wartungsroutinen abschließen, ohne den Zustand der gesamten Gruppe zu beeinträchtigen.

Durch die Kombination von Liveness- und Readiness-Tests können Sie Kubernetes anweisen, Pods automatisch neu zu starten oder sie aus Backend-Gruppen zu entfernen. Wenn Sie Ihre Infrastruktur so konfigurieren, dass diese Funktionen genutzt werden, kann Kubernetes die Verfügbarkeit und den Zustand Ihrer Anwendungen ohne zusätzlichen Arbeitsaufwand verwalten.

Bei der Erörterung einiger Grundlagen des Pod-Designs haben wir bereits erwähnt, dass andere Kubernetes-Objekte auf diesen Grundelementen aufbauen, um erweiterte Funktionen bereitzustellen. Adeployment, ein solches zusammengesetztes Objekt, ist wahrscheinlich das am häufigsten definierte und manipulierte Kubernetes-Objekt.

Bereitstellungen sind zusammengesetzte Objekte, die auf anderen Kubernetes-Grundfunktionen aufbauen, um zusätzliche Funktionen hinzuzufügen. Sie fügen Zwischenobjekten mit der Bezeichnungreplicasets Funktionen zur Verwaltung des Lebenszyklus hinzu, z. B. die Möglichkeit, fortlaufende Aktualisierungen durchzuführen, auf frühere Versionen zurückzusetzen und zwischen Zuständen zu wechseln. Mit diesen Replikatsätzen können Sie Pod-Vorlagen definieren, um mehrere Kopien eines einzelnen Pod-Designs zu erstellen und zu verwalten. Auf diese Weise können Sie Ihre Infrastruktur einfach skalieren, die Verfügbarkeitsanforderungen verwalten und Pods bei einem Ausfall automatisch neu starten.

Diese zusätzlichen Funktionen bieten einen administrativen Rahmen und Selbstheilungsfunktionen für die relativ einfache Pod-Abstraktion. Während Pods die Einheiten sind, die letztendlich die von Ihnen definierten Workloads ausführen, sind sie nicht die Einheiten, die Sie normalerweise bereitstellen und verwalten sollten. Stellen Sie sich Pods stattdessen als einen Baustein vor, mit dem Anwendungen stabil ausgeführt werden können, wenn sie über übergeordnete Objekte wie Bereitstellungen bereitgestellt werden.

Mithilfe von Bereitstellungen können Sie Gruppen austauschbarer Pods bereitstellen und verwalten, um Ihre Anwendungen zu skalieren und die Anforderungen der Benutzer zu erfüllen. Das Weiterleiten des Datenverkehrs an die bereitgestellten Pods ist jedoch ein gesondertes Problem. Wenn Pods im Rahmen von fortlaufenden Aktualisierungen ausgetauscht, neu gestartet oder aufgrund von Hostfehlern verschoben werden, ändern sich die zuvor mit der ausgeführten Gruppe verknüpften Netzwerkadressen. Mit Kubernetesservices können Sie diese Komplexität verwalten, indem Sie Routing-Informationen für dynamische Pools von Pods verwalten und den Zugriff auf verschiedene Ebenen Ihrer Infrastruktur steuern.

In Kubernetes sind Dienste spezifische Mechanismen, die steuern, wie der Datenverkehr an Pod-Gruppen weitergeleitet wird. Unabhängig davon, ob Sie Datenverkehr von externen Clients weiterleiten oder Verbindungen zwischen mehreren internen Komponenten verwalten, können Sie mithilfe von Diensten steuern, wie der Datenverkehr fließen soll. Kubernetes aktualisiert und verwaltet dann alle Informationen, die zum Weiterleiten von Verbindungen an die entsprechenden Pods erforderlich sind, auch wenn sich die Umgebung ändert und sich die Netzwerklandschaft ändert.

Kubernetes bietet eine große Flexibilität bei der Definition und Steuerung der für Ihren Cluster bereitgestellten Ressourcen. Mit Tools wiekubectl können Sie unbedingt Ad-hoc-Objekte definieren, die sofort in Ihrem Cluster bereitgestellt werden sollen. Während dies für die schnelle Bereitstellung von Ressourcen beim Erlernen von Kubernetes nützlich sein kann, weist dieser Ansatz Nachteile auf, die ihn für eine langfristige Produktionsadministration unerwünscht machen.

Eines der Hauptprobleme bei der zwingenden Verwaltung besteht darin, dass keine Aufzeichnungen über die Änderungen hinterlassen werden, die Sie in Ihrem Cluster implementiert haben. Dies macht es schwierig oder unmöglich, im Falle von Fehlern eine Wiederherstellung durchzuführen oder betriebliche Änderungen zu verfolgen, die auf Ihre Systeme angewendet werden.

Glücklicherweise bietet Kubernetes eine alternative deklarative Syntax, mit der Sie Ressourcen in Textdateien vollständig definieren und dannkubectl verwenden können, um die Konfiguration oder Änderung anzuwenden. Das Speichern dieser Konfigurationsdateien in einem Versionskontroll-Repository ist eine einfache Möglichkeit, Änderungen zu überwachen und in die Überprüfungsprozesse zu integrieren, die für andere Teile Ihrer Organisation verwendet werden. Die dateibasierte Verwaltung macht es auch einfach, vorhandene Muster an neue Ressourcen anzupassen, indem vorhandene Definitionen kopiert und bearbeitet werden. Durch das Speichern Ihrer Kubernetes-Objektdefinitionen in versionierten Verzeichnissen können Sie zu jedem Zeitpunkt eine Momentaufnahme des gewünschten Clusterstatus erstellen. Dies kann bei Wiederherstellungsvorgängen, Migrationen oder beim Aufspüren der Hauptursache unbeabsichtigter Änderungen, die an Ihrem System vorgenommen wurden, von unschätzbarem Wert sein.

Die Verwaltung der Infrastruktur, in der Ihre Anwendungen ausgeführt werden, und das Erlernen, wie die Funktionen moderner Orchestrierungsumgebungen optimal genutzt werden können, können entmutigend sein. Viele der Vorteile, die Systeme wie Kubernetes und Technologien wie Container bieten, werden jedoch deutlicher, wenn Ihre Entwicklungs- und Betriebspraktiken an den Konzepten ausgerichtet sind, auf denen die Werkzeuge basieren. Die Systemarchitektur mit den Mustern von Kubernetes zeichnet sich dadurch aus, dass Sie verstehen, wie bestimmte Funktionen einige der mit hochkomplexen Bereitstellungen verbundenen Herausforderungen lindern können, um Ihre Erfahrung mit der Ausführung auf der Plattform zu verbessern.