// Wissenswertes über die Cloud Native Technologie

Kubernetes

Hier erfährst Du alles über die Geschichte von Kubernetes, der Architektur von Kubernetes, Vorteile & Einsatzfelder & vieles mehr!

Kubernetes Technologie Header

Inhaltsverzeichnis

Es war einmal: Der Weg zu Kubernetes

Die Geschichte von Kubernetes begann bei Google

Wie kein anderes benötigte das Unternehmen riesige Infrastrukturen, um seine Suchmaschine und die damit verbundene Werbung für alle Menschen verfügbar zu machen. Das geplante, gewaltige Wachstum war eine Herausforderung, für die verschiedene Ideen entstanden sind. Virtualisierung von Hardware, Site Reliability Engineering und Container-Technologien stellen drei wesentliche Pfeiler dar, welche für die spätere Lösung essenziell sind:

Kubernetes Logo

Cloud Computing: Mit virtuellen Maschinen effiziente Infrastrukturen realisieren

Virtualisierte Rechenleistung ist eine bedeutende Grundvoraussetzung für effiziente Infrastrukturen: Sie hat die Auslastung von Server-Hardware um das fünffache verbessert. Während zuvor für einen Dienst ein Hardware-Server eingesetzt wurde, versammeln sich dank virtualisierter Hardware viele Dienste auf einem. So verbessert sich die Auslastung der Hardware von 5 auf 25 Prozent. Trotz Virtualisierung ist es weiterhin so, dass das volle Potential der Ressourcen nicht vollständig ausgereizt wird: Reicht bei Hochlasten eine einzelne Maschine nicht aus, kann sich zu ruhigeren Zeiten das ganze System langweilen. Das stellen auch wir als Betreiber einer OpenStack-basierten Public Cloud fest.

Site Reliability Engineering: Probleme über Software lösen

Der Ansatz hinter Site Reliability Engineering (SRE) ist, Betrieb und Softwareentwicklung zu vereinen. Indem SRE auf die Mittel der Softwareentwicklung zugreift, löst es klassische Probleme der IT-Operations. Stürzt beispielsweise ein Server ab, will SRE das Problem nicht in erster Linie dadurch beheben, indem es die Konfiguration der Server verändert. Stattdessen setzt Site Reliability Engineering auf Ebene der Software an, um das Problem automatisiert und nachhaltiger zu lösen. 

Das Docker-Zeitalter: Mit Containern Entwicklung und Betrieb optimieren

Docker startete 2013 mit einer simplen Idee: Applikationen benötigen nicht immer ein vollständiges Betriebssystem mit allen Diensten und Services, sondern nur einen kleinen Teil dieser. Mit diesem Ansatz lassen sich ressourcenschonende Images bauen, die für sich autonom funktionieren und ein eigenständiges Arbeitsergebnis produzieren. Für die Softwareentwicklung, aber auch aus Perspektive des Betriebs, war der neue Quasistandard für Container-based Images eine erfreuliche Entwicklung: Developer konnten mit ihnen Software entwickeln, ohne verstärkt Rücksicht auf individuelle Umgebungen nehmen zu müssen; ebenso führte der Container zu weniger Fehlern im Betrieb.

Docker vs. Kubernetes

Docker und Kubernetes gehören zu den beliebtesten Container Technologien. Wer hat also die Nase vorn im Kampf um die Hoheit im Container-Geschäft? Die Beantwortung dieser Frage ist schwieriger als vermutet. Wir haben eine Infografik erstellt, welche die wesentlichen Bestandteile und Features von Docker und Kubernetes gegenübergestellt und somit Klarheit verschafft!

Infografik Docker vs. Kubernetes Vorschau Abbildung

Aus dem Projekt “Borg” wird Kubernetes

Google griff auf vielfältige Weise auf Container und ihre Vorteile zurück – auch unabhängig von Docker. Um Container vernünftig zu verwalten (oder zu orchestrieren) entwickelten die Mitarbeiter das Projekt “Borg”. Star-Trek-Fans kennen die Bedeutung des Namens: Es handelt sich um ein Kollektiv, das nicht hierarchisch organisiert ist, denn alle Borg stehen miteinander in Verbindung. Wir lernen später, was das für Kubernetes bedeutet.

 

Borg war ein unbestrittener Wettbewerbsvorteil von Google, denn er lastete die Maschinen deutlich besser aus als es über den rein virtualisierten Betrieb möglich war. Google stärkte seine Marktposition, indem es in der Lage war, zu wesentlich geringeren Kosten riesige Infrastruktur-Landschaften bereitzustellen.

 

Der große Wurf für die Allgemeinheit war die Idee, Borg als Open-Source-Lösung zur Verfügung zu stellen. Kubernetes (griechisch für Steuermann; kurz: K8 oder K8s) war geboren.

Kubernetes und die CNCF

Im Jahr 2016 wurde das Projekt Kubernetes von Google an die Cloud Native Computing Foundation (CNCF) gespendet. Die CNCF wurde 2015 als Projekt der Linux Foundation gegründet und hat mittlerweile über 500 Mitglieder, bestehend aus Entwicklern, Endanwendern sowie IT-Technologie- und Serviceanbietern. Ziel dieser Community ist die Ausgestaltung eines Open Source Ökosystems aus herstellerneutralen Projekten

Was ist Kubernetes?

Die Open-Source-Plattform Kubernetes orchestriert und automatisiert das Einrichten, Betreiben und auch Skalieren von Container-Anwendungen. Die Architektur ermöglicht, die Container über mehrere Maschinen zu orchestrieren – unabhängig davon, ob es sich dabei um virtualisierte Hardware oder Bare Metal handelt.

Kubernetes Architektur mit einzelnen Komponenten

Kubernetes überwacht den Zustand der Anwendungen kontinuierlich und stellt sicher, dass er den angegebenen Beschreibungen entspricht: Ist in den Beschreibungen hinterlegt, dass beispielsweise immer drei Instanzen als Webserver ausgeführt werden sollen, hält Kubernetes genau drei Instanzen am Laufen. Fällt eine Instanz aus oder stürzt ein Prozess ab, startet Kubernetes diese Instanz neu. Auch wenn ein ganzer Arbeitsprozess ausfällt oder nicht erreichbar ist, startet Kubernetes diesen von einem neuen Knoten aus neu. Mehr zu Kubernetes erfährst Du auch in unserem Blogpost „Kubernetes einfach erklärt“.

Kubernetes Architektur

Die Control Plane ist das zentrale Steuerungselement, das die Container auf die Nodes verteilt und verwaltet. Sie ist für die Aufrechterhaltung des gewünschten Zustands des Clusters verantwortlich, einschließlich der Bereitstellung und Planung von Anwendungen.

Eine Node, auch Minion genannt, kann eine virtuelle Maschine (VM) oder ein physikalischer Server sein. Auf den Nodes laufen die Pods.

Pods sind die kleinste deploybare Einheit. Sie beinhalten einen oder mehrere Container, die sich die zugeteilten Ressourcen teilen.

Der etcd speichert die Konfigurationen des Kubernetes Clusters und stellt damit die Key-Value-Datenbank dar. Die Kommunikation mit der etcd verwaltet Kubernetes über den API Server.

Der API Server hält alle Informationen des etcd bereit, er gehört damit zu den wichtigsten Komponenten von Kubernetes. Über REST-Schnittstellen beispielsweise kommuniziert er mit allen internen und externen Diensten der Kubernetes Cluster.

Der kube-scheduler überwacht und verwaltet die Auslastung der Nodes, indem er als eigenständige Komponente anhand der Ressourcen entscheidet, auf welcher Node ein Pod startet.

Der Controller Manager enthält alle Kontrollmechanismen und ist dadurch ein wesentlicher Bestandteil für das Monitoring. Er kommuniziert mit dem API Server, um alle Status zu lesen und zu schreiben.

// Managed Kubernetes Made in Germany

Mehr als Kubernetes: MetaKube by SysEleven

Für die IT-Welt ist Kubernetes ein revolutionärer Ansatz und erleichtert DevOps das Leben. Doch die Implementierung von Kubernetes ist aufwendig und komplex. Mit MetaKube bieten wir Dir einen Managed Service für Kubernetes an, der über die reine Bereitstellung hinaus geht: Wir stellen Dir die mächtigen Features von Kubernetes zur Verfügung und haben bereits weitere wichtige Services für Dich berücksichtigt. Zu den Meta-Features gehören Backup & Recovery, Load Balancer as a Service, Monitoring sowie das Lifecycle Management.

Mit MetaKube sind wir Mitglied der CNCF und sind damit beim Dachverband registriert, der die Entwicklungen der Open-Source-Lösung organisatorisch zusammenfasst. Aus diesem Grund achten wir strikt darauf, dass wir bei MetaKube standardkonform zu Kubernetes bleiben. Auch unsere OpenStack-basierte Cloud, auf der wir Kubernetes betreiben, ist zu 100 % standardkonform.

SysEleven Kubernetes Service Layer Schaubild mit 4 Ebenen
// Managed Kubernetes 101

Alles, was Du über den Betrieb eines Clusters wissen musst

Der Aufbau eines eigenen Kubernetes kann sehr komplex sein. Eine Kubernetes-Installation allein reicht in der Regel nicht aus, denn der Teufel steckt im Detail: die Verwaltung aller Bestandteile eines Clusters. Wir zeigen Dir Schritt für Schritt, welche Erweiterungen für Kubernetes existieren. Du erhältst einen allgemeinen Einblick in folgende Themenbereiche:

Runtime

Die Container Runtime läuft getrennt von der eigentlichen Containerverwaltung und bietet über diese Schnittstelle eine externe Steuerung. Da diese Schnittstelle auch gewartet werden muss, ist dies die erste Komponente, die in das Kubernetes-Lifecycle-Management integriert ist.

Service Proxy

In Kubernetes können zentrale Komponenten für standardisierte Aufgaben in der Software-Architektur eingesetzt werden. So kann z. B. mit einem Service Proxy oder einem Service Mesh eine Software eingesetzt werden, welche globale Funktionsanforderungen erfüllt.

Service Mesh

Ein Service Mesh ist eines der größeren Themen, die die Softwareentwicklung auf Kubernetes erwarten darf. Hierbei wird die Möglichkeit integriert, das “Netz” von Microservices bzw. Pods in ihrer Kommunikation zu verwalten.

Message Streaming

Eine Message Queue dient zur asynchronen Verarbeitung von Nachrichten zwischen einzelnen Diensten. Das unterstützt den generellen Ansatz von Microservice-Architekturen und damit auch containerisierte Applikationen.

Datenbanken

Management-Systeme für Datenbanken erfreuen sich einer großen Beliebtheit. Durch die hohe Effizienz in der Speicherung, der Zugriffssteuerung als auch in der logischen Sortierung bilden sie den Status Quo im Bereich der Datenspeicherung.

CI/CD

Continuous Integration (CI) behandelt die automatisierte Zusammenführung verschiedener Komponenten während der Softwareentwicklung. Dadurch wird sichergestellt, dass auch bei mehreren Entwicklungen an der gleichen Applikation keine Fehler entstehen.

App Definition & Image Build

Damit eine Applikation geliefert werden kann, muss zunächst einmal festgelegt werden, was eine Applikation ist. Im Bereich der Containerisierung und der Aufteilung von Services in Microservices kann das schon einmal verwirrend werden.