Containerbetrieb im RZ, Teil 2
Containersicherheit und Stolperfallen
Teil 1 dieser Artikelserie (siehe Link) beschrieb die Grundlagen des Containerbetriebs im Unternehmens-RZ, die Vorzüge von Containern gegenüber Virtual Machines sowie im Zusammenspiel mit VMs, ebenso Containerorchestrierung und den Betrieb auf HCI-Systemen (Hyperconverged Infrastructure). Im Teil 2 geht es nun um die Migration von Anwendungen aus VMs in Container, die Stolperfallen im Containerbetrieb sowie um Sicherheitsaspekte und Cloud Bursting.
Um Anwendungen von virtuellen Maschinen (VMs) in Container zu migrieren, muss der Administrator sich zunächst auf eine Topologie für den Container-Cluster festlegen. Anschließend muss er bei der Überführung von Anwendungen von VMs in Container darauf achten, dass Entwickler ihre Flexibilität und die Einfachheit behalten, aber gleichzeitig die nötige Sicherheit dazubekommen. Das Ziel ist es, dass sie ein Ökosystem erhalten, das aus container- und VM-basierten Tools und Anwendungen besteht.
Für den Administratoren selbst gilt es hingegen, durch die Migration den Betrieb und die Automatisierung zu perfektionieren, um so die Komplexität von Containern und VMs in Koexistenz zu beherrschen. Dazu bedarf es System-Management-Tools, die sowohl Container in Pods (Gruppe von Containern, die sich Storage und Netzwerk teilen, d.Red.) als "mortale Einheiten" und VMs als das Herzstück der persistenten Datenhaltung verwalten können.
Die Containerisierung von Anwendungen findet meist durch einen Lift- und Shift-Ansatz statt. Es ist jedoch zu berücksichtigen, dass sich die wenigsten existierenden Anwendungen problemlos in Container transformieren lassen. Meist ist eine Modernisierung in kleinere Teile (Micro-Services nach den 12-Faktor-Regeln) notwendig, wenn nicht sogar erwünscht. Dies ist jedoch kein Hindernis. So hat die CloudFoundry Foundation mit Herstellern wie IBM, Suse, Pivotal und SAP sogar eine PaaS-Lösung (Platform as a Service) wie CloudFoundry mit Dutzenden VMs auf Container migriert (Project Eirini) und das neu entstandene CloudFoundry Enterprise Edition auf Containern in Kubernetes statt auf VMs implementiert.
Containernative Virtualisierungs-Tools
Wenn man Anwendungen zügig und ohne Refactoring - zum Beispiel zu Testzwecken - in einen Container bringen muss, bietet sich die sogenannte containernative Virtualisierung (CNV) an. Einen technologisch neuen Ansatz, eine VM über ein Import-Tool in einen Container zu überführen, bietet etwa RedHat CNV.
Aus dem OpenSource-Projekt KubeVirt bietet RedHat mit CNV auf OpenShift 4.2 (momentan noch im Tech Preview) die Möglichkeit, mittels CNV eine ganze VM in einen Container zu überführen. Die KubeVirt-Operator-Technik erweitert Kubernetes um zusätzliche Virtualisierungstypen, hier den Typ "VM", über Kubernetes Custom Resource Definitions (CRDs). KubeVirt bietet die Verwendung des Kubernetes-APIs, um die VM-Ressourcen wie auch andere von Kubernetes bereitgestellte Ressourcen zu verwalten. Der Import der VM erfolgt über ein Container Data Interface (Container Data Importer, CDI), das das OVA-File der VM in den Container importiert. So lassen sich Anwendungen in VMs ohne Änderungen in die Orchestrierungs-Plattform (OpenShift) einbinden und als Container lauffähig machen.
Stolperfallen im Betrieb von Containern
Container machen VMs jedoch nicht obsolet, vor allem nicht bei hohen regulatorischen Sicherheitsanforderungen. Zwar lässt sich ein Container gut absichern - das Bundesamt für Sicherheit in der Informationstechnologie (BSI) bietet hier etwa eine Vielzahl von Empfehlungen für die Absicherung von Anwendungen in Containern auf einer Container-Orchestrierungsplattform - aber VMs besitzen immer noch herausragende Tools zur Einhaltung von nicht-funktionalen und regulatorischen Anforderungen für Anwendungen wie Hochverfügbarkeit, Datensicherheit, Datensicherung, Security-Scanning, Überwachung und Isolation. In diesem Bereich haben Container- und Orchestrierungsplattformen noch Nachholbedarf. Es gibt Szenarien, in denen VMs immer noch besser geeignet sind als Container. Dies sind die Themenfelder rund um die Persistenz von Datenbanken, der Datensicherung und der In-Memory-Skalierbarkeit.
Wenn es beispielsweise auf Datenpersistenz ankommt, sind Datenbanken in VMs immer noch die bessere Wahl, um Tabellen und Logs leichter anzuordnen. Die Datensicherung von Datenbanken, die man über ein zusätzliches Datensicherungs-Tool bis zur letzten (committed) Transaktion sichert, lässt sich in VMs leichter konfigurieren, als wenn man diese Datenbanken und die dazugehörigen Datensicherungs-Tools in Containern hätte.
In-Memory Datenbanken wie SAP HANA, Redis oder extremeDB benötigen einen hohen Hauptspeicherausbau, der gerade in VMs (oder noch besser in Bare-Metal-Servern) möglich ist und sich daher für Container noch nicht eignet. Bei der Isolation bieten VMs außerdem einen hohen Schutz aller Objekte innerhalb der VM, da die Hypervisoren besser isoliert sind. Sie sind weniger empfindlich für Angriffe als beispielsweise ein von Containern gemeinsam genutzter Linux-Kernel, da Container per Design nur auf Prozessebene des Host-OSs isolieren.
Container sind demnach kein Allheilmittel für jegliche Anwendungsfälle und bringen bei allen Vorzügen auch einige zu beachtende Einschränkungen mit sich. Trotz moderner Sicherheits- und Isolierungsfunktionen bleibt die Isolierung der Container untereinander und gegenüber dem Host-System (noch) hinter der Isolation bei klassischer Virtualisierung zurück. In Kombination allerdings bieten sie bereits heute ein "unschlagbares" Duo, was Sicherheit, Isolierung und Management betrifft.
Ein Softwarefehler oder eine Sicherheitslücke, die das gesamte System (Host-Betriebssystem der Container-Nodes) in Mitleidenschaft ziehen, ist beispielsweise bei der Virtualisierung nicht möglich, da sie mit ihrer Hardwareunterstützung von "echter" Isolierung profitiert. Ein "Abstürzen" einer VM hat durch die Isolation im Typ-1-Hypervisor keine Auswirkung auf weitere VMs, auch wenn diese auf der gleichen physischen Maschine gehosted sind - beim Typ-2-Hypervisor, einem gehosteten Hypervisor in einem Betriebssystem, dagegen schon.
Bei Containern auf einem Linux- oder Windows-Host ist das Betriebssystem hier immer ein Single Point of Failure. Das heißt, dass ein Betriebssystemfehler auf dem Container-Host alle Container in Mitleidenschaft zieht. Heute können Container allerdings damit problemlos umgehen, dank intelligenter Containerorchestrierung, Replica Sets und verwandter Kubernetes-Konzepte zur Containerverteilung über mehrere Worker Nodes.
Container sind dadurch mittlerweile in einigen Bereichen "Enterprise-ready". Durch eine Vielzahl an Open-Source- und kommerziellen Tools sind Container gut zu administrieren (ELK-Stack) und abzusichern (Mutationsüberwacher). Ferner sind sie sogar flexibler wegen der geringeren Größe und portabler als VMs mit passendem Hypervisor. Dazu haben nicht nur Containertechniken wie Docker beigetragen, sondern auch weitere OCI-konforme Container-Engines wie rkt, containerd oder cri-o. Für die meisten Unternehmen empfiehlt es sich schon aufgrund der Vielzahl und Heterogenität an eingesetzten Applikationen und Diensten, beide Technologien in Kombination zu nutzen.
Empfehlungen
Ob Container, VMs, oder beides zusammen - sogar "aufeinander": Die richtige Mischung macht den Unterschied. Hybride Lösungen, bei denen Container und VMs in Einklang miteinander harmonieren, sind oft die beste Wahl. In einem solchen hybriden Szenario können Container ihre Stärken für statuslose (stateless) Anwendungen ausspielen und portierbar sowie skalierbar sein, während Datenhaltungskonzepte (File-Systeme und Datenbanken) noch immer in VMs am besten untergebracht sind, bei denen das Logging, Monitoring, Backup/Recovery, Stabilität, Isolation und Performance die wesentlichen Charakteristika für Anwendungen mit persistenten Daten sind. Daher ist davon auszugehen, dass Container und virtuelle Maschinen bis auf Weiteres parallel existieren und nicht konkurrieren, sondern eher die Stateles-s und die Stateful-Anwendungen unter sich aufteilen.
Auch wenn das Konzept des "You build it, you run it" dem Anwendungsentwickler/Developer mehr Aufgaben im Bereich "Operations" beschert, sind die klassische Administratoren, die für die reinen Operations zuständig sind, nicht unterbeschäftigt. Im Gegenteil: Security, Monitoring, Logging, Upgrades und die Pflege der unterliegenden Infrastruktur (der softwaredefinierten Umgebungen) werden den Administrator bei zunehmender Anzahl an Containern und Container-Clustern immer noch gut beschäftigen. Der Betrieb von Container-Clustern, in denen viele und kritische statuslose Anwendungen in Containern laufen, fordert den heutigen Administrator in allen Bereichen wie Netzwerk-, Speicher- und Virtualisierungs-Management, aber vor allem bei den Sicherheitskonzepten.
Sicherheitskonzepte sind das A und O
Für Unternehmen, die viele Container von außerhalb einsetzen, ist der Einsatz eines Security- und Mutationsscanners für Container unabdingbar. Selbst wenn Entwickler nur zertifizierte Container von vertrauenswürdigen Herstellern einsetzen, entdecken die Scanning-Tools die Schwach-stellen oft erst spät. Dies bedeutet, dass Sicherheitslücken auch bei sicher geglaubten Containern immer im Bereich des Möglichen liegen.
Der Einsatz eines weitreichenden IAM-Tools (Identitäts- und Access-Management) wie etwa Keycloak oder RedHat SSO hilft, die Rollen- und Zugriffsrechte im Container-Cluster einzuteilen und zu verwalten. Gleichzeitig kann die Laufzeitüberwachung von Apps in Containern als auch die der VMs, auf denen die Master Nodes und Worker Nodes der Container Cluster laufen, den Administratoren dabei unterstützen, ungewollte Veränderungen zu entdecken. Ein hochverfügbarer und gut arbeitender Master Node wird in einem ausgelasteten Cluster viele Informationen in sein internes Repository schreiben, etwa eine Etcd-Datenbank.
Dabei überprüft er viele Container während der Laufzeit auf Mutationen, sodass Performance-Engpässe auf allen Container-Nodes auftreten können. Erste Erfahrungen mit produktiven Kubernetes-Clustern haben gezeigt, dass eine Trennung der Security Scanning Nodes von den Master Nodes angebracht ist.
Des Weiteren ist es sinnvoll, die Einbindung von Speicher und Netzwerk über die vom Container-Cluster angebotenen Standardschnittstellen (CSI, CNI) einer Einbindung über proprietärer Netzwerk- und Speicherkomponenten über proprietäre Interfaces vorzuziehen. Zusätzlich zu den Kubernetes-internen SDNs (Calico/Flannel, Open VSwitch, Multus) verwenden Netzwerkadministratoren gerne auch das SDN (Software-Defined Network) des zugrunde liegenden IaaS-Layers, etwa VMware NSX-T oder Cisco ACI oder OpenStack OVN. Dies kann dem IT-Verantwortlichen dabei helfen, eine stärkere Netzwerksicherheit für containerisierte Anwendungen sowie eine gute Isolierung bei hoher Netzlast und Skalierbarkeit im Frontend zu erreichen.
Die Integration des Container-Clusters in einen DevOps-Workflow und in ein Staging-Tool wie IBM UrbanCode, RedHat Ansible Automation Platform, Chef, Puppet, Microsoft Team Foundation Server oder Azure DevOps kann es sowohl Entwicklern als auch Administratoren erleichtern, die qualitätsgesicherte Automation von Deployments einzuführen.
Cloud Bursting und Autoscaling
Die Planung für externe Skalierbarkeit (Cloud Bursting) ist - sofern eine hybride Cloud für ein Unternehmen erlaubt ist - kein Luxusproblem. Vorausdenkende Betriebsabteilungen etablieren Skalierbarkeit in externe Clouds, um Engpässe bei lokalen Worker Nodes auszugleichen und automatisiert und dynamisch weitere Worker Nodes über die IaaS-Layer des Cloud-Providers hinzuzufügen (Infrastructure as Code, beispielsweise mit Terraform, An-sible Automation, CloudForms, Juju oder Saltstack).
Und falls doch die Anzahl der Container-Cluster und VM-Domänen eine beängstigend hohe Anzahl erreicht - auch als "Multi-Cloud"- oder "Multi-Cluster Sprawl"-Phänomen bezeichnet - kann der Einsatz neuartiger Tools für das Multi-Cloud-Management helfen. Diese gestalten über eine zentrale Management-Instanz die bereits ausufernden Container-Cluster übersichtlich, erstellen Policies für Application Deployment und Governance für Management-Aufgaben und verwalten föderierte Container-Cluster als eine Einheit. Prominente Vertreter dieser Multi-Cluster-Management-Tools sind Rancher, Gardener, Scalr, RightScale und IBM CloudPak4MCM. Ist einmal ein Ende der HCI-internen Ressourcen erreicht und benötigen containerisierte Anwendungen etwa im saisonalen Geschäft mehr Rechenleistung, so skaliert die Container-Orchestrierungsplattform über Cloud Bursting und Autoscaling sogar in andere Clouds, indem sie weitere Worker Nodes, Proxy Nodes oder Infrastructure Nodes allokiert und weitere Container von Kubernetes per Autoscaler auf die zusätzlichen, neu geschaffenen Nodes provisioniert.
Cloud Bursting mit Hilfe von Autoscaling provisioniert zusätzliche Kubernetes Worker Nodes oder CloudFoundry Diego Cells, auf denen K8 oder CF weitere Container für einen Anwendungs-Service bereitstellen. Bei Abflauen der Lastspitzen können sie diese wiederrum stilllegen oder sogar deprovisionieren.
Die Verbindung zu entfernten Clouds wie AWS, Azure, GCP oder IBM Cloud entsteht in vielen Fällen über ein sogenanntes Terraform Provider Plugin, über das der Administrator eine Verbindung zur präferierten Cloud definiert, um VMs als Kubernetes Nodes zu provisionieren. Oder beim Kubernetes-internen Ansatz, wo über den Multi-Cluster-Management-Hub im entfernten Kubernetes Ziel-Cluster (Multi-Cluster-Endpoint) Kubelet-Container provisioniert werden, um die Verbindung zum Multi-Cluster-Hub herzustellen und den Endpoint am Hub bekanntzumachen.
Blickt man zurück auf die drei tragenden Säulen einer Cloud-Plattform - Menschen (Entwickler und Administratoren), Architektur (Anwendungen und Systeme) sowie Infrastruktur (Betrieb und operationale Aspekte) - so spielt der Mensch immer noch die tragende Rolle, weil er mit der voranschreitenden Containertechnologie im Rechenzentrum auch zusätzliche Aufgaben bekommt.
Entwickler erhalten immer mehr Administrationsaufgaben
Entwickler bekommen durch Container-Plattformen immer mehr (Teil-)Administrationsaufgaben, weil sie schon beim Design der Anwendung auf einer Containerplattform wie Kubernetes auf Betriebsaspekte achten sollen. Typische Beispiele hierfür sind:
- Wo werden Container-Images bezogen oder abgelegt (internes Docker-repo, Quay, Artifactory, Nexus, gitlab)?
- Benötigt die Anwendung persistenten Speicher, und wenn ja, wo und in welcher Güte/Storage-Klasse?
- Welche Ports müssen beziehungsweise dürfen nicht geöffnet sein - beispielsweise für Frontend-Anwendungen oder Anwendungen in einer DMZ?
- Welche "Inter-Container-" oder "Inter-Node-Kommunikation" benötigt die Anwendung über welche Netzwerkzonen?
- Welche Sicherheitszertifikate werden wo gespeichert und wie gesichert (zum Beispiel CA-Domain, Etcd-Datenbank)?
- Welche Logs schreibt die Anwendung beziehungsweise schreiben die Pods? Und wohin sollen diese geschrieben werden, beispielsweise Kubernetes-internes Logging (Fluentd, Logstash) oder externes Logging (Splunk, Graylog)?
Fazit
Die Zeit ist reif für Containerplattformen. In der Studie "Best Practices for Running Containers and Kubernetes in Production" vom Februar 2019 prognostiziert Gartner, dass 2020 weltweit mehr als 75 Prozent der Unternehmen containerisierte Anwendungen in der Produktion betreiben werden. Dies würde einen Anstieg von circa 30 Prozent bedeuten.
Zwar haben gefühlt mehr als 90 Prozent der Großunternehmen Container "irgendwie im Einsatz", doch wie viele davon wirklich einen produktiven Charakter haben, das wissen nur die Entwickler und Administratoren selbst. Doch unabhängig davon, wie hoch diese Zahl ist, so hilft die Kombination von Softwareentwickler und IaaS-Administratoren gemeinsam - hier als Team für DevOps - die Anwendungen und Systeme von heute zusammen zu betreuen und die vorhandenen technischen und mentalen Barrieren zwischen Dev und Ops zu überwinden.
Lesen Sie mehr zum Thema
