Get best of the week

Kubernetes: Open Source gegen Anbieter

Hallo, ich heiße Dmitry Krasnov. Seit über fünf Jahren verwalte ich Kubernetes-Cluster und erstelle komplexe Microservice-Architekturen. Anfang dieses Jahres haben wir den auf Containerum basierenden Kubernetes-Clusterverwaltungsdienst gestartet. Bei dieser Gelegenheit werde ich Ihnen sagen, was diese Kubernetes sind und wie sich die Integration mit dem Anbieter von Open Source unterscheidet.

Für den Anfang, was ist Kubernetes. Dies ist ein System zum Verwalten von Containern auf einer großen Anzahl von Hosts. Aus dem Griechischen wird es übrigens als "Pilot" oder "Steuermann" übersetzt. Ursprünglich von Google entwickelt, wurde die Cloud Native Computing Foundation, eine internationale gemeinnützige Organisation, die weltweit führende Entwickler, Endbenutzer und Containertechnologieanbieter zusammenbringt, als technologischer Beitrag übertragen.



Eine große Anzahl von Containern steuern


Nun wollen wir sehen, um welche Art von Containern es sich handelt. Diese Anwendung mit all ihrer Umgebung - hauptsächlich Bibliotheken, von denen das Programm abhängt. All dies ist in Archiven verpackt und in Form eines Images dargestellt, das unabhängig vom Betriebssystem ausgeführt, getestet und nicht nur getestet werden kann. Es gibt jedoch ein Problem: Die Verwaltung von Containern auf einer großen Anzahl von Hosts ist sehr schwierig. Daher wurde Kubernetes erstellt.

Ein Container-Image ist eine Anwendung mit ihren Abhängigkeiten. Die Anwendung, ihre Abhängigkeiten und das Image des OS-Dateisystems befinden sich in verschiedenen Teilen des Images, den sogenannten Layern. Ebenen können für verschiedene Container wiederverwendet werden. Beispielsweise kann für alle Anwendungen im Unternehmen die Ubuntu-Basisschicht verwendet werden. Beim Starten von Containern müssen nicht mehrere Kopien einer Basisschicht auf dem Host gespeichert werden. Auf diese Weise können Sie die Speicherung und Bereitstellung von Bildern optimieren.

Wenn wir die Anwendung vom Container aus starten möchten, werden die erforderlichen Ebenen übereinandergelegt und ein Overlay-Dateisystem gebildet. Oben wird eine Ebene für die Aufzeichnung überlagert, die beim Stoppen des Containers gelöscht wird. Dadurch wird sichergestellt, dass die Anwendung beim Starten des Containers immer dieselbe Umgebung hat, die nicht geändert werden kann. Dies stellt die Reproduzierbarkeit der Umgebung auf verschiedenen Host-Betriebssystemen sicher. Ob Ubuntu oder CentOS, die Umgebung wird immer dieselbe sein. Darüber hinaus wird der Container mithilfe der im Linux-Kernel integrierten Mechanismen vom Host isoliert. Anwendungen im Container sehen keine Dateien, Prozesse des Hosts und benachbarter Container. Diese Isolierung von Anwendungen vom Host-Betriebssystem bietet eine zusätzliche Sicherheitsebene.

Es gibt viele Tools zum Verwalten von Containern auf dem Host. Das beliebteste davon ist Docker. Damit können Sie den gesamten Lebenszyklus von Containern sicherstellen. Es funktioniert jedoch nur auf einem Host. Wenn Sie Container auf mehreren Hosts verwalten müssen, kann Docker das Leben von Ingenieuren in die Hölle verwandeln. Deshalb wurde Kubernetes erstellt.

Die Nachfrage nach Kubernetes beruht genau auf der Fähigkeit, Gruppen von Containern auf mehreren Hosts als einzelne Einheiten zu steuern. Die Popularität des Systems bietet die Möglichkeit, DevOps oder Entwicklungsvorgänge zu erstellen, in denen Kubernetes verwendet wird, um die Prozesse dieses DevOps selbst zu starten.



Abbildung 1. Schematische Darstellung der Funktionsweise von Kubernetes

Vollautomatisierung


DevOps ist im Prinzip eine Automatisierung des Entwicklungsprozesses. Grob gesagt schreiben Entwickler Code, der in das Repository eingegossen wird. Dann kann dieser Code automatisch sofort in einem Container mit allen Bibliotheken gesammelt, getestet und für die nächste Stufe - Staging - und dann sofort für die Produktion bereitgestellt werden.

Zusammen mit Kubernetes können Sie mit DevOps diesen Prozess so automatisieren, dass die Entwickler selbst kaum oder gar nicht daran teilnehmen. Aus diesem Grund wird die Assembly erheblich beschleunigt, da der Entwickler dies nicht auf seinem Computer ausführen muss. Er schreibt lediglich einen Code, schiebt den Code in das Repository und startet dann die Pipeline, die die Assembly, das Testen und den Rollout-Prozess umfassen kann. Und dies geschieht bei jedem Commit, sodass die Tests noch nicht abgeschlossen sind.

Gleichzeitig können Sie durch die Verwendung des Containers sicherstellen, dass die gesamte Umgebung dieses Programms genau in der Form in Produktion geht, in der es getestet wurde. Das heißt, es wird keine Probleme aus der Kategorie "Beim Test gab es einige Versionen in der Produktion - andere, aber wenn eingestellt - alles fiel". Und seit heute haben wir einen Trend zur Microservice-Architektur, wenn anstelle einer großen Anwendung Hunderte kleiner Anwendungen vorhanden sind, um sie manuell zu verwalten, benötigen Sie ein großes Personal. Deshalb verwenden wir Kubernetes.

Vorteile, Vorteile, Vorteile


Wenn wir über die Vorteile von Kubernetes als Plattform sprechen, hat dies erhebliche Vorteile hinsichtlich der Verwaltung der Microservice-Architektur.

  • . — . , — . . , Kubernetes .
  • . Kubernetes . . , . Kubernetes , Service Discovery. IP- Kubernetes. health check` .
  • . . Kubernetes ConfigMap`. . , .
  • Persistent Volumes. , , . . Kubernetes — Persistent Volumes. , , . , .
  • Load Balancer. , Kubernetes Deployment, StatefulSet .., . . Kubernetes . , ? , . Kubernetes Load Balancer. . . , . Kubernetes.

Kubernetes eignet sich am besten zum Starten von Microservice-Architekturen. Die Implementierung eines Systems in klassischer Architektur ist möglich, aber sinnlos. Wenn die Anwendung nicht in mehreren Replikaten funktionieren kann, was ist dann der Unterschied - in Kubernetes oder nicht?

Open Source Kubernetes


Open Source Kubernetes ist eine großartige Sache: Es ist installiert und funktioniert. Sie können auf Ihren Eisenservern, in Ihrer Infrastruktur, Assistenten und Worker bereitstellen, auf denen alle Anwendungen ausgeführt werden. Und vor allem - das alles ist kostenlos. Es gibt jedoch Nuancen.

  • Das erste ist die Genauigkeit des Wissens und der Erfahrung von Administratoren und Ingenieuren, die all dies bereitstellen und begleiten werden. Da der Client im Cluster vollständige Handlungsfreiheit erhält, trägt er die Verantwortung für die Funktionsfähigkeit des Clusters. Und hier alles zu brechen ist sehr einfach.
  • Das zweite ist die mangelnde Integration. Wenn Sie Kubernetes ohne eine beliebte Virtualisierungsplattform ausführen, erhalten Sie nicht alle Vorteile des Programms. B. die Verwendung von Persistent Volumes und Load Balancer-Diensten.



Abbildung 2. Die k8s-Architektur

Kubernetes vom Verkäufer


Die Integration mit einem Cloud-Anbieter bietet zwei Optionen:

  • Erstens kann eine Person einfach auf die Schaltfläche „Cluster erstellen“ klicken und einen Cluster abrufen, der bereits konfiguriert und betriebsbereit ist.
  • Zweitens richtet der Anbieter selbst einen Cluster ein und konfiguriert die Integration in die Cloud.

Wie passiert das bei uns? Der Techniker, der den Cluster startet, gibt an, wie viele Mitarbeiter er benötigt und mit welchen Parametern (z. B. 5 Mitarbeiter mit jeweils 10 CPUs, 16 GB RAM und beispielsweise 100 GB Festplatte). Dann erhält es Zugriff auf den bereits gebildeten Cluster. Gleichzeitig werden die Mitarbeiter, auf denen die Last gestartet wird, vollständig an den Kunden übergeben, aber die gesamte Managementebene bleibt im Verantwortungsbereich des Anbieters (wenn der Service gemäß dem Managed Service-Modell bereitgestellt wird).

Ein solches Schema hat jedoch seine Nachteile. Aufgrund der Tatsache, dass 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 der Client bestimmte Funktionen an Kubernetes binden möchte, z. B. die Authentifizierung über LDAP, und die Konfiguration der Verwaltungsebene lässt dies nicht zu.



Abbildung 3. Ein Beispiel für einen Kubernetes-Cluster von einem Cloud-Anbieter

Was zu wählen: Open Source oder Anbieter


Also, Open Source Kubernetes oder Anbieter? Wenn wir Open Source Kubernetes verwenden, möchte der Benutzer das tun, was er tut. Aber eine gute Chance, sich ins Bein zu schießen. Bei Anbietern ist dies komplizierter, da alles für das Unternehmen durchdacht und konfiguriert ist. Der größte Nachteil von Open Source Kubernetes ist die Anforderung an Spezialisten. Bei einem Anbieter bleibt das Unternehmen von diesen Kopfschmerzen verschont, muss jedoch entscheiden, ob es seine Spezialisten oder den Anbieter bezahlt.





Nun, die Vor- und Nachteile liegen auf der Hand. Ausnahmslos eines: Kubernetes löst viele Probleme, indem es die Verwaltung mehrerer Container automatisiert. Und welche Wahl, Open Source oder Anbieter - jeder entscheidet für sich.

Der Artikel wurde von Dmitry Krasnov, leitender Architekt des Containerum-Dienstes des Anbieters #CloudMTS, erstellt

More articles:


All Articles