Kubernetes: Open Source vs. herstellerspezifisch

Hallo, mein Name ist Dmitry Krasnov. Seit mehr als fünf Jahren verwalte ich Kubernetes-Cluster und baue komplexe Microservice-Architekturen auf. Anfang dieses Jahres haben wir einen Dienst zur Verwaltung von Kubernetes-Clustern auf Basis von Containerum gestartet. Bei dieser Gelegenheit erzähle ich Ihnen, was Kubernetes ist und wie sich die Integration mit einem Anbieter von Open Source unterscheidet.

Zunächst einmal, was ist Kubernetes. Hierbei handelt es sich um ein System zur Verwaltung von Containern auf einer großen Anzahl von Hosts. Aus dem Griechischen wird es übrigens mit „Pilot“ oder „Steuermann“ übersetzt. Ursprünglich von Google entwickelt und dann als Technologiebeitrag an die Cloud Native Computing Foundation gespendet, eine internationale gemeinnützige Organisation, die die weltweit führenden Entwickler, Endbenutzer und Anbieter von Containertechnologie zusammenbringt.

Verwalten Sie eine große Anzahl von Containern

Lassen Sie uns nun herausfinden, um welche Art von Containern es sich handelt. Dabei handelt es sich um eine Anwendung mit ihrer gesamten Umgebung – hauptsächlich den Bibliotheken, von denen das Programm abhängt. All dies wird in Archiven verpackt und in Form eines Images präsentiert, das unabhängig vom Betriebssystem ausgeführt, getestet und mehr werden kann. Es gibt jedoch ein Problem: Die Verwaltung von Containern auf einer großen Anzahl von Hosts ist sehr schwierig. Aus diesem Grund wurde Kubernetes entwickelt.

Ein Container-Image repräsentiert eine Anwendung und ihre Abhängigkeiten. Die Anwendung, ihre Abhängigkeiten und das Betriebssystem-Dateisystem-Image befinden sich in verschiedenen Teilen des Images, sogenannten Ebenen. Ebenen können für verschiedene Container wiederverwendet werden. Beispielsweise könnten alle Anwendungen in einem Unternehmen die Ubuntu-Basisschicht verwenden. Beim Ausführen von Containern ist es nicht erforderlich, mehrere Kopien einer einzelnen Basisschicht auf dem Host zu speichern. Dadurch können Sie die Bildspeicherung und -bereitstellung optimieren.

Wenn wir eine Anwendung aus einem Container ausführen möchten, werden die erforderlichen Schichten übereinander gelegt und ein Overlay-Dateisystem gebildet. Darauf wird eine Aufnahmeschicht gelegt, die beim Stoppen des Behälters entfernt wird. Dadurch wird sichergestellt, dass die Anwendung beim Ausführen des Containers immer dieselbe Umgebung hat, die nicht geändert werden kann. Dies gewährleistet die Reproduzierbarkeit der Umgebung auf verschiedenen Host-Betriebssystemen. Ob Ubuntu oder CentOS, die Umgebung wird immer dieselbe sein. Darüber hinaus wird der Container mithilfe von im Linux-Kernel integrierten Mechanismen vom Host isoliert. Anwendungen in einem Container sehen keine Dateien, Prozesse des Hosts und benachbarter Container. Diese Isolierung der Anwendungen vom Host-Betriebssystem bietet eine zusätzliche Sicherheitsebene.

Es stehen zahlreiche Tools zum Verwalten von Containern auf einem Host zur Verfügung. Das beliebteste davon ist Docker. Damit können Sie den gesamten Lebenszyklus von Containern abdecken. Es funktioniert jedoch nur auf einem Host. Wenn Sie Container über mehrere Hosts hinweg verwalten müssen, kann Docker Ingenieuren das Leben zur Hölle machen. Aus diesem Grund wurde Kubernetes entwickelt.

Die Nachfrage nach Kubernetes ist genau auf die Fähigkeit zurückzuführen, Containergruppen auf mehreren Hosts als eine Art einzelne Einheit zu verwalten. Die Beliebtheit des Systems bietet die Möglichkeit, DevOps oder Development Operations aufzubauen, bei denen Kubernetes zum Ausführen der Prozesse dieses DevOps verwendet wird.

Abbildung 1. Schematische Darstellung der Funktionsweise von Kubernetes

Vollständige Automatisierung

Unter DevOps versteht man grundsätzlich die Automatisierung des Entwicklungsprozesses. Grob gesagt schreiben Entwickler Code, der in das Repository hochgeladen wird. Anschließend kann dieser Code sofort automatisch in einem Container mit allen Bibliotheken gesammelt, getestet und für die nächste Stufe – das Staging – und dann sofort für die Produktion „ausgerollt“ werden.

Zusammen mit Kubernetes können Sie mit DevOps diesen Prozess automatisieren, sodass er praktisch ohne Beteiligung der Entwickler selbst abläuft. Dadurch ist der Build deutlich schneller, da der Entwickler dies nicht auf seinem Computer tun muss – er schreibt einfach einen Code, schiebt den Code in das Repository und startet anschließend die Pipeline, die den Prozess einbinden kann vom Bauen, Testen und Ausrollen. Und das passiert bei jedem Commit, sodass die Tests kontinuierlich stattfinden.

Gleichzeitig können Sie durch die Verwendung eines Containers sicher sein, dass die gesamte Umgebung dieses Programms genau in der Form, in der es getestet wurde, in die Produktion freigegeben wird. Das heißt, es wird keine Probleme wie „Es gab einige Versionen im Test, andere in der Produktion, aber als wir sie installiert haben, ist alles kaputt gegangen.“ Und da wir heute einen Trend zur Microservice-Architektur haben, bei der es statt einer großen Anwendung Hunderte von kleinen gibt, ist für deren manuelle Verwaltung ein riesiger Mitarbeiterstab erforderlich. Deshalb verwenden wir Kubernetes.

Vorteile, Vorteile, Vorteile

Wenn wir über die Vorteile von Kubernetes als Plattform sprechen, dann hat es aus Sicht der Verwaltung einer Microservice-Architektur erhebliche Vorteile.

• Verwalten mehrerer Replikate. Das Wichtigste ist die Verwaltung von Containern über mehrere Hosts hinweg. Noch wichtiger ist, dass Sie mehrere Anwendungsreplikate in Containern als eine Einheit verwalten. Dadurch müssen sich Ingenieure nicht um jeden einzelnen Container kümmern. Wenn einer der Container abstürzt, erkennt Kubernetes dies und startet ihn erneut.
• Cluster-Netzwerk. Kubernetes verfügt außerdem über ein sogenanntes Cluster-Netzwerk mit eigenem Adressraum. Dadurch hat jeder Pod seine eigene Adresse. Unter einem Subpod versteht man die minimale Struktureinheit eines Clusters, in dem Container direkt gestartet werden. Darüber hinaus verfügt Kubernetes über Funktionen, die einen Load Balancer und Service Discovery kombinieren. Dadurch können Sie auf die manuelle IP-Adressverwaltung verzichten und diese Aufgabe an Kubernetes delegieren. Und automatische Gesundheitsprüfungen helfen dabei, Probleme zu erkennen und den Datenverkehr auf funktionierende Pods umzuleiten.
• Konfigurationsmanagement. Bei der Verwaltung einer großen Anzahl von Anwendungen wird es schwierig, die Anwendungskonfiguration zu verwalten. Zu diesem Zweck verfügt Kubernetes über spezielle ConfigMap-Ressourcen. Sie ermöglichen es Ihnen, Konfigurationen zentral zu speichern und sie beim Ausführen von Anwendungen Pods zur Verfügung zu stellen. Mit diesem Mechanismus können wir die Konsistenz der Konfiguration in mindestens zehn oder hundert Anwendungsreplikaten garantieren.
• Persistente Volumes. Container sind von Natur aus unveränderlich und wenn der Container gestoppt wird, werden alle in das Dateisystem geschriebenen Daten zerstört. Einige Anwendungen speichern Daten jedoch direkt auf der Festplatte. Um dieses Problem zu lösen, verfügt Kubernetes über eine Funktionalität zur Festplattenspeicherverwaltung – Persistent Volumes. Dieser Mechanismus nutzt externen Speicher für Daten und kann persistenten Speicher, Block oder Datei, in Container übertragen. Mit dieser Lösung können Sie Daten getrennt von den Arbeitern speichern, sodass diese gespeichert werden, wenn diese Arbeiter ausfallen.
• Lastenausgleicher. Auch wenn wir in Kubernetes abstrakte Entitäten wie Deployment, StatefulSet usw. verwalten, laufen Container letztendlich auf regulären virtuellen Maschinen oder Hardwareservern. Sie sind nicht perfekt und können jederzeit fallen. Kubernetes erkennt dies und leitet den internen Datenverkehr an andere Replikate weiter. Doch was tun mit dem Verkehr, der von außen kommt? Wenn Sie den Datenverkehr einfach an einen der Worker weiterleiten, ist der Dienst bei einem Absturz nicht mehr verfügbar. Um dieses Problem zu lösen, verfügt Kubernetes über Dienste wie Load Balancer. Sie dienen dazu, automatisch einen externen Cloud-Balancer für alle Worker im Cluster zu konfigurieren. Dieser externe Balancer leitet den externen Datenverkehr an die Mitarbeiter weiter und überwacht selbst deren Status. Wenn ein oder mehrere Worker nicht verfügbar sind, wird der Datenverkehr auf andere umgeleitet. Dadurch können Sie mithilfe von Kubernetes hochverfügbare Dienste erstellen.

Kubernetes funktioniert am besten, wenn Microservice-Architekturen ausgeführt werden. Es ist möglich, das System in die klassische Architektur zu implementieren, aber es ist sinnlos. Welchen Unterschied macht es, wenn eine Anwendung nicht auf mehreren Replikaten ausgeführt werden kann – in Kubernetes oder nicht?

Open-Source-Kubernetes

Open-Source-Kubernetes ist eine tolle Sache: Ich habe es installiert und es funktioniert. Sie können es auf Ihren eigenen Hardwareservern und in Ihrer eigenen Infrastruktur bereitstellen und Master und Worker installieren, auf denen alle Anwendungen ausgeführt werden. Und das Wichtigste: Das alles ist kostenlos. Es gibt jedoch Nuancen.

• Der erste ist der Bedarf an Wissen und Erfahrung von Administratoren und Ingenieuren, die all dies bereitstellen und unterstützen. Da der Kunde im Cluster völlige Handlungsfreiheit erhält, ist er selbst für die Leistung des Clusters verantwortlich. Und es ist sehr leicht, hier alles kaputt zu machen.
• Der zweite Grund ist der Mangel an Integrationen. Wenn Sie Kubernetes ohne eine beliebte Virtualisierungsplattform ausführen, profitieren Sie nicht von allen Vorteilen des Programms. Beispielsweise die Verwendung von Persistent Volumes und Load Balancer-Diensten.

Abbildung 2. k8s-Architektur

Kubernetes vom Anbieter

Die Integration mit einem Cloud-Anbieter bietet zwei Optionen:

• Erstens kann eine Person einfach auf die Schaltfläche „Cluster erstellen“ klicken und erhält einen Cluster, der bereits konfiguriert und einsatzbereit ist.
• Zweitens installiert der Anbieter selbst den Cluster und richtet die Integration mit der Cloud ein.

Wie es hier passiert. Der Ingenieur, der den Cluster startet, gibt an, wie viele Worker er benötigt und mit welchen Parametern (z. B. 5 Worker mit jeweils 10 CPUs, 16 GB RAM und beispielsweise 100 GB Festplatte). Danach erhält es Zugriff auf den bereits gebildeten Cluster. In diesem Fall werden die Worker, auf denen die Last gestartet wird, vollständig an den Kunden übertragen, die gesamte Verwaltungsebene bleibt jedoch in der Verantwortung des Anbieters (sofern der Dienst nach dem Managed-Service-Modell bereitgestellt wird).

Dieses Schema hat jedoch seine Nachteile. Da die Verwaltungsebene beim Anbieter verbleibt, gewährt der Anbieter dem Client keinen vollständigen Zugriff, was die Flexibilität bei der Arbeit mit Kubernetes verringert. Manchmal kommt es vor, dass ein Client bestimmte Funktionen zu Kubernetes hinzufügen möchte, beispielsweise die Authentifizierung über LDAP, die Konfiguration der Managementebene dies jedoch nicht zulässt.

Abbildung 3. Beispiel eines Kubernetes-Clusters eines Cloud-Anbieters

Was Sie wählen sollten: Open Source oder Anbieter

Ist Kubernetes also Open Source oder herstellerspezifisch? Wenn wir Open-Source-Kubernetes nehmen, dann macht der Benutzer damit, was er will. Aber es besteht eine große Chance, sich selbst ins Bein zu schießen. Beim Anbieter ist es schwieriger, da alles für das Unternehmen durchdacht und konfiguriert ist. Der größte Nachteil von Open-Source-Kubernetes ist der Bedarf an Spezialisten. Mit einer Anbieteroption ist das Unternehmen von diesem Problem befreit, muss sich jedoch entscheiden, ob es seine Spezialisten oder den Anbieter bezahlt.

Nun, die Vorteile liegen auf der Hand, die Nachteile sind ebenfalls bekannt. Eines ist konstant: Kubernetes löst viele Probleme, indem es die Verwaltung vieler Container automatisiert. Und für welches man sich entscheidet, Open Source oder Vendor – jeder trifft seine eigene Entscheidung.

Der Artikel wurde von Dmitry Krasnov, dem führenden Architekten des Containerum-Dienstes des #CloudMTS-Anbieters, verfasst

Source: habr.com