Containerbetrieb im RZ, Teil 1
Die Zeit ist reif für Container
Als im letzten Jahrzehnt die Virtualisierung von x86-Servern ihren Durchbruch schaffte, hatte fast niemand den Siegeszug software- definierter Umgebungen auf dem Radarschirm. Virtualisierung erlaubte den Administratoren über Typ-1- und Typ-2-Hypervisoren die filigrane Zuordnung der Betriebssystem-Ressourcen für eine Vielzahl von VMs. Genau dieser Trend lässt sich Jahre später nun auch für Softwarecontainer erkennen.
Ursprünglich konzipiert für den Einsatz von relativ kleinen, zweckorientierten, meist statuslosen Micro-Services, haben sich Container durch das von der Firma Docker geschaffene Container-Ökosystem über die Anwendungsentwicklungsabteilung und Public Clouds still und heimlich auch im klassischen Datacenter ausgebreitet. Genau wie seinerzeit Virtualisierung hat auch die Containerisierung Auswirkungen auf verschiedenste Bereiche. Die wichtigsten Aspekte sind:
- Menschen (vor allem Entwickler und Administratoren),
- Architektur (der Anwendungen und der Systeme) sowie
- Infrastruktur (Betrieb und andere operationale Aspekte).
Entwickler erhalten aufgrund ihrer Containerisierungs-Skills verstärkt auch einen dezentralen Administrationsauftrag, während Administratoren wiederum mittlerweile auch verteilte Anwendungsarchitekturen mit Containern verstehen müssen. In puncto (Anwendungs-)Architekturen laufen neue Artefakte basierend auf Cloud-nativen Micro-Services, entwickelt nach den Twelve-Factor-Regeln (empfohlene Best Practices für die Entwicklung von Cloud Apps), als Stateless- oder Stateful-Anwendungen in Containern und diese in ephemeren (nur zur Laufzeit existierenden) "Pods". (Hyperkonvergente) Infrastrukturen schließlich bilden heute die skalierbare und hochverfügbare Grundlage für Container und VMs, sodass man Cloud-portable Anwendungen in Containern dynamisch zwischen den Server-Nodes verschieben kann.
Fachleute sehen Container mittlerweile vielfach als Nachfolger oder sogar Ersatz der Server-Virtualisierung. Beide Ansätze können sich allerdings hervorragend ergänzen. Sie müssen es sogar. Aber helfen Container - dem früheren Anspruch an VMs folgend - tatsächlich, Ressourcen zu sparen? Container haben abgespeckte universelle Basis-Images (UBIs), die nur das beinhalten, was man als Laufzeitumgebung in einem Betriebssystem wirklich benötigt. Auch bei der Entwicklung von Micro-Services legen Entwickler - zumindest in einer idealen Welt - Wert auf einen "schlanken Service", der gemäß Twelve-Factor-Charakteristika nur genau das bietet, was er soll.
Trotzdem bestehen moderne Anwendungslösungen, die auf Containern implementiert sind, nicht selten aus Dutzenden von Images, lautet doch eine goldene Twelve-Factor-Regel: Pro Container nur ein Micro-Service. Durch die resultierende hohe Anzahl an Services wachsen auch die Zahl und die Versionsstand-Vielfalt der Container, die zu orchestrieren sind, beispielsweise durch PaaS-Umgebungen (Platform as a Service) wie CloudFoundry oder CaaS-Konzepte (Containers as a Service) wie Kubernetes.
Einführung und Updates
Containerisierung ist jedoch nicht nur Docker, und Containerorchestrierung ist nicht nur Kubernetes oder CloudFoundry. Denn auch so wichtige Gebiete wie Netzwerk- und Speicher-Management fordern den Administrator dieser Container-Orchestrierungsplattformen. Zu Einführung und Betrieb von Containerplattformen existieren mittlerweile viele Artikel und Bücher. Zunächst eroberten die ersten Containerplattformen wie Red Hat OpenShift, Suse CaaS, Rancher und Pivotal PKS (Kubernetes-basierte Derivate) sowie Pivotal PCF, IBM CF oder SAP CF (CloudFoundry-basierte Derivate) den Markt. Doch dann trat eine gewisse erste Ernüchterung ein, insbesondere bezüglich Migration und Updates von Containerplattformen. Befragt man beide Seiten von DevOps (die Developer und die Operations-Verantwortlichen, also die Administratoren), stößt man auf unterschiedliche Meinungen: Entwickler arbeiten immer gerne mit den neuesten Tools und Versionen, Administratoren hingegen wünschen sich lieber erprobte und bewährte Versionsstände.
Ein Risiko in diesem Kontext ist der sogenannte "Container-Sprawl", also das sprunghafte Ansteigen der Versionsstände einer Service-Funktion. Das "Taggen" und "Einchecken" von Container-Image-Versionen in ein Artefakte-Repository (etwa Artifactory, Nexus, Gitlab oder Bitbucket) ist unabdingbar, um die Übersicht nicht zu verlieren. Verschiedene Versionen von Services entstehen und fast alle Software-Entwicklungsabteilungen wollen oder müssen (je nach Regularien der jeweiligen Branche) diese Versionen zu Revisionszwecken aufbewahren. Daher ist es wichtig, die Container-Images mit möglichst aussagekräftigen Tags und Metadaten zu versehen und Versionen zu den jeweiligen Stadien eines Projekts im richtigen Repository-Zweig abzulegen.
Bei der Paketierung helfen containerspezifische Paketierungswerkzeuge wie Helm-Charts, Operatoren oder CloudPaks. Helm ist ein von Google entwickeltes und nun zur CNCF (Cloud Native Computing Foundation) gehörendes Tool zum einfachen Installieren, Ausrollen, Publizieren, Skalieren und Verwalten vorkonfigurierter Kubernetes-Anwendungen. Operatoren wiederum sind eine relativ neues Konzept, um Kubernetes-native Anwendungen zu paketieren, auszurollen und über Kubernetes-APIs zu verwalten. Operatoren sind permanent laufende, softwarebasierte Controller, die den gewünschten Zielzustand von Kubernetes-Objekten erreichen und diesen dann über die Laufzeit halten und überwachen. CloudPaks schließlich sind eine neue Methode, um Versionsstände von Anwendungspaketen kontrolliert auf Containern auszuliefern. Ein CloudPak beinhaltet einen getesteten Versionsstand aller erforderlichen Komponenten in Containern, inklusive aller auf Sicherheitslücken geprüften und zertifizierten Container-Images. Die vordefinierten Pakete herstellerzertifizierter und -unterstützter Lösungskomponenten mit Lebenszyklus-Management fördern die Zusammengehörigkeit von Container-Images und deren Versionierung für ganzen Lösungspakete. Ein CloudPak umfasst:
- Vorbereitungs- und Nachbereitungsskripte (Pre- und Post-Deployment Scripts),
- Provisionierungsmethoden, beispielsweise Helm Charts oder Operatoren als Kubernetes-CRDs (Custom Resource Definitions),
- die Einbindungen in Monitoring- oder Logging-Tools und entsprechende Dashboards,
- die Integration in Service-Kataloge zum Beispiel über Open Service Broker sowie
- eine standardisierte und vollständige Dokumentation.
Containerplattformen sind Update- und wartungsintensiv, will man sie immer auf dem neuesten Stand halten. Gerade bei Kubernetes erblickt fast jedes Quartal ein neues Release oder eine neue Version das Licht der Welt. Mittlerweile bieten fast alle Hersteller gute Update-Funktionen mit Rollback-Möglichkeiten, aber trotzdem entscheiden sich immer noch viele Administratoren für das "Blue/Green"-Deployment statt eines "Inline-Upgrades". Beim Blue/Green-Ansatz provisioniert das IT-Team Anwendungen in Containern auf zwei getrennten, aber ansonsten gleichartigen Container-Clustern. Man baut also einen weiteren Container-Cluster in der neuen Version auf und überträgt die containerisierten Anwendungen in den neuen Cluster. Zwar lässt sich der netzwerkfähige persistente Storage problemlos übernehmen, aber der Parallelbetrieb erfordert weitere Server-Resourcen und Netzwerksegmente (VLANs) für die "Worker Nodes", auf denen die containerisierten Anwendungen laufen. Das Inline-Upgrade hingegen findet auf einem laufenden Container-Cluster statt. Hier startet der Administrator - je nach Distribution und Hersteller des Container-Clusters - den Update-Vorgang; der Prozess tauscht dann "unter der Decke" die alten Containerversionen gegen neue aus.
Beide Verfahren haben ihre Vor- und Nachteile, je nachdem, welche nicht-funktionalen Anforderungen einzuhalten sind. So ist beispielsweise bei einem kleineren Container-Cluster (mit bis zu zehn Nodes) der parallele Neuaufbau der neuen Container-Cluster-Version einfacher als bei einem sehr großen und skalierbaren Cluster mit Dutzenden oder gar Hunderten von Nodes. Mit in den neuen Container-Cluster übernehmen muss man bei einem parallelen, neu aufgebauten Container-Cluster auch die entsprechenden Management-Anwendungen wie Logging, Monitoring, Metering, Auditing und Security-Scanning, soweit diese als Management-Dienste im zu aktualisierenden Container-Cluster laufen. Doch wie lässt sich ein Container-Cluster schnell, automatisiert und ohne manuelle Eingriffe bereitstellen? Neben den bekannten Automatisierungs-Tools für die Bereitstellung des IaaS-Layers (Infrastructure as a Service) wie Terraform, RedHat CloudForms, Ansible, Bosh und VMware vRealize Automation sind hier auch HCI-Systeme (Hyperconverged Infrastucture) ein beliebtes Verfahren.
Betrieb auf HCI-Systemen
Integrierte Systeme, die auf HCI-Technik basieren, haben sich mittlerweile als Teil der softwaredefinierten IT-Infrastruktur im Datacenter etabliert. Mit redundanten Standardkomponenten aus x86-Servern, virtualisierbaren Netzwerk- und Speicherbausteinen sowie Hypervisor-basierter Virtualisierung eignen sich HCI-Systeme sehr gut als Infrastrukturbasis für containerisierte Workloads. Zwar sollten vor vielen Jahren Container auf Bare-Metal-Servern die klassische Virtualisierung gezielt vermeiden, doch heute sind die meisten Kubernetes- und CloudFoundry-Implementierungen auf VMs anzutreffen - und das aus gutem Grund: Dank Virtualisierung lassen sich die Resourcen genau so einteilen, wie man es für eine skalierbare und mandantenfähige Implementierung einer Container-Orchestrierungsplattform ("Hyperconverged Kubernetes") benötigt. So kann das IT-Team den verschiedenen Mandanten oder Abteilungen genau die richtigen Ressourcen für deren Anwendungen in Containern bereitstellen.
Beispiele sind die Größe und Anzahl der Worker Nodes, eingeteilt in Node Groups, Proxy oder Router Nodes in speziell abgeschirmten Netzwerksegmenten oder dedizierte Container Storage Nodes mit Containern speziell für den Aufbau von persistentem Speicher auf Cluster-Dateisystemen, Message Queues oder verteilten Datenbanken. Je einfacher die softwaredefinierten Komponenten auszuwählen sind, desto effizienter lässt sich eine Container-Orchestrierungsplattform mandantenfähig verwalten.
Moderne Cloud-Native-Anwendungen passen daher ideal auf HCI-Systeme, weil diese Anwendungen in Containern sehr granular und komponentenreich mehrere Funktionen der Orchestrierungsplattform beanspruchen. Wo Entwickler viele Resourcen granular allokieren, ist eben ein flexibler Unterbau erforderlich.
HCIs vereinen alle wichtigen Kriterien, die gerade für eine Cloud-Plattform so wichtig sind: Skalierbarkeit, Redundanz, Virtualisierung, softwaredefinierte Strukturen (Netzwerk, Speicher) und die Isolierung sogenannter "Noisy Neighbors" (Instanzen, die Ressourcen monopolisieren, sodass die Performance anderer Instanzen leidet). Kubernetes umfasst Schnittstellen wie CNI (Container Networking Interface) und CSI (Container Storage Interface), um die HCI-internen Speicher- und Netzwerkressourcen direkt einzubinden. Der Virtualisierungs-Layer und die HCI-System-Management-Software bieten die notwendigen Templates, um einen oder mehrere Container-Cluster in vordefinierten Topologien auszurollen und zu betreiben.
Virtuell, containerisiert, Serverless
Softwarecontainer ermöglichen eine effiziente Nutzung der Systemressourcen. Containerisierte Anwendungen verbrauchen meist deutlich weniger Hauptspeicher als virtuelle Maschinen, da ihr Betriebssystem viel kleiner und bedarfsorientierter erstellt ist - nämlich nur mit dem, was die Anwendung an "Laufzeit-Stack" benötigt. Container lassen sich durch optimierte Container-Engines schneller starten und stoppen und viel dichter auf eine Host-Hardware packen - vorausgesetzt, die containerisierten Anwendungen haben keinen großen Ressourcenhunger oder beenden sich, wenn man sie nicht mehr benötigt.
In Summe arbeiten Container im Gesamtkontext deutlich ressourcenschonender und effizienter als virtuelle Maschinen und die Möglichkeiten der Skalierbarkeit sind deutlich höher. Nicht selten versprechen Hersteller von Enterprise-Container-Orchestrierungsplattformen eine getestete Skalierbarkeit bis weit in die zehntausende Container.
Ein weiteres Konzept, Ressourcen in einem Container-Cluster zu sparen, bieten Serverless-Computing-Frameworks, wie das auf Kubernetes basierende Knative oder Apache OpenWhisk. Ziel dieses FaaS-Ansatzes (Function as a Service) ist es, Funktionen temporär nur dann im Container auszuführen, wenn Ereignisse sie auslösen. Dann starten solche Frameworks einen Container in einem Bruchteil der Zeit eines VM-Starts und beenden ihn ebenso schnell wieder - auch hier mit dem Ziel, gegenüber VMs nur einen Bruchteil der Ressourcen in geringer Zeit zu verbrauchen.
Serverless-Konzepte profitieren daher vom sehr schnellen Start- und Stop-Verhalten schlanker Container und entlasten die Server-Resourcen. Gerade Knative vereint sowohl die Containertechnologie als auch Serverless-Architektur. Die Software kann für bedarfsgerechte Skalierung sowohl hoch skalieren, als auch auf null Instanzen zurückskalieren, wenn die Funktionen nicht mehr laufen. Das bedeutet die Beendigung eines Kubernetes-Pods und damit auch die Freigabe der Server-Resourcen.
Teil 2 dieses Beitrags befasst sich unter anderem mit der Anwendungsmigration von VMs in Container, den Stolperfallen des Containerbetriebs, Sicherheitskonzepten und Cloud Bursting. Er ist unter Link abrufbar.
Lesen Sie mehr zum Thema
