Aus Kubernetes wird Container as a Service

Die IT-Abteilungen müssen sich jetzt darauf vorbereiten, den Schritt zu Container-Umgebungen in den nächsten Jahren zu vollziehen.“ So lautet die deutliche Ansage von Marc Kleff, Director Solutions Engineering beim Datenspeicher-Spezialisten NetApp. Langfristig rechnet er damit, dass Container den Großteil der Anwendungen abdecken.

Die sogenannte Containerisierung gilt als einer der bedeutendsten Umbrüche in der IT-Welt: gekapselte Anwendungen, die unabhängig voneinander ausgeführt werden - ganz egal wo sie sich gerade befinden. Das erleichtert vor allem den IT-Abteilungen die Arbeit ungemein. So stehen Unternehmen in Sachen Digitalisierung momentan unter einem enormen Erfolgsdruck, der vor allem die Anforderungen an die IT-Abteilungen hochschraubt. Mit Containern lassen sich neue Anwendungen und Dienste schnell und flexibel zur Verfügung stellen.

Doch trotz aller Vorteile der Container-Technologie, zum Standard gehören sie in den Unternehmen bislang nicht. Stephan Michard, Senior Systems Engineer bei Dell Technologies, bestätigt dies: „Unsere Gespräche mit Unternehmen zeigen, dass viele noch nicht in der Lage sind, Container-Applikationen zu betreiben.“

Die Containerisierung spielt derzeit vor allem in der Planung von neuen Software-Systemen eine große Rolle, so die Erfahrung von Simon Fleischer, Teamleiter Software Engineering bei der IT-Beratung Consol. Architekten und DevOps-Ingenieure würden ihren Einsatz häufig in der Konzeptionsphase erwägen. Allerdings müssten Container nicht in jeder Umgebung die beste Wahl sein und oft sei es wirtschaftlich nicht sinnvoll, jedes Altsystem in Container umzuziehen. „Man kann also sagen, dass Container längst ‚angekommen‘ und reif für den Produktiveinsatz sind. Von einer flächendeckenden Durchdringung zu sprechen, wäre jedoch übertrieben.“ Aber: „Viele Unternehmen nutzen bereits Container und wissen es gar nicht, denn viele Produkte aus dem Bereich Software as a Service setzen im Hintergrund auf Containern auf.“

Zu einem ähnlichen Ergebnis kommt die aktuelle Studie „Container in der IT und ihr Potenzial in deutschen Unternehmen“ des IT-Dienstleisters Cronon und der Analysten von Techconsult: Für 38 Prozent der Unternehmen, die Container im Einsatz haben oder dies planen, stellt das mangelnde Know-how über die Technologie ein Hemmnis dar und erschwert die Implementierung, „weshalb in solchen Fällen eher auf altbewährte und sogar veraltete Konzepte zurückgegriffen wird“. Die Vorteile von Containern haben die Unternehmen aber erkannt: 78 Prozent halten es für wahrscheinlich, dass Container-Technologie künftig ein fester Bestandteil ihrer IT-Landschaft sein wird.

„Technisch gesehen sind Container eine logische Weiter­entwicklung diverser Innovationen im Linux-Kernel wie Cgroups oder Namespaces über das letzte Jahrzehnt. Dazu kommt die Etablierung von Kubernetes und einem ganzen Ökosystem von Projekten“, so Björn Brundert, Principal Solution Engineer Application Platforms beim Cloud- und Virtualisierungs-Spezialisten VMware. Bei Kubernetes handelt es sich um ein ursprünglich von Google entwickeltes und inzwischen als Open Source zur Verfügung stehendes Tool zur Automatisierung der Bereitstellung, Skalierung und Ver­waltung von Container-Anwendungen. Kubernetes hat sich mittlerweile als Standard für die Verwaltung von Containern etabliert.

Während Kubernetes und Containerisierung große Vorteile mit sich bringen können, braucht deren Realisierung, wie es bei jeder neuen Technologie der Fall ist, jedoch ihre Zeit. Der technische Reifegrad, das Ökosystem an Tools und nicht zuletzt auch das vorhandene Wissen, zum Beispiel bei den Entwicklern, sind hier nur einige Faktoren. Kubernetes ist zwar eine komplexe Software, die es Nutzern einfacher macht, verteilte Systeme zu bauen - „aber nicht jede Anwendung eignet sich hierfür beziehungsweise die Verwendung kommt erst in einem neueren Release von Kubernetes infrage“, schränkt Björn Brundert ein.

Mit zentralen Updates alle drei Monate schaffe Kubernetes jedoch zunehmend neue Möglichkeiten und decke neue Anwendungsfälle ab.

Auch laut Marc Kleff von NetApp hat sich Kubernetes als Quasi-Standard im Bereich der Container erfolgreich durchgesetzt: „Die Lösung ist komplex, bietet aber auch einen sehr großen Mehrwert und eine hohe Entwicklungsgeschwindigkeit. Da viele Alternativen nicht mithalten konnten, wurden sie bereits von Kubernetes verdrängt.“

Dabei ist Kubernetes allerdings kein Allheilmittel und schon gar keine eierlegende Wollmilchsau: Zwar nimmt Kubernetes den DevOps-Teams die meiste Arbeit ab, wenn es um Orchestrierung und Management geht, aber einen kompletten Überblick erhält man erst durch ein vernünftiges Monitoring. Hierfür eignen sich zum Beispiel die Tools Prome­theus und Grafana. Letztlich erfordert ein erfolgreiches Container-Management aber ein ganzes Potpourri unterschied­licher Tools, zum Beispiel für den sicheren Zugriff auf Datenbanken oder andere Unternehmens-Services.

Früher war vor allem das Container-Verwaltungs-Tool Docker beliebt. Auch wenn dessen Bedeutung schwindet, so ist es in den Unternehmen doch weiterhin vertreten: „Gerade beim Evaluieren neuer Software und solange es sich nicht um eine reine Microsoft-Umgebung handelt, gehört Docker für Entwickler zum Standard“, berichtet Frank Haumann. Er ist Partner beim Cloud-Dienstleister Red Reply. Vermehrt sehe er Docker in produktiven Umgebungen und bei Kunden, die versierter im Umgang mit der CI/CD-Pipeline (Continuous Integration and Continuous Delivery) sind. Doch je größer die Installationen seien, desto häufiger treffe man auf das Container-Management-Framework Kubernetes, „das sich verstärkt zum Standard entwickelt und ältere Frameworks wie Cloud Foundry, Apache Mesos oder Docker Swarm ablöst“. Haumann unterstreicht: „Ohne Kubernetes sind Lösungen mit mehreren Hundert Containern nicht mehr wirtschaftlich und sicher zu betreiben.“ Kubernetes bringe aber auch eine Komplexität mit sich, die Operations-Teams vor Herausforderungen stelle. Aus diesem Grund wanderten viele Kubernetes-Installationen als Managed Kubernetes in Private oder Public Clouds.

Häufig hört man, dass Container sogar virtuelle Maschinen (Virtual Machines, VMs) obsolet machen. Virtualisierung und Container zu vergleichen ähnelt jedoch dem sprichwörtlichen Vergleich von Äpfeln und Birnen. VMs stellen (virtualisierte) Hardware bereit. „Das eröffnet Unternehmen ab ‚Oberkante Hardware ‘ alle Freiheiten, zum Beispiel bei der Wahl des Betriebssystems“, erklärt Thomas Franz. Er leitet den Technologiebeirat beim IT-Dienstleister Adesso. Container-Umgebungen hingegen arbeiteten auf einem Betriebssystem, das für eine bestimmte Hardware-Architektur konzipiert sei. Diese unterschiedlichen Freiheitsgrade hätten Folgen, positive wie negative. Deswegen, so Franz weiter, könne ein Container nicht automatisch auf jeder Hardware-Architektur oder jedem Betriebssystem betrieben werden. Dieser Nachteil spiele in der Praxis jedoch seltener eine Rolle, „da häufig einheitliche Betriebssysteme und Hardware-Architekturen genutzt werden“. Für Projekte im IoT-Umfeld sei dies allerdings schon relevanter. So sei ein Container zum Beispiel für einen Intel-basierten Server nicht ohne Weiteres auf einem Raspberry Pi einsetzbar.

Viele Anwendungen, die früher in virtuellen Maschinen liefen, lassen sich grundsätzlich in einen Container verschieben. Wenn man aber irgendwelche existierenden Applikationen ohne eine Anpassung in Containern betreibt, dann fügt das diesen Applikationen erst einmal keine neuen Funk­tionen hinzu. Anders ausgedrückt: „Eine nicht skalierbare Single-Instance-Applikation ist auch nach der Containerisierung keine cloudnative Scale-Out-Applikation.“ Es gibt laut Björn Brundert von VMware diverse Applikationen, die sich für eine einfache Umwandlung in einen Container eignen. Die technische Komplexität müsse aber teilweise sehr individuell betrachtet werden. Als Beispiel nennt er Anwendungen, die etwa über keine integrierten Backup-Mechanismen verfügen und daher von externen Backup-Tools abhängig sind. Weitere Fragen seien, ob eine Applikation überhaupt auf dem Betriebssystem unterstützt werde, das der Container-Runtime zugrunde liegt. Oder wie werden Updates an der Applikation gemacht, nachdem sie containerisiert wurde? All diese und noch etliche andere Themen müssten auf jeden Fall be­rücksichtigt werden, soll eine Migration erfolgreich sein.

IT-Abteilungen sollten also die beiden Technologien - sprich virtuelle Maschinen auf der einen und Container auf der anderen Seite - nicht gegeneinander ausspielen: Es sei kein Oder, sondern ein Und, wie Stephan Michard von Dell betont. „Beide Technologien stellen verschiedene Möglichkeiten der Virtualisierung dar und haben ihre jeweilige Berechtigung und ihre Vorzüge - je nach den Anforderungen, die an eine Applikation gestellt werden.“ Für virtuelle Maschinen existierten bewährte Management- und Orchestrierungs-Tools, und so lange es keine extremen Anforderungen an eine hohe Skalierbarkeit oder sehr kurze Entwicklungszyklen gebe, ließen sich Applikationen auch gut über virtuelle Maschinen bereitstellen.

Felix Grundmann zufolge, Head of Product Management beim Provider Ionos, gibt es durchaus auch Gründe, virtuelle Maschinen gegenüber Containern vorzuziehen. Dies sei der Fall, wenn man beispielsweise einen Custom-Kernel betreiben, das Gast-Betriebssystem wählen oder eine bestimmte Hardware simulieren wolle. Hinzu komme die bessere Isolierung und Sicherheit, aber auch die Möglichkeit, Work­loads ohne Ausfallzeit „live“ zu migrieren. „Vermutlich lassen sich nahezu alle Anwendungen umbauen, um in Containern zu laufen“, ergänzt er. Aber: „Technisch gibt es noch Gründe, dass dies nicht immer sinnvoll sein muss.“

Doch wie sehen Anwendungen in Containern eigentlich aus? Im Zusammenhang mit Containern ist häufig von Microservices die Rede. Darunter versteht man Dienste, die jeweils eine kleine Aufgabe erfüllen. Die Microservices lassen sich über Schnittstellen so miteinander verbinden, dass sich daraus eine beliebig komplexe Software ergibt. Darüber hinaus sind die einzelnen Funktionsblöcke je nach Nutzung und Auslastung unabhängig voneinander skalierbar. Die beiden Haupteigenschaften von Microservices sind dabei Spezialisierung und Eigenständigkeit. So beschränkt sich jeder Dienst auf die Lösung eines bestimmten Problems - und arbeitet dabei eigenständig: Jeder dieser kleinen Dienste lässt sich bereitstellen, betreiben und skalieren, ohne die Funktionsfähigkeit anderer Services zu beeinträchtigen.

Aus technischer Sicht besteht jedoch zwischen Microservices und Containern kein direkter Zusammenhang. So lassen sich auch komplette monolithische Applikationen mit Hilfe von Containern betreiben. Doch gerade in Anbetracht einer möglichen Skalierung beziehungsweise einer effizienten Nutzung der IT-Infrastruktur ist das manchmal nicht unbedingt sinnvoll.

Ähnlich sieht es Wolfgang Kurz, CEO beim IT-Dienstleister Indevis: „Natürlich kann man auch größere Blöcke in Container packen. Allerdings verfehlt man dann etwas den ursprünglichen Gedanken, für jeden Task einen Container zu haben, der dann im Idealfall ‚state­less‘ ist und im Bedarfsfall einfach häufiger gestartet wird.“ Wolle man beispielsweise eine große SQL-Datenbank in einem Container betreiben, dann stelle sich die Frage, warum sie in einem Container laufen sollte. „In klassischen Infrastrukturen hat man das Thema des persistenten hochverfügbaren Storage mit hohem I/O, funktionierendem Cluster und Backup-Konzept seit vielen Jahren im Einsatz.“ Wenn man so etwas in einem Container machen wolle, dann sei man schnell im experimentellen Bereich oder müsse sehr viel Know-how selbst aufbauen. Das sei nur für sehr große Firmen oder Cloud-Anbieter sinnvoll.

In einigen Fällen kann es dennoch ratsam sein, auch ganze Applikationen in Container zu packen. Laut Simon Fleischer von Consol hat es sich insbesondere während der Entwicklungsphase bewährt, lokale Dienste wie etwa Datenbanken oder Queue-Server in Containern zu starten, „da auf diese Weise sehr einfach identische Umgebungen für alle Kollegen im Entwicklungsteam erstellt werden können“.

Trotz aller Vorteile - Unternehmen treibt beim Einsatz von Containern vor allem das Thema Sicherheit um. Laut der eingangs erwähnten Studie gaben 38 Prozent der IT-Verantwortlichen an, dass Sicherheitsbedenken ein Grund dafür sind, keine Container im Unternehmen einzusetzen. Und die Bedenken haben auch ihre Berechtigung: Der sichere Betrieb von Container-Workloads ist nicht trivial.

In den Anfangszeiten der Containerisierung liefen diese oft mit Root-Rechten. Dadurch konnte ein Angreifer, der die Sicherheitsmechanismen des Host-Betriebssystems überwand und Zugriff auf die Hardware hatte, gegebenenfalls auch auf die Container zugreifen. Heutzutage liegen laut Marc Kleff von NetApp die Hürden hingegen deutlich höher, da viele Lösungen auf den Root-Zugriff verzichten - „System und Container bleiben getrennt, obwohl diese Trennung nicht so weit wie bei einer Server-Virtualisierung reicht.“ Im Allgemeinen gilt, so Kleff: „Wo aus Sicherheitsgründen eine dedizierte Hardware-Trennung eingeführt wurde, wird man diese jetzt nicht durch einen Mischbetrieb mehrerer Container auf einem Host ersetzen.“

Dass die Sicherheit ein großes Thema ist, das noch längst nicht gelöst ist, betont auch Wolfgang Kurz von Indevis. Ein gängiges Problem sei etwa der Übergriff in Speicherbereiche des Nachbarn. Das gelte unter anderem auch für Teile des Betriebs­systems. „Durch den Einsatz von Containern wird es also keinesfalls sicherer, zumal viele Technologien zum Schutz von Containern noch in den Kinderschuhen stecken.“ Auch wenn alle etablierten Firmen Angebote zum Schutz von Container-Lösungen im Angebot hätten, so seien das oft aus der Virtual-Machine-Welt übertragene Ansätze, die nur teilweise funktionierten. Daher seine Warnung: „Viele Online-Repositories, von denen viele Anwender ihre Container beziehen, sind veraltet und haben eklatante bekannte Sicherheitslücken. Hier muss man im Grunde täglich die Container neu bauen. Solch eine Build Pipeline hat aber nicht jeder im Einsatz, auch wenn sie notwendig wäre.“ 

Vor allem im DevOps-Bereich ist die Sicherheit von Containern ein Thema: Das Operations-Teams hat die Aufgabe, Sicherheitslücken in Produktivumgebungen zu finden. Dabei ist es in der Praxis aber häufig schon schwierig, Komponenten und Abhängigkeiten in Container-Images zu überblicken. 

„Der Überblick über Komponenten und Abhängigkeiten in Container-Images gelingt dort, wo die enge Verbindung von Dev und Ops in einer DevOps-Kultur gelebt wird“, ­betont Marc Kleff. Die Operations-Teams dürften nicht nur auf das Resultat blicken, „sondern müssen bereits im Code-­Repository und beim Quellcode ansetzen. Hier werden die Abhängigkeiten und Komponenten definiert. Dafür können Unternehmen auf fertige Lösungen zurückgreifen.“ GitHub werde beispielsweise automatisch auf Sicherheitslücken in solchen Abhängigkeiten gescannt und der Anwender benachrichtigt.

Von der Cloud Native Computing Foundation - einem ­Projekt der Linux Foundation, um Cloud-Computing, Microservices und Containervirtualisierung zu fördern - gibt es ­eine Reihe von empfohlenen Vorgehensweisen, an denen sich Unternehmen orientieren können. Sinnvoll ist es zum Beispiel, jeweils aktuelle Software-Stände der Container-­Engine und des Orchestrierungssystems einzusetzen oder sensible Work-loads voneinander zu separieren. Das lässt sich umsetzen, indem man etwa Applikationen in getrennten Clustern betreibt.

Bei der Verwendung von Container-Basis-Images sollte man darauf achten, aus welcher Quelle diese stammen. Hier ist es unter Umständen angebracht, entweder einen Anwendungskatalog mit signierten Basis-Images zu verwenden oder auch Container-Images in regelmäßigen Abständen neu zu erstellen. Weitere wichtige Aspekte für einen sicheren Betrieb von Container-Workloads sind das Netzwerk-Design und der Einsatz von Monitoring- und Logging-Systemen.

Container haben auch Auswirkungen auf den Patch-Prozess. So sind Container  typischerweise „immutable“. Das bedeutet: Sie werden nicht kontinuierlich gepflegt, sondern einfach durch neue Container ersetzt. Das erfordert in vielen Fällen neue Software-Build- und -Release-Routinen. „Das bringt bei komplexen Systemen - insbesondere in monolithischen Strukturen - viel Aufwand mit sich, dessen Nutzen sich erst später einstellt und häufig auch nicht vorweg quantifizieren lässt“, ­berichtet Ionos-Produktmanager Felix Grundmann. Bei Containern patcht man also keine Live-Container, sondern die Images in ihrer Container-Registry. „Auf diese Weise kann das vollständig gepatchte Container-Image als eine Einheit ­ausgerollt oder zurückgerollt werden, sodass der Patch-Rollout-Prozess mit seinem - offensichtlich sehr häufigen - Code-Rollout-Prozess identisch wird, komplett mit Überwachung, Canarying und Tests“, erklärt Stefan Schäfer, Head of Global Product Marketing beim ­Hosting-Spezialisten OVHcloud. So werde ein Patch unter Verwendung des normalen ­Prozesses auf vorhersehbare Weise ausgerollt. Eine Alternative  - wenn auch weniger vorteilhaft, da sie nach einem unvorhersehbaren Zeitplan eintritt - sei es, den Rollout ad hoc erfolgen zu lassen. „Wenn ein Container dann das nächste Mal stirbt, dreht Kubernetes einen weiteren Container auf, um dies auszugleichen, und alle Patches, die man angewendet hat, werden auf die Infrastruktur ausgerollt.“ Abhängig von der Lebensdauer der Container sollten diese innerhalb weniger Tage vollständig gepatcht sein.

Die Sache mit den Containern klingt also nicht nur kompliziert - sie ist es auch. Die Integration von Container-Technologien stellt viele, vor allem kleinere Unternehmen vor He­rausforderungen. Die Implementierung und das Management von Containern erfordern entsprechend qualifiziertes IT-Personal, das sich vor allem bei dem einen oder anderen Mittelständler erst einmal einarbeiten muss. Hinzu kommt: Viele IT-Abteilungen sind wie erwähnt bereits durch die zahlreichen Anforderungen in Zuge der Digitalisierung ausreichend ausgelastet.

Die Nutzung von Container-Diensten, Container as a ­Service (CaaS), ist daher eine gute Alternative zum ­Aufbau einer eigenen Container-Plattform. Die Cloud-Angebote stellen die notwendige Infrastruktur und Management-Tools wie Docker oder Kubernetes bereit. „Container-as-a-­Service-Angebote sind prä­destiniert für den schnellen Einstieg, weil Unternehmen damit innerhalb kurzer Zeit mit Container-Applika­tionen bei Public-Cloud-Providern starten können“, meint Stephan Michard von Dell. Michael Armstrong, Projektleiter beim Hosting-Unternehmen Centron, bestätigt das: „Wir können aus Erfahrung sagen: Dieser Bereich wird immer wichtiger. Wir verzeichnen eine konstant steigende Nachfrage nach Container-as-a-­Service-Lösungen - und das ist nur logisch: Die Apps und Services des Kunden sind innerhalb weniger Sekunden verfügbar. Gleichzeitig muss er weder Fachkräfte für Einrichtung und Betrieb vorhalten noch in eine neue IT-Infrastruktur investieren.“

Für NetApp-Engineer Marc Kleff hat der Einsatz von Container as a Service vor allem praktische Gründe: „Wir erleben den Trend, dass Unternehmen in den Bereichen auf Services zurückgreifen, in denen sie durch einen eigenen Betrieb keinen unmittelbaren Mehrwert schaffen.“ Den Mehrwert erbrächten meistens die Applikationen, während die Infrastruktur lediglich ein Mittel zum Zweck sei. „Container-Plattformen als Infrastruktur-Ebene zählen deshalb zu den Anwendungsfällen, die ‚as a Service‘ konsumiert werden können.“

Für Simon Fleischer sind Container as a Service „sicherlich Teil der Zukunft“, aktuell komme es aber noch stark auf den Anwendungsfall an. „Es ist sehr charmant, dass man einfach einen Container bereitstellt und dieser beliebig skaliert werden kann, allerdings fehlt hier in manchen Bereichen noch die Kontrolle.“ Konkret bedeute dies, dass man sich etwa bei erhöhten Sicherheitsanforderungen zunächst besser selbst um das Container-Management kümmern sollte. Auch im Sinne der Multi-Cloud gebe es noch Verbesserungspotenzial, da sich die APIs der Anbieter stark unterschieden.

Eines steht fest: Container sind zwar alles andere als einfach zu betreiben, aber die Vorteile überwiegen und der Trend zur Containerisierung wird weiter anhalten. Doch was kommt als Nächstes? Dell-Engineer Stephan Michard zitiert dazu Mark Twain: „Voraussagen soll man unbedingt vermeiden, besonders solche über die Zukunft.“ Container-Lösungen würden mittel- bis langfristig sicher eine bedeutendere Rolle als bisher einnehmen - einen genauen Anteil vorherzusagen, hält Michard jedoch für schwer möglich.

Für Thomas Franz von Adesso werden sich Container als innovative Technologie etablieren, die viele weitere Entwicklungen beflügelt, „beispielsweise Microservice-Architekturen, Automatisierung von Software-Delivery- und Betriebsprozessen oder ein Homogenisieren dieser Prozesse“. Container sind ihm zufolge inzwischen ein anerkanntes Werkzeug in der IT: „Unternehmen nutzen sie standardmäßig, wenn es um den vereinheitlichten Transport, das Management oder den Betrieb von Software geht.“ Dies zeige etwa das Angebot von Plattformen für das Orchestrieren und das Management von Containern.

Nach Einschätzung von Indevis-CEO Wolfgang Kurz ist auch für die klassische Virtual Machine noch lange kein Ende in Sicht. Es würde noch immer eine Vielzahl physischer Server betrieben. „Gerade wenn es um sehr hohe Performance geht, ist die Hardware-Nähe immer noch entscheidend.“ Der Kosten-Nutzen-Aufwand, um sämtliche Applikationen in Richtung Container zu entwickeln, stehe oft in keinem Verhältnis.

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.

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.

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.

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.

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.

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.