Aus Kubernetes wird Container as a Service

Im Gespräch mit Markus Eisele von Red Hat

von - 08.01.2021
Markus Eisele
Markus Eisele: Developer Adoption Program Lead bei Red Hat
(Quelle: Red Hat )
Die IT-Modernisierung mittels Container-Plattformen und Microservices gewinnt weiter an Bedeutung. com! professional spricht über den Stand der Dinge und die Entwicklungen rund um Container-Technologien mit Markus Eisele, Developer Adoption Program Lead beim Software-Spezialisten Red Hat.
com! professional: Herr Eisele, Container gibt es ja schon seit einigen Jahren. Ist das Thema noch relevant - oder gehören Container ohnehin schon zum Standard in der IT?
Markus Eisele: Container als Technologie gibt es schon sehr lange. Chroot-Umgebungen wurden schon 1979 erfunden. Namespaces und die Prozess-Container (cgroups) sind 2006 dazugekommen. Aber erst um 2013 haben Container in der heutigen Version stark an Popularität gewonnen. Und Container allein lösen auch noch nicht die Aufgaben der Orchestrierung oder Verteilung. Folglich hat auf alle Fälle noch Kubernetes für eine nutzbare Gesamtlösung gefehlt. Kubernetes kam erst vor knapp vier Jahren dazu und wurde mittlerweile tatsächlich zur Grundlage moderner Software-Entwicklung. Die Container-Technologie entwickelt sich immer noch rasant weiter und bietet immer mehr Vorteile durch einen Rechenzentren- und Cloud-übergreifenden Betrieb. Die Antwort auf die Frage lautet also: Standard ja, aber altes Eisen noch lange nicht.
com! professional: Container bringen Unternehmen eine Menge Vorteile … Wieso setzen dann nicht schon längst alle auf diese Technologie? Mit welchem Anteil von Container-Lösungen können wir in Zukunft rechnen?
Eisele: Wir haben in den vergangenen Jahren in der IT gesehen, dass unser Werkzeugkasten einem extrem schnellen Wandel unterworfen ist. Wir haben viele neue und spezialisierte Werkzeuge dazubekommen, um aktuelle Anforderungen besser, schneller und kostengünstiger zu erfüllen. Es ist zunehmend zu beobachten, dass Unternehmen sich nicht mehr von Plattform-Entscheidungen treiben lassen, sondern bestrebt sind, die wirklich wichtigen Fragen nach der optimalen Lösung für einzelne Herausforderungen zu beantworten. Welche prozentualen Anteile dabei Container-basierte Anwendungen haben werden, bleibt abzuwarten.
com! professional: Ein hartnäckiger Mythos bei Containern ist, dass sie virtuelle Maschinen obsolet machen. Viele Anwendungen, die früher in virtuellen Maschinen liefen, könnten in einen Container verschoben werden. Das ist aber nicht immer sinnvoll, oder?
Eisele: Für mich ist es weniger eine Frage nach der technischen Machbarkeit als vielmehr nach der fachlichen Sinnhaftigkeit. Es gibt nur sehr wenige technische Fälle, in denen ein Wechsel von Virtualisierung zu Containern nicht möglich ist. Die viel drängendere Frage ist aber der tatsächliche Modernisierungsbedarf. Helfen mir die alten Anwendungen überhaupt auf meinem Weg hin zur digitalen Transformation? Falls dies nicht der Fall ist, dann ist auch ein einfaches Umstellen der Plattform-Technologie nicht mehr sinnvoll. Dann ist eine konsequente Modernisierung der richtige Weg.
com! professional: Sind Microservices die technische Voraussetzung für Container oder lassen sich auch größere Funktionsblöcke hineinpacken?
Eisele: Nein, sicherlich keine Voraussetzung, aber sie sind ein sehr guter Weg, um die Flexibilität und Mehrwerte von Container-Plattformen voll auszuschöpfen. Natürlich kann man auch große Monolithen in Container stecken und betreiben. Nachdem diese in Design und Betrieb aber vielfach auf statusbehafteten Transaktionen aufgebaut sind, wird eine schnelle Skalierung und die Abbildung auf eine statuslose Infrastruktur eine größere Herausforderung. Auch sind die Monolithen vielfach darauf ausgerichtet, eine lange Zeit eine sehr hohe Anzahl an Anfragen zu beantworten, was im Gegensatz zu kurzlebigen und schnell skalierbaren kleineren Services steht. Um es mal bildlich zu beantworten: Ja, eine Anakonda kann ein Pferd verschlingen, es wird aber komisch aussehen und lange dauern.
com! professional: Wie sieht das in der Praxis aus: Wie und mit welcher Technologie lassen sich Container am einfachsten verwalten? Und wie behalte ich als Unternehmen den Überblick?
Eisele: Hier gibt es mehrere Ebenen zu beachten. Bisher habe ich von Container-Plattformen gesprochen und damit war irgendwie auch immer Kubernetes als Orchestrierungsebene gemeint. Im tatsächlichen Betrieb ist dies also die direkte Antwort auf die Frage nach der Verwaltung. Die Container benötigen aber auch eine „Beschreibung“, also etwas, was quasi als die Blaupause für den auszuführenden Service fungiert. Hier sprechen wir von den sogenannten Images, die Namen und Versionen haben und in Registries verwaltet werden. Für Unternehmen mit vielen dieser Images bedarf es deutlich mehr als nur einer einfachen Registry. Hier müssen also neben den technischen Möglichkeiten auch Prozesse und Vorgehensweisen eingeführt werden, um die Anzahl beherrschbar zu machen.
com! professional: Dabei eignen sich Container doch vor allem für Multi-Cloud-Umgebungen …
Eisele: Wenn wir von Containern sprechen, meinen wir meistens die tatsächlich ausgeführte Instanz, also einen laufenden Prozess. Die Definition erfolgt in den Images. Und genau diese Beschreibung wird von der Container-Plattform gelesen und in einem Container instanziiert. Für die Themen Hybrid- und Multi-Cloud sind aber mehrere Ebenen relevant. Zunächst ist festzuhalten, dass die Images herstellerübergreifend als OCI-Standard (Open Container Initiative) definiert sind, das heißt, ein gleichwertiger Container kann herstellerübergreifend auf allen Container-Plattformen betrieben werden. Mit diesem Schritt wird aber keine Dynamik beim Ausführen der Anwendungen ermöglicht, sondern nur eine Herstellerbindung vermieden.
Besser wäre es natürlich, wenn eine Container-Plattform aufgrund von Laufzeitinformationen entscheiden könnte, in welcher Cloud welche Container ausgeführt werden. So könnten etwa bei einer Spitzenlast am „Black Friday“ zusätzliche, temporäre Ressourcen hinzugefügt werden, während im normalen täglichen Betrieb nur die im eigenen Rechenzentrum bereitgestellten Ressourcen genutzt werden. Und genau diese Ebene ist die hohe Kunst von hy­bridfähigen Container-Plattformen. Nur die wirklich guten unterstützen alle drei großen Cloud-Anbieter und können auch den Betrieb von kritischen Teilen im eigenen Rechenzentrum abdecken.
com! professional: Welche Rolle spielt Container as a Service (CaaS)? Ist das die Zukunft - Services statt es selbst zu machen?
Eisele: Mit CaaS wird quasi die Ablaufumgebung für Container, also die Container-Plattform, von einem Cloud-Anbieter bereitgestellt und muss nicht im eigenen oder gemieteten Rechenzentrum aufgebaut werden. Als Unternehmen spart man sich den Betrieb und die Bereitstellung der Plattform. Je nach Anbieter sind hier Fallstricke verbaut, auf die man achten muss. Aber prinzipiell ist dies in meinen Augen der optimale Weg, vor allem für den Mittelstand. Lediglich bei der Auswahl der Lösung sollte ein Unternehmen darauf achten, ob es wirklich nur ein gehostetes Kubernetes braucht oder ob eine voll hybridfähige Container-Plattform nicht viel eher die Anforderungen erfüllt.
com! professional: Vor allem das Thema Sicherheit treibt Unternehmen um. Alle Container eines Systems teilen sich die Kernfunk­tionen und die Schnittstellen des Betriebssystems für den Hardware-Zugriff …
Eisele: Sicherheit ist eines der wirklich komplexen Themen bei Container-Plattformen. Grundsätzlich nutzen Container die vom Betriebssystem Linux bereitgestellten Funktionen (Namespaces, cgroups und chroot), um einen abgesicherten Bereich zu ermög­lichen. Zusätzlich wurde in den vergangenen Jahren in diversen Projekten daran gearbeitet, die Menge der für Container zugreif­baren System-Calls stark zu reduzieren.
Auch ist es dringend empfehlenswert, darauf zu achten, dass Container nicht mit Root-Usern betrieben werden. Ein Ziel von Container-Plattformen ist vielfach, den Zugriff aus einem Container heraus auf den Host und damit gegebenenfalls auf andere Ressourcen zu verhindern.
com! professional: Wer es schafft, an die Hardware zu kommen, der kann auf alle Container zugreifen?
Eisele: Wer einen physikalischen Zugriff auf das Host-Betriebssystem bekommt und sich dank Konfigurationsfehlern oder fehlender Sicherheits-Patches am System anmelden kann, hat auch die Möglichkeit zur Schadensverursachung. Allerdings besteht diese Gefahr auch bei bisherigen Technologieansätzen. Auf jeden Fall ist im Container-Bereich die unverzichtbare Grundlage ein absolut zuverlässiges und sicheres Linux.
com! professional: Vor allem im DevOps-Bereich ist die Sicherheit bei Containern ein Thema: Das Operations-Teams hat die Aufgabe, Sicherheitslücken in Produktivumgebungen zu finden. Dabei ist es in der Praxis aber häufig sehr schwierig, Komponenten und Abhängigkeiten in Container-Images zu überblicken. Wie lässt sich das lösen?
Eisele: Bei der Sicherheit müssen prinzipiell mehrere Ebenen beachtet werden: vom Host-Betriebssystem über die Basis-Images für die Container und die verwendeten Bibliotheken und Abhängig­keiten bis hin zur eigentlichen Container-Plattform mit den darin enthaltenen Teilen. Ohne ein komplettes Konzept, das all diese Ebenen berücksichtigt, ist der Fokus auf Container-Images nicht viel wert.
com! professional: Und welche Veränderungen bringen Container beim Patch-Prozess mit sich?
Eisele: Container an sich sind „unveränderbar“. Das heißt, ein einmal definierter Container wird immer wieder von der Basiskonfiguration gestartet und es ist nicht ratsam, eine ausgerollte Version im klassischen Sinn zu patchen. Dabei ist auch zu berücksichtigen, wie neue Container-Versionen sich auf der Infrastruktur verteilen und vor allem mit welcher Geschwindigkeit. Insgesamt ist es wesentlich effizienter, einen Container neu aufzusetzen statt ihn zu patchen.
Verwandte Themen