Cloud Native News #6: Plattformbau für den Unternehmenseinsatz

Inhaltsverzeichnis

"Keep Cloud Native Classy" war das Motto der CloudNativeCon im November in San Diego. Das klingt wie ein Aufbäumen vor einer befürchteten Kommoditisierung im Cloud-nativen Ökosystem, die jedoch vermutlich in weiter Ferne ist. Dennoch geht es im Cloud-nativen Ökosystem mehr um die tatsächlichen Bedürfnisse von Unternehmen als um stilvolle Techniken.

Kubernetes-basierte Plattformen

Unternehmen benötigen Kubernetes-basierte Plattformen, die alle Funktionen bieten, die Entwickler und Betriebseinheiten im produktiven IT-Leben benötigen. Dabei haben Unternehmen zwei grundlegende Optionen:

1. sich in Abhängigkeit von einer Distribution oder einen Cloud Provider zu begeben, die oder der das umfangreich vorgefertigt anbieten, oder
2. die Bausteine der Plattform selbst auszuwählen und zu integrieren.

Bei den Distributionen herrscht Ernüchterung: Inzwischen existieren gefühlt fast ebenso viele Distributionen wie Cloud-native Techniken in der Cloud-native Landschaft – Stand 12/2019: 63 Distributionen und 23 Installer – mit wenig klaren Differenzierungsmerkmalen und teilweise noch großen Lücken bezüglich der in Unternehmen benötigten Funktionen.

Das bringt Bewegung in das Anbieterfeld: Mirantis hat die strauchelnde Enterprise-Sparte von Docker aufgekauft. Mesosphere nennt sich nun D2IQ und fokussiert auf Day 2 Operations auf dem Weg zum Börsengang. VMware verleibt sich Pivotal ein und stellt mit dem Project Pacific postwendend die Initiative vor, Kubernetes zum Kern des eigenen Paradeprodukts vSphere zu machen.

Der Trend bei den Distributionen geht in Richtung Sicherheit und Betreibbarkeit sowie der Unterstützung von Multi- und Hybrid-Cloud-Szenarien, die von 58 Prozent der Unternehmen laut "RightScale State of the Cloud Report" das präferierte Setting sind. Hier positionieren sich mittlerweile aber ebenso die großen Cloud-Anbieter wie Google mit Anthos, AWS mit Outposts und Microsoft mit Azure Stack.

Marke Eigenbau mit Operatoren

Erfolgreiche Kubernetes-Plattformen der Marke Eigenbau sind selten. Das liegt insbesondere daran, dass die Cloud-Native-Landschaft mit ihrer exponentiell wachsenden Zahl potenziell dafür relevanter Techniken immer mehr zur "Hellscape" wird, die eine Wahl schwer macht. Eine Orientierung bieten zunehmend die offiziellen CNCF-Projekte (Cloud Native Computing Foundation), die den Standard in ihren jeweiligen Bereichen setzen wollen und denen die CNCF Sichtbarkeit und Traktion bietet. Neben Kerntechniken wie Kubernetes und Observability-Werkzeugen florieren mittlerweile höherwertige Plattformbausteine und Standards zum Messaging (NATS, CloudEvents) und zur Datenhaltung (Vitess als graduiertes Projekt der CNCF und Presto unter dem Dach der Linux Foundation.

Das zweite zentrale Problem beim Eigenbau einer Kubernetes-Plattform ist die Integration der Techniken zu einem großen Ganzen. Der Klebstoff der Wahl sind dabei die sogenannten Operatoren. Sie automatisieren den gesamten Lebenszyklus von Bausteinen auf Kubernetes und kümmern sich gleichzeitig darum, die Bausteine untereinander zusammenspielen zu lassen. Aktuell ist die Entwicklung eigener Operatoren jedoch komplex und aufwendig. Auf OperatorHub finden sich zwar für viele Techniken fertige Operatoren, die aber noch von wechselnder Qualität sind und die man auf die speziellen Bedürfnisse anpassen muss.

Ein spannender neuer Ansatz ist KUDO (Kubernetes Universal Declarative Operator), mit dem sich Operatoren deklarativ per YAML definieren lassen. Dabei hilft, dass die Basis für Operatoren in Kubernetes, die Custom Resource Definitions (CRDs), mit dem aktuellen Release Kubernetes 1.16 generell verfügbar sind.

Emanzipation von Continuous Delivery

Der aus Entwicklersicht wichtigste Teil einer Kubernetes-Plattform ist die CI/CD-Werkzeugkette. In dem Bereich tut sich gerade viel – manifestiert durch die Gründung der Continuous Delivery Foundation aus der CNCF heraus. Die Stiftung hat das Ziel, der nächsten Generation der Continuous-Delivery-Werkzeuge eine Heimat zu bieten. Die Tools haben einiges gemeinsam:

• Sie laufen auf Kubernetes.
• Ihre Abläufe sind hochautomatisiert über Pipelines.
• Sie bieten risikoarme Release-Prozesse wie Canary Releases.
• Continuous Integration und Continuous Delivery sind voneinander entkoppelt.

Gerade die Emanzipation von Continuous Delivery ist neu, denn lange wurden CI und CD als unzertrennliches Pärchen gesehen. Mit dem GitOps-Paradigma erfolgt nun die Trennung. Das Prinzip ist einfach: Im Kubernetes-Cluster läuft ein Operator, der ein Git-Repository auf Änderungen hin überwacht. Letzteres enthält die Beschreibung des Zielzustands des Clusters:

• Die Pods und damit auch die Container, die laufen sollen,
• die bereitgestellten Services,
• die (verschlüsselten) Passwörter und Konfigurationswerte sowie
• Berechtigungen, Security-Regeln und alles, was sich per YAML in Kubernetes beschreiben lässt.

Bei einer Änderung ist es die Aufgabe des Operators, im Cluster den beschriebenen Zielzustand herzustellen. Damit ist die CI-Pipeline bis Übergabekante Container Image in der Registry und YAML-Dateien in Git zuständig. Änderungen in Git stoßen die CD-Pipeline asynchron an. GitOps hat dabei viele Vorteile:

• Durch das automatische Herstellen des Zustands in Kubernetes lässt sich der schreibende Zugriff darauf durch menschliche Hand komplett abklemmen. Das führt zu einem deutlich höheren Sicherheitsniveau, da nur noch der GitOps-Operator den Cluster-Zustand verändert.
• Jede Änderung im Cluster-Zustand erfolgt per Code (Infrastructure-as-Code-Prinzip), ist auditiert (über den Git Change) und lässt sich bei Bedarf nach dem Vieraugenprinzip (über Pull/Merge Requests) freigeben.
• Mehrere Umgebungen lassen sich über mehrere Branches im Git-Repository abbilden, mit Abgleichsfunktionen per Git. Somit ist auch die Promotion von Änderungen zwischen Umgebungen nicht mehr als ein Merge(-Request) von Änderungen in einen anderen Branch.

Unabdingbar bei GitOps-basiertem CD sind Post-Deployment-Checks, die den Erfolg der Zustandssynchronisation bestimmen und Probleme melden. Rund um GitOps konsolidieren sich gerade führende Werkzeuge zu einem hoffnungsvollen Open-Source-Ansatz, der unter das Dach der CNCF wandern soll: Argo CD als Continuous Delivery Engine, Flux als GitOps-Operator und Flagger für progressive Releasetechniken wie Canary, Blue/Green Deployments und A/B Testing.

Es gibt noch eine Reihe weiterer spannender Neuigkeiten im Umfeld von Continuous Delivery:

• Die Quay Registry, die RedHat durch die Übernahme von CoreOS erworben hat, ist nun Open Source. Quay ist nicht nur eine Image-Registry, sondern kann Images automatisch bauen und Vulnerability-Scans durchführen. Das reduziert Komplexität in der CI-Pipeline. Harbour ist eine Alternative zu Quay unter dem Dach der CNCF, die jüngst in Version 1.9 erschienen ist. Sie kann Inhalte der Harbour-Registry in die Container-Registrys der großen Cloud-Provider replizieren.
• Helm entfernt in der lange erwarteten Version 3.0 Tiller. Letzteres war ein Service von Helm, der direkt im Ziel-Cluster laufen musste, um dort Helm Charts verwalten zu können. Tiller galt stets als Sicherheitsrisiko. Zur Migration von Helm-2-Charts auf Helm 3 steht ein Kommandozeilenwerkzeug zur Verfügung.

GitHub hat mit Actions eine Funktion eingeführt, mit der Entwickler ihre Arbeitsabläufe automatisieren können. GitHubs Actions steht für alle öffentlichen Repositorys kostenlos zur Verfügung, und die Abrechnung für die privaten erfolgt abhängig von der Ausführungszeit. Gerade die enge Integration in GitHub und der offene Marktplatz für Bausteine zum Erstellen von Workflows und Pipelines könnten GitHub Actions eine gute Marktposition verschaffen.