KubeCon + CloudNativeCon 2019 EU: Plateau der Realität

Inhaltsverzeichnis

Das geflügelte Wort der KubeCon + CloudNativeCon war "Empower the community". Es geht voran, es wird breiter, es wird unaufgeregter. Man ist auf dem Plateau der Realität angekommen. Das ist ein guter Zeitpunkt, um den Fokus auf die Gemeinschaft zu legen, die die Techniken weiterbringen und anwenden. Es geht darum, Benutzer zu Beitragenden und zu Verantwortlichen zu machen.

Vor allem die Benutzer wie Intuit, ABN Amro, das CERN und Spotify haben auf der KubeCon eindrucksvoll gezeigt, was auf Basis von Kubernetes so alles möglich ist. Die Themen der Konferenz waren breit gestreut, aber einige Schwerpunkte waren sichtbar.

Kubernetes als Plattform, um Plattformen zu bauen

Kubernetes ist ein Container-Manager, und es braucht zahlreiche Aufbauten, damit effizient Anwendungen darauf entwickelt und betrieben werden können. Diese Aufbauten sind CI/CD-Strecken, aber auch Services für Anwendungen wie Messaging oder Datenbanken. Damit wird die Erweiterbarkeit von Kubernetes zu einer zentralen Anforderung und steht im Fokus der Kubernetes-Roadmap. Eine wichtige Technik zur Erweiterung von Kubernetes sind die Custom Resource Definitions (CRDs). Damit lassen sich eigene Kubernetes-Objekte neben eingebauten wie Pods, Services und ConfigMaps erzeugen. Diese Objekte können unter anderem Message Queues anlegen oder Datenbanken hoch- und runterskalieren sowie Backups und Restores anfertigen.

Bereits 2016 hat das damalige CoreOS auf CRDs aufbauend das Konzept der Operatoren eingeführt. Dabei handelt es sich um ein Paketierungs- und Laufzeitformat für Kubernetes-Plattformaufbauten, die im Kern aus CRDs bestehen, die Betriebsautomatismen bei Kubernetes-Ereignissen gegen die Kubernetes-API ausführen. Vor einem Jahren hat sich das Operator-Framework das Ziel gesetzt, das Programmieren eigener CRDs zu vereinfachen. Mittlerweile sind viele Operatoren verfügbar (siehe OperatorHub), in denen teilweise erheblicher Entwicklungsaufwand steckt. Neben dem Operator-Framework stehen nun mit dem kubebuilder von Google und dem Open-Source-Projekt Kudo von Mesosphere weitere Toolkits zur Entwicklung von Operatoren zur Verfügung. Kudo setzt dabei auf einen deklarativen Ansatz bei der Entwicklung von Operatoren.

Die drei Säulen der Observability

Mit Observability ist die Fähigkeit von Anwendungen, Plattformen und Infrastrukturen gemeint, in ihrem Laufzeitverhalten beobachtbar zu sein. Observability hat drei Säulen: Metriken, Traces und Logs. Mit OpenTelemetry wurde ein Standard vorgestellt, der Daten in allen drei Säulen beschreiben und verschiffen kann. Auf Seiten der Analysewerkzeuge kommt es nun ebenfalls zu einer verstärkten Konvergenz dieser Daten. So macht es Grafana Loki möglich, Metriken und Logs integriert zu analysieren, und mit Kibana sowie ZipKin ermöglichen den Sprung aus Log-Einträgen in die entsprechenden Traces. Mit Continuous Profiling ist ein Ansatz im Entstehen, das Laufzeitverhalten einer Anwendung einfach und minimalinvasiv zu beobachten.

Anwendungen definieren und paketieren

Während die Entwicklung Cloud-nativer Anwendungen ein stiefmütterlich behandeltes Thema der Konferenz war, wurden mehrere Projekte zum Definieren und Paketieren von Anwendungen vorgestellt. Allen voran Helm in der Version 3.0 alpha, das nun ausschließlich clientseitig funktioniert und damit sicherer ist. Mit CNAB (Cloud Native Application Bundle) haben Docker und Microsoft ein Format zum Paketieren von Anwendungen vorgestellt. CNAB definiert dazu ein Verzeichnisformat nebst Deskriptoren für die Eigenschaften der Anwendungen. Komplexe Installations- und Deinstallationslogik ist über dafür spezialisierte Images abbildbar. Kustomize.io ist ein weiterer Ansatz, um Anwendungen zu definieren und ist mittlerweile direkt in das Kubernetes-Kommandozeilenwerkzeug kubectl integriert.

Alle machen Policies

Eine kleine Überraschung der Konferenz war der Open Policy Agent (OPA), der in auffällig vielen Talks präsent war. Er ermöglicht, Policies in einer einheitlichen Sprache – Rego genannt – zu formulieren und dann am Ort des Geschehens gegen dort erhobene strukturierte Kontext-Daten auszuführen. So gibt es mit dem Gatekeeper-Projekt eine Integration von OPA mit dem Eingangstor zu Kubernetes, dem Admission Controller. Damit lassen sich bei jeder administrativen Interaktion mit Kubernetes wie Deployments Policies ausführen und anschließend beispielsweise prüfen, ob die richtigen Basis-Images zum Einsatz kommen und mit dem passenden Zertifikat signiert sind. Für OPA wurden auch neuartige Use Cases präsentiert wie das Unit Testing von Kubernetes Definitionen schon im CI/CD Prozess. (rme)