Benutzer:MoreInput/Kubernetes Einführung

Einführung

Vergleich traditioneller Ansatz vs. virtuelle Maschinen vs. Containerisierung von Anwendungen

Früher führten Unternehmen Anwendungen auf physischen Servern aus. Es gab keine Möglichkeit, Ressourcengrenzen für Anwendungen auf einem physischen Server zu definieren. Dies führte zu Problemen bei der Ressourcenzuweisung. Wenn z. B. mehrere Anwendungen auf einem physischen Server ausgeführt werden, kann es vorkommen, dass eine Anwendung die meisten Ressourcen beansprucht. Dies hat zur Folge, dass die anderen Anwendungen nicht mehr mit der notwendigen Leistung arbeiten können. Eine Lösung hierfür wäre, jede Anwendung auf einem anderen physischen Server laufen zu lassen. Dies war jedoch nicht skalierbar, da die Ressourcen nicht ausgelastet waren und es für Unternehmen teuer war, viele physische Server zu unterhalten. Die zu betreibende Software war stark an das Betriebssystem gebunden. Aktualisierungen von Bibliotheken konnten Auswirkungen auf die bereits installierte Software haben. Die Aktualisierung der Software war ein kritischer Prozess, der zu Ausfallzeiten führte. Ein Zurückrollen der Installation war praktisch kaum möglich. Die Anwendungen selbst basierten auf einer monolithischen Architektur, die in der Regel nicht in Teilsysteme gegliedert oder auf Basis einzelner, zusammenwirkender Komponenten erstellt wurden. Dadurch waren diese Systeme weder wartbar noch erweiterbar, da die Teile dieses Systems nur mit erheblichem Aufwand modifiziert und an neue Bedingungen angepasst werden können.

Ein Teil der beschriebenen Probleme konnte gelöst werden durch die Virtualisierung der Hardware. Sie ermöglicht es, mehrere virtuelle Maschinen (VMs) auf der CPU eines einzigen physischen Servers auszuführen. Die Virtualisierung ermöglicht die Isolierung von Anwendungen zwischen VMs und bietet ein gewisses Maß an Sicherheit, da die Informationen einer Anwendung nicht frei von einer anderen Anwendung abgerufen werden können. Die Virtualisierung ermöglicht eine bessere Ausnutzung der Ressourcen eines physischen Servers und bietet eine bessere Skalierbarkeit. Eine Anwendung kann einfach hinzugefügt oder aktualisiert werden. Dies reduziert u.a. die Hardwarekosten. Jede virtuelle Maschine ist eine vollständige Maschine, auf der alle Komponenten, einschließlich eines eigenen Betriebssystems, auf der virtualisierten Hardware laufen. Die Abstraktion zwischen der tatsächlich vorhandenen Hardware übernimmt der Hypervisor. Da in einer VM jeweils ein Betriebssystem installiert ist, sind diese nicht leichtgewichtig.

Dies führte zu der Idee der Containervirtualisierung: Für eine Anwendung werden jeweils nur Ressourcen des Betriebssystems zur Verfügung gestellt, welches sie wirklich benötigt. Ein Programm, das innerhalb eines Containers läuft, kann nur den Inhalt des Containers und die dem Container zugewiesenen Geräte sehen. Solche Container sind ähnlich wie VMs, haben aber gelockerte Isolationseigenschaften, um das Betriebssystem mit den Anwendungen zu teilen. Daher werden Container als leichtgewichtig angesehen. Ähnlich wie eine VM hat ein Container sein eigenes Dateisystem, Anteil an CPU, Speicher, Prozessraum und mehr. Da sie von der zugrunde liegenden Infrastruktur entkoppelt sind, sind sie über unterschiedliche Cloud-Lösungen und Betriebssysteme hinweg portabel. Da Container klein und schnell sind, kann in jedes Containerimage eine Anwendung gepackt werden. Container sind in der Regel unveränderlich, d.h. ab dem Zeitpunkt der Erstellung des Containers wird eine konsistente Umgebung von der Entwicklung bis zur Produktion zu gewährleistet. Anstatt die Software innerhalb eines Containers zu aktualisieren wird der alte Container mit einem anderen Container mit neuerer Software ausgetauscht.

Anstatt eine Anwendung monolithisch aufzubauen, werden diese in kleinere Einheiten aufgeteilt (Microservices), die jeweils einen Teilaspekt der Anwendung bereitstellen. Ein Microservice kann relativ leicht ausgetauscht werden, um zum Beispiel Fehler zu beheben. Wenn ein Service in einer Cloud-Umgebung läuft, ist es wichtig, dass das Aktualisieren dieser Komponente ohne Probleme und mit möglichst wenig Ausfallzeit durchgeführt werden kann. (Continuous Deployment). Dies lässt sich erreichen, indem man jeweils einen Service in einem Container bereitstellt.

Mit der Containervirtualisierung gibt es eine gute Möglichkeit, Anwendungen zusammenzustellen und auszuführen. Wird die Anwendung produktiv eingesetzt, so müssen die Container, in denen die Anwendungen laufen, verwaltet werden. Es muss sichergestellt werden, dass es keine Ausfallzeiten gibt. Fällt zum Beispiel ein Container aus, so muss ein anderer Container gestartet werden.

Kubernetes bietet nun ein Framework an, mit dem solche verteilten, auf Container basierenden Systeme ausfallsicher betrieben werden können. Das System kümmert sich um Skalierung und Failover für die laufenden Containern. Kubernetes übernimmt das deployen (bereitstellen) der Container und überwacht deren Status.

Kubernetes bietet folgendes an:

• Service Discovery und Lastausgleich: Stellt Kubernetes fest, dass das Datenaufkommen zu einem Container hoch ist, dann ist das System in der Lage, einen Lastausgleich durchzuführen und den Netzwerkverkehr so zu verteilen, dass die Bereitstellung stabil ist.
• Speicherorchestrierung: Kubernetes kann unterschiedliche Speichersysteme einbinden, z. B. lokale Speicher, öffentliche Cloud-Anbieter und mehr. Die Anwendung, die in einem Container läuft, muss nicht angepasst werden und verwendet die Schnittstelle, die Kubernetes anbietet.
• Automatisierte Rollouts und Rollbacks: Anstatt eine Schritt für Schritt Installationsanweisung zu schreiben, um einen Software zu installieren, wird bei Kubernetes nur der gewünschte Ziel-Zustand für die bereitgestellten Container beschrieben. Kubernetes ändert dann den tatsächlichen Zustand mit dem gewünschten Zustand mit einer kontrollierten Rate.
• Automatisches Bin Packing: Der Administrator stellt Kubernetes einen Cluster von Knoten zur Verfügung, den es zur Ausführung von containerisierten Aufgaben verwenden kann. Zudem wird Kubernetes mitgeteilt, wie viel CPU und Speicher (RAM) jeder Container benötigt. Kubernetes wird dann die Container so auf die Knoten verteilen, um die Ressourcen optimal zu nutzen.
• Selbstheilung: Kubernetes startet Container neu, die ausfallen, ersetzt Container und stoppt Container, wenn diese nicht auf eine benutzerdefinierte Prüfung reagieren. Container werden von Kubernetes erst dann den Clients verfügbar gemacht, wenn diese arbeitsfähig sind.

Cloud-Provider bieten jeweils eine Kubernetes-Umgebung an, in dem der Kunde seine Container laufen lassen kann. Durch das Kubernetes Framework wird sichergestellt, dass die Anwendung in der Cloud in der Weise läuft wie während der Entwicklung getestet.

Wie wurde Software früher betrieben? Welche Nachteile gab es? Monolithisch, schlecht wartbar. Starke Abhängigkeit von Hardware, gemeinsame Bibliotheken. Installation der Anwendungen auf einem Host mit dem Betriebssystempaketmanager Dies hatte den Nachteil, dass die ausführbaren Dateien, Konfigurationen, Bibliotheken und Lebenszyklen der Anwendungen untereinander und mit dem Host-Betriebssystem verwoben waren

Virtualisierung des Betriebssystems? Man könnte unveränderliche Virtual-Machine-Images erzeugen, um vorhersehbare Rollouts und Rollbacks zu erreichen, aber VMs sind schwergewichtig und nicht portierbar.

Was wurde durch Containerisierung einfacher? Anwendung läuft in einem abgeschlossenen System (Container). Alles, was die Anwendung benötigt, wird abstrahiert der Anwendung vom Container System zur Verfügung gestellt. Da Container klein und schnell sind, kann in jedes Containerimage eine Anwendung gepackt werden. ie Generierung von Container-Images zum Zeitpunkt der Erstellung bzw. Freigabe ermöglicht es, eine konsistente Umgebung von der Entwicklung bis zur Produktion zu gewährleisten

Was sind die Anforderungen von Anwendungen in der Cloud? - Kurze Wartungszyklen - Skalierbarkeit - Kurze Ausfallzeiten

Wie bedient Kubernetes die Anforderungen von Anwendungen in der Cloud?

Anwendungen werden aufgeteilt in Dienste / kleinere Einheiten. Austausch einzelner Dienste flexibler.

Platform as as Service (PaaS) und Infrastructre as a Service (IaaS).

https://www.google.de/books/edition/Kubernetes/FiIPEAAAQBAJ?hl=de&gbpv=1&printsec=frontcover