zurück zum Artikel

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

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

Es herrscht Bewegung im Cloud-nativen Umfeld, und die jüngeren Entwicklungen zielen vor allem auf den praktischen Einsatz im Unternehmen ab.

"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.

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 [1]: 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 [2]. Mesosphere nennt sich nun D2IQ [3] und fokussiert auf Day 2 Operations auf dem Weg zum Börsengang. VMware verleibt sich Pivotal ein [4] und stellt mit dem Project Pacific [5] 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 [6]" 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.

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 [7] und Presto unter dem Dach der Linux Foundation [8].

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 [9] 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 [10] (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 [11] generell verfügbar sind.

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

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:

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:

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 [15]: Argo CD [16] als Continuous Delivery Engine, Flux als GitOps-Operator [17] und Flagger [18] 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:

GitHub hat mit Actions eine Funktion eingeführt [23], 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.

Ohne ein ausreichendes Security- und Compliance-Niveau geht bei größeren Unternehmen gar nichts. Darum wundert es nicht, dass bei der diesjährigen CloudNativeCon in San Diego der Open Policy Agent [24] (OPA) einen ähnlichen Hype ausgelöst hat wie im Jahr davor Istio.

OPA ist ein CNCF-Projekt, mit dem sich Policys programmieren, provisionieren sowie durchsetzen und dabei überwachen lassen. Als Grundlage für die Vorgaben dient die proprietäre Sprache Rego, und die OPA-Agenten prüfen sie. Letztere sitzen als dedizierter Service oder eingebettet per Go-Bibliothek nahe an dem mit Policys gesteuerten Workload. Der Anwendungsbereich ist vielfältig und beliebig erweiterbar: Steuerung von Authentifizierung und Autorisierung, Compliance-Checks in der CI/CD Pipeline, Kontrolle des Service-Mesh und der Kubernetes-Konfiguration. OPA ist unabhängig von Kubernetes – die Agenten laufen auch außerhalb eines Clusters. Mit OPA lassen sich somit vielfältige Compliance- und Security-Policys per Code definieren und umsetzen und somit ein umfassender Security-Stack aufbauen.

Gemäß dem Prinzip "Shift Left [25]" können Security-Checks Bestandteil des CI/CD-Prozesses werden. Dafür steht unter anderem das Werkzeug Conftest [26] zur Verfügung, mit dem sich über in Rego formulierte Policy-Checks zahlreiche Konfigurationsdateien wie YAMLs, JSONs, TOMLs und Dockerfiles definieren und prüfen lassen. Kubernetes Admission Controller oder die darauf aufbauende OPA-Integration Gatekeeper [27] sind im Anschluss der Türsteher ins Kubernetes-Cluster und lassen nur Veränderungen zu, die allen definierten Policys genügen.

"Shift Left" benötigt ebenfalls Security-Maßnahmen, die zur Laufzeit wirken. Kubernetes bietet mit den PodSecurityPolicies und NetworkPolicies wirksame Sicherheitsvorkehrungen – idealerweise begleitet von einer Policy-fähigen und eBPF-basierten (Extended Berkeley Packet Filter) Netzwerkvirtualisierung wie Calico oder Cilium. Das reduziert die Angriffsfläche im Netzwerk deutlich. Mit dem CNCF-Projekt Falco [28] steht ein Werkzeug zur Verfügung, das die Angriffsfläche auf die Workloads deutlich reduzieren kann. Falco überwacht das Laufzeitverhalten von Containern und schreitet ein, wenn es eine Anomalie oder gar ein Eindringen erkennt.

Ein weiteres Tool zum Umsetzen von Sicherheitsmaßnahmen zur Laufzeit sind Service-Meshes. In dem Bereich hat es Linkerd geschafft, den Hype rund um Istio zu brechen. Obwohl Letzteres weiter der "Feature-König" ist, schätzen viele Linkerd wegen der deutlich geringeren Komplexität und der besseren Betreibbarkeit [29]auch wenn Istio mit Version 1.4 [30] in den Bereichen deutliche Verbesserungen mitbringt. Das Service-Mesh steht zusätzlich in der Kritik, weil es kein neutrales CNCF-Projekt ist und den auf der CloudNativeCon EU im Mai angekündigten Service-Mesh-Standard SMI [31] nur widerwillig adaptiert. Ein Service-Mesh arbeitet oft Hand in Hand mit einem API-Gateway als Eingangstor. In dem Bereich gewinnt insbesondere Gloo [32] an Sichtbarkeit. Vergleichbar zur Service-Mesh- Prominenz basiert Gloo auf Envoy als Proxy-Technik und integriert sich als Ingress in die Kubernetes-Welt.

In den letzten Monaten kristallisierte sich als Trend im Cloud-nativen Ökosystem heraus, dass die Hersteller zunehmend die Erfordernisse für den Einsatz in größeren, nicht Cloud-nativen Unternehmen berücksichtigen. Die große Frage bleibt, wer die vielen verfügbaren Techniken zu einer für Entwickler und den Cloud-Betrieb brauchbaren Plattform integriert. Mittlerweile existierten zahlreiche Kubernetes-Distributionen, die aber vielfach noch Funktionslücken aufweisen.

Für Plattformen der Marke Eigenbau braucht es als Klebstoff zwischen den Techniken die sogenannten Operatoren. Die Entwicklung von Operatoren ist komplex, aber neue Werkzeuge vereinfachen den Prozess zunehmend. Gerade im Bereich CI/CD ist viel Bewegung durch die Gründung der Continuous Delivery Foundation und dem fundamentalen Wandel durch das vielversprechende GitOps-Prinzip erkennbar.

Für das Pflichtprogramm rund um Security und Compliance existieren inzwischen genügend Bausteine, um ein hochwertiges Niveau auf Kubernetes zu erreichen. Es mangelt jedoch noch an Tools zur Integration der einzelnen Teile.

Josef Adersberger
ist CTO und Mitgründer der QAware, einem Softwarehaus aus München mit rund 100 Mitarbeitern, das Cloud-Native-Applikationen entwickelt und bestehende Anwendungen auf Cloud-Native-Plattformen migriert. Er hält seit 2011 Vorlesungen zum Thema Cloud (Native) Computing und ist CNCF-Mitglied.
(rme [33])


URL dieses Artikels:
https://www.heise.de/-4630509

Links in diesem Artikel:
[1] https://docs.google.com/spreadsheets/d/1LxSqBzjOxfGx3cmtZ4EbB_BGCxT_wlxW_xgHVVa23es/edit?usp=sharing
[2] https://www.heise.de/meldung/Docker-verkauft-Enterprise-Geschaeft-und-bekommt-neuen-CEO-4585658.html
[3] https://www.heise.de/meldung/Aus-Mesosphere-wird-D2IQ-4489090.html
[4] https://www.heise.de/meldung/VMware-kauft-Pivotal-und-Carbon-Black-4503276.html
[5] https://www.heise.de/meldung/VMware-setzt-mit-dem-Project-Pacific-voll-auf-Kubernetes-4505999.html
[6] https://info.flexera.com/SLO-CM-WP-State-of-the-Cloud-2019
[7] https://www.heise.de/meldung/Vitess-wird-zum-vollwertigen-Projekt-der-Cloud-Native-Computing-Foundation-4578803.html
[8] https://www.heise.de/meldung/Facebooks-Presto-landet-unter-dem-Dach-der-Linux-Foundation-4537444.html
[9] https://operatorhub.io
[10] https://kudo.dev
[11] https://www.heise.de/meldung/Kubernetes-1-16-startet-mit-mehr-als-30-Verbesserungen-4533705.html
[12] https://www.heise.de/meldung/DevOps-World-CloudBees-baut-die-Cloud-native-Zukunft-4609301.html
[13] https://cd.foundation
[14] https://landscape.cd.foundation
[15] https://www.weave.works/blog/argo-flux-join-forces
[16] https://argoproj.github.io/argo-cd
[17] https://github.com/fluxcd/flux
[18] https://flagger.app
[19] https://www.heise.de/meldung/Project-Quay-Red-Hat-legt-den-Quellcode-seiner-Cloud-Container-Registry-offen-4585887.html
[20] https://goharbor.io/blogs/harbor-1.9
[21] https://www.heise.de/meldung/Kubernetes-Paketmanager-Helm-3-verzichtet-auf-Tiller-4586105.html
[22] https://github.com/helm/helm-2to3
[23] https://github.com/features/actions
[24] https://www.openpolicyagent.org
[25] https://www.heise.de/developer/artikel/Shift-Left-Secure-by-Design-und-agile-Entwicklung-4613935.html
[26] https://github.com/instrumenta/conftest
[27] https://github.com/open-policy-agent/gatekeeper
[28] https://falco.org
[29] https://platform9.com/blog/kubernetes-service-mesh-a-comparison-of-istio-linkerd-and-consul/
[30] https://www.heise.de/meldung/Service-Mesh-Istio-1-4-naehert-sich-Telemetrie-ohne-Mixer-an-4586928.html
[31] https://smi-spec.io
[32] https://www.heise.de/meldung/Cloud-native-Der-API-Gateway-Gloo-erreicht-Version-1-0-4588034.html
[33] mailto:rme@ix.de