Kubernetes, Container und persistentes Storage erklärt

Was ist Containerisierung?

Die Containerisierung ist eine Form der Virtualisierung, die sich vielleicht am besten durch einen Vergleich mit der traditionellen Servervirtualisierung verstehen lässt.

Bei der Servervirtualisierung – beispielsweise von VMware und Nutanix – wird eine Hypervisor-Schicht geschaffen, die die physischen Serverressourcen maskiert und auf der zahlreiche logische Server, die so genannten virtuellen Maschinen, laufen.

Bei der Anwendungs-Containerisierung wird diese Hypervisor-Schicht abgeschafft und mit dem Serverbetriebssystem gearbeitet. Container kapseln alles, was für die Ausführung einer Anwendung erforderlich ist, und können sehr schnell erstellt, in Betrieb genommen, geklont, skaliert und gelöscht werden.

Container sind leichter, da sie ohne Hypervisor und mehrere Iterationen des Virtualisierungsbetriebssystems auskommen. Sie benötigen weniger Server-Ressourcen und sind sehr portabel in On-Premise- und Cloud-Umgebungen. Daher eignen sich Container gut für Arbeitslasten, die massive Nachfragespitzen aufweisen, insbesondere im Internet.

Container arbeiten außerdem nach dem Prinzip der Microservices, bei dem einzelne Anwendungsfunktionen in kleine, codierte Instanzen unterteilt werden, die über Anwendungsprogrammierschnittstellen (APIs) miteinander verbunden sind – im Gegensatz zu den großen, monolithischen Anwendungen der Vergangenheit. Container und Microservices sind auch ein Synonym für die iterativen Softwareentwicklungsmethoden von DevOps.

Was ist Kubernetes?

Kubernetes ist ein Container-Orchestrierungs-Tool. Es ist aber nicht das einzige am Markt verfübare Tool dafür. Es gibt unter anderem auch Apache Mesos, Docker Swarm, Nomad oder Red Hat OpenShift. In der Cloud gibt es AWS Elastic Container Services (ECS), Azure Kubernetes Service und Google Cloud Kubernetes. Zudem sind VMware Tanzu-Produkte erhältlich, die Kubernetes in ihrer Virtualisierungsumgebung verwalten.

Container-Orchestratoren übernehmen Funktionen wie die Erstellung, die Verwaltung, die Automatisierung, den Lastausgleich und die Beziehung zur Hardware – einschließlich des Storage – von Containern. Sie sind in der Kubernetes-Sprache in Pods organisiert, das heißt einer Sammlung von einem oder mehreren Containern.

In dieser Erläuterung konzentrieren wir uns auf Kubernetes. Wie bereits erwähnt, ist Kubernetes nicht der einzige Container-Orchestrator, aber einigen Untersuchungen zufolge ist er mit einem Anteil von über 97 Prozent der überwältigende Marktführer.

Wie ist Kubernetes organisiert?

Der Container ist die Grundeinheit, die die Anwendungslaufzeit und den Code sowie Abhängigkeiten und Bibliotheken enthält. Container sind zustandslos, da sie keine Daten oder Informationen über frühere Zustände speichern. Sie sind äußerst portabel, klonbar und skalierbar, da sie alles, was sie brauchen, mit sich führen. Diese Zustandslosigkeit ist auch eine potenzielle Achillesferse, die wir später erläutern.

Als nächstes folgen Cluster, die Pods enthalten und Container hosten und verwalten. Diese Container können unterschiedliche Funktionen haben – zum Beispiel eine Benutzeroberfläche oder eine Backend-Datenbank –, aber sie befinden sich auf demselben Knoten (das heißt Server) und sind nahe beieinander, sodass sie schnell miteinander kommunizieren können.

Nodes sind physische Maschinen oder VMs, auf denen Pods laufen. Sie können Master-Knoten oder Worker-Knoten sein. Master-Knoten sind die Steuerungsebene, die die Bereitstellung und den Zustand des Kubernetes-Clusters verwaltet.

Zu den Master-Knoten gehören: der API-Server, über den die Interaktion mit dem Cluster erfolgt; ein Scheduler, der die besten Knoten für die Ausführung von Pods findet und bestimmt; der Controller-Manager, der dabei hilft, den erforderlichen Zustand des Clusters aufrechtzuerhalten, zum Beispiel die Anzahl der zu verwaltenden Replikate; und etcd, ein Key-Value-Store, der den Zustand des Clusters speichert.

Worker-Knoten führen Container aus, deren Aufgaben von den Master-Knoten delegiert werden. Worker-Knoten bestehen aus: Kubelets, die die primäre Schnittstelle zwischen dem Worker-Knoten und der Steuerebene des Masterknotens bilden; kube-proxy, das die Netzwerkkommunikation zu den Pods abwickelt; und container runtime, die Software, die die Container ausführt.

Worin besteht die Herausforderung bei Storage und Kubernetes?

Im Grunde genommen ist das Storage in Kubernetes ephemer. Das bedeutet, dass er nicht persistent ist und nach dem Löschen des Containers nicht mehr zur Verfügung steht. Nativer Kubernetes-Speicher wird in den Container geschrieben und aus temporärem Scratch-Speicher auf dem Host-Rechner erstellt, der nur für die Lebensdauer des Kubernetes-Pods existiert.

Aber natürlich benötigen Unternehmensanwendungen persistenten Speicher, und Kubernetes hat Möglichkeiten, dies zu erreichen.  

Wie bietet Kubernetes persistentes Storage?

Kubernetes unterstützt persistenten Speicher, der in eine breite Palette von On-Premise- und Cloud-Formaten geschrieben werden kann, einschließlich Dateien, Blöcken und Objekten sowie in Datendiensten, zum Beispiel Datenbanken.

Speicher kann innerhalb des Pods referenziert werden, was jedoch nicht empfohlen wird, da es gegen den Grundsatz der Portabilität verstößt. Stattdessen verwendet Kubernetes persistente Volumes (PVs) und persistente Volume Claims (PVCs), um Speicher- und Anwendungsanforderungen zu definieren.

PVs und PVCs entkoppeln das Storage und ermöglichen es, dass er von einem Pod auf portable Weise genutzt werden kann.

Ein PV – das nicht über Kubernetes-Cluster hinweg portabel ist – definiert Speicher im Cluster, der anhand seiner Leistungs- und Kapazitätsparameter profiliert wurde. Es definiert ein persistentes Storage Volume und enthält Details wie Leistungs-/Kostenklasse, Kapazität, verwendetes Volume-Plug-in, Pfade, IP-Adressen, Benutzernamen und Passwörterund was nach der Verwendung mit dem Volumen geschehen soll.

Eine PVC hingegen beschreibt eine Speicheranforderung für die Anwendung, die in Kubernetes ausgeführt werden soll. PVCs sind portabel und reisen mit der containerisierten Anwendung mit. Kubernetes ermittelt anhand der definierten PVs, welcher Speicherplatz verfügbar ist, und bindet die PVC daran.

PVCs werden in der YAML-Konfigurationsdatei des Pods definiert, so dass der Anspruch sich mit dem Pod mitbewegt und Kapazität, Speicherleistung und andere Parameter angeben kann.

Das StatefulSet dupliziert PVCs unter anderem für das persistente Storage über Pods hinweg.

Eine Sammlung von PVs kann in einer Speicherklasse gruppiert werden, die das verwendete Storage-Volume-Plug-in, den externen – zum Beispiel Cloud – Anbieter und den Namen des CSI-Treibers angibt (siehe unten).

Häufig wird eine Speicherklasse als Standard markiert, so dass sie bei Verwendung einer PVC nicht aufgerufen werden muss oder aufgerufen werden kann, wenn ein Benutzer keine Speicherklasse in einer PVC angibt. Eine Speicherklasse kann auch für alte Daten erstellt werden, auf die möglicherweise von containerisierten Anwendungen zugegriffen werden muss.

Was ist CSI?

CSI steht für Container Storage Interface und ist die Speicherschnittstelle. CSI beschreibt Treiber für Kubernetes und andere Container-Orchestratoren, die von Speicheranbietern bereitgestellt werden, um ihre Kapazität für containerisierte Anwendungen als persistenten Speicher bereitzustellen.

Zum Zeitpunkt der Erstellung dieses Artikels sind mehr als 130 CSI-Treiber für Datei-, Block- und Objektspeicher in Hardware- und Cloud-Formaten verfügbar.

CSI bietet eine Schnittstelle, die die Konfiguration von persistentem Speicher außerhalb des Orchestrators, seine Ein-/Ausgabe (E/A) und erweiterte Funktionen wie Snapshots und Klonen definiert.

Ein CSI-Volume kann zur Definition von PVs verwendet werden. Sie können zum Beispiel PVs und Speicherklassen erstellen, die auf externen Speicher verweisen, der durch ein CSI-Plug-in definiert ist, wobei die Bereitstellung durch eine PVC ausgelöst wird, die diesen spezifiziert.

Was bieten Storage-Anbieter zur Unterstützung von K8s Storage und Data Protection?

Die Komponenten von Kubernetes sind zahlreich und modular. Es überrascht vielleicht nicht, dass die Anbieter von Speicher-Arrays die Möglichkeit genutzt haben, eine weitere Verwaltungsschicht darüber zu legen und die Bereitstellung von Speicher- und Datendiensten für Administratoren zu vereinfachen. Hier betrachten wir die Produkte der Speicheranbieter in diesem Bereich.

Die Anforderungen reichen hier von der Konfiguration der Ressourcen entsprechend dem von den Anwendungen benötigten Speicherprofil bis hin zu Quelle und Ziel von Backups und anderen Data-Protection-Funktionen, die sich alle schnell ändern können.

Dell EMC, IBM, HPE, Hitachi, NetApp und Pure Storage verfügen alle über Container-Management-Plattformen, die es Entwicklern ermöglichen, Speicher- und Data-Protection-Anforderungen einfacher in den Code zu schreiben und gleichzeitig traditionelle IT-Funktionen wie Data Protection ohne tiefgreifende Kenntnisse zu verwalten.

Alle verwenden CSI-Treiber in irgendeiner Form, um die Bereitstellung und das Management von Storage und Backup für ihre eigene und in einigen Fällen für jede beliebige Speicherumgebung, einschließlich derjenigen in der Cloud, anzubieten.

Was leisten die Container Storage Modules von Dell?

Die Container Storage Modules (CSM) von Dell basieren auf CSI-Treibern. Während die grundlegenden CSI-Treiber bei der Bereitstellung, Löschung, Zuordnung und Aufhebung der Zuordnung von Datenvolumina helfen, sorgen die CSMs von Dell für Automatisierung, Kontrolle und Einfachheit.

Mehrere CSMs ermöglichen Kunden den Zugriff auf Storage-Array-Funktionen, auf die sie normalerweise keinen Zugriff haben. Diese CSM-Plug-ins zielen auf bestimmte Funktionen oder Datenservices ab, darunter Replikation, Beobachtbarkeit, Ausfallsicherheit, Anwendungsmobilität (Klonen), Snapshots, Autorisierung (das heißt Zugriff auf Speicherressourcen) und Verschlüsselung.

Die CSMs von Dell ermöglichen es den Kunden, bestehende Speichercontainer für den Zugriff auf die Speicher-Arrays von Dell fit zu machen, anstatt zusätzliche Software für den Zugriff auf diese Funktionen zu verwenden.

Was leistet Red Hat Openshift von IBM für Container?

Mit der Übernahme von Red Hat im Jahr 2018 hat IBM das OpenShift-Portfolio übernommen, das den Hauptteil seiner Bemühungen um die Verwaltung von Containern ausmacht. OpenShift nutzt Kubernetes Persistent Volume Claims über CSI-Treiber, damit Entwickler Speicherressourcen anfordern können. PVCs können von überall in der OpenShift-Plattform auf persistente Volumes zugreifen.

Die OpenShift Container Platform unterstützt viele beliebte PV-Plug-ins vor Ort und in der Cloud, darunter Amazon EBS, Azure Files, Azure Managed Disks, Google Cloud Persistent Disk, Cinder, iSCSI, Local Volume, NFS und VMware vSphere.

Der Anbieter von hyperkonvergenter Infrastruktur Nutanix nutzt OpenShift ebenfalls als Plattform für die Bereitstellung von Containern.

Wie hilft die Ezmeral Runtime Enterprise von HPE bei der Verwaltung von Containern?

HPE hat seine eigene Kubernetes-Verwaltungsplattform, HPE Ezmeral Runtime Enterprise, entwickelt, die über die Synergy-Umgebung von HPE bereitgestellt werden kann.

Es handelt sich um eine Softwareplattform, die für die Bereitstellung von Cloud-nativen und nicht-Cloud-nativen Anwendungen unter Verwendung von Kubernetes entwickelt wurde und auf Bare-Metal- oder virtualisierter Infrastruktur, vor Ort oder in einer beliebigen Cloud ausgeführt werden kann. Sie geht über die bloße Bereitstellung von Anwendungen hinaus und umfasst auch das Datenmanagement bis hin zum Edge.

Ezmeral bietet persistentea Container-Storage und Konfigurationsautomatisierung zur Einrichtung von Container-HA, Sicherung und Wiederherstellung, Sicherheitsvalidierung und Überwachung, um manuelle Verwaltungsaufgaben zu minimieren. 

Was leistet der Hitachi Kubernetes Service für Container-Implementierungen?

Im Jahr 2021 stieg Hitachi mit dem Hitachi Kubernetes Service (HKS) in den Kubernetes-Speicher ein, mit dem Kunden Container-Speicher in lokalen Rechenzentren und den drei wichtigsten Public Clouds verwalten können.

HKS ermöglicht den Einsatz der Hitachi Unified Compute Platform als Kubernetes-verwaltete private Cloud in lokalen und hybriden Cloud-Umgebungen. 

HKS verwendet CSI-Treiber, um persistente Volumes direkt auf Kubernetes-Knoten zu managen, wodurch es sich von den Container-nativen Angeboten anderer Anbieter unterscheidet.

Wie hilft NetApp Astra beim Deployment und Management von Containern?

Astra ist die Container-Management-Plattform von NetApp. Sie umfasst eine Reihe von Komponenten, darunter Astra Control für das Management des Lebenszyklus von Kubernetes-Applikationen, Astra Control Service für das Datenmanagement von Kubernetes-Workloads in Public Clouds, Astra Control Centre für Kubernetes-Workloads vor Ort und Astra Trident für die Bereitstellung und das Management von CSI-Storage. Außerdem gibt es Astra Automation und seine APIs und SDK für Astra-Workflows.

Welche Funktionen bietet Pure Storage Portworx für Container-Implementierungen?

Portworx ist die Container-Plattform von Pure Storage, die eine containernative Bereitstellung, Konnektivität und Leistungskonfiguration für Kubernetes-Cluster ermöglicht. Es kann Speicher erkennen und dauerhafte Kapazität für Unternehmensanwendungen mit Zugriff auf Block-, Datei- und Objekt- sowie Cloud-Speicher bereitstellen.

Kunden können mit Portworx Speicherpools aufbauen, die Bereitstellung verwalten und erweiterte Funktionen wie Backup, Disaster Recovery, Sicherheit, automatische Skalierung und Migration von lokalem oder Cloud-Speicher bei den wichtigsten Cloud-Anbietern bereitstellen.