© Sergey Nivens, 123RF

Menschenmengenmäßig besuchte eine ganze Kleinstadt die Kubecon in Barcelona. Neben Geschichten aus der Kubernetes-Praxis hörten die Teilnehmer auch Neuigkeiten aus der vielfältigen und sich stets verändernden Softwaregalaxie rund um die Containerplattform.

Aus Versehen mal wieder alle Kubernetes-Cluster für die USA gelöscht? Kein Problem, das passiert den Besten, erzählte ein Spotify-Mitarbeiter auf der Kubecon in Barcelona. Mit seiner Failure-Story lieferte David Xia die wohl unterhaltsamste Keynote auf der “Kubecon und Cloud Native Con Europe 2019” (kurz: Kubecon). Als Zuhörer hatte sich mengenmäßig eine komplette Kleinstadt zur morgendlichen Keynote versammelt: Rund 7700 Besucher nahmen diesmal teil. 2018 pilgerten noch 4300 Menschen nach Kopenhagen. Das zeigt: Das Interesse an Containertechnologie scheint ungebrochen zu sein.

Menschen machen Fehler

Spotify betreibt Kubernetes-Cluster in drei Regionen: in Asien, Europa und den USA. Xia hatte einen Testcluster angelegt, die Konfiguration eines Produktivclusters dorthin kopiert und sich beim Löschen des Clusters für das falsche Browsertab entschieden. Das zeigte den aktiven Cluster in den USA mit 50 Nodes an. Offenbar macht Googles Cloud sowohl das Anlegen als auch das Löschen von Kubernetes-Clustern besonders einfach. Dank kleiner Bugs auf dem Weg dauerte es dreieinhalb Stunden, den Cluster wieder zu restaurieren.

Einen Monat später führten die Spotify-Admins Terraform [1] ein, damit sich solche Vorfälle künftig nicht wiederholen. Das Ergebnis: Dank eines Terraform-Bedienfehlers und falsch gesetzter Rechte gelang es den Admins diesmal, gleich zwei Cluster lahmzulegen, einen in Asien, einen in den USA.

Wir leben, wir lernen

Wer weiß, ob Xia die Story auf der großen Bühne erzählt hätte, wäre sie nicht gut ausgegangen. Die Nutzer bekamen trotz des nur einen verbliebenen Clusters nichts von dem Ausfall mit. Das Team musste lediglich mehr VMs außerhalb von Kubernetes erzeugen, einige hardkodierte IPs entfernen und Konfigurationen auffrischen.

Für den guten Ausgang machte Xia vor allem drei Punkte verantwortlich: eine Ausfallplanung, einen graduellen Umzug auf Kubernetes und eine gute Lern- und Fehlerkultur.

• So migrierte Spotify nicht alle Dienste auf Kubernetes und integrierte Failovers auf andere Cluster außerhalb der Containerplattform.
• Zudem führte das Unternehmen neue Tools nur graduell ein, ergänzte Prüfmechanismen, erzeugte Redundanzen und hielt sich Pfade für eine Rückkehr offen.
• Nicht zuletzt herrscht bei Spotify eine produktive Fehlerkultur. Diese kalkuliert ein, dass Menschen Fehler machen, und versucht die Ursachen herauszufinden und abzustellen.

Inzwischen sei es Spotify möglich, gelöschte Cluster mitsamt den Integrationen in einer Stunde zu restaurieren. Das gelinge auch, weil die komplette Infrastruktur als Code vorliege.

Die Wurzeln von Kubernetes

Gemenschelt hatte es auch in der vorherigen Keynote von CNCF-Chef Dan Kohn. “Kubernetes is People”, erklärte Kohn mit Blick auf die rund 31000 Kubernetes-Contributors. Für alle CNCF-Projekte zusammen kam Cheryl Hung, Director of Ecosystem bei der CNCF, gar auf rund 56000 Codelieferanten bei 2,66 Millionen Codebeiträgen.

Weil die Kubecon zugleich den fünften Geburtstag von Kubernetes feierte, erinnerte Google-Mitarbeiterin Janet Kuo an die Kubernetes-Anfänge. Intern nannte Google die an Borg orientierte Plattform zunächst Project 7 – nach Seven of Nine, einem freundlichen Borg aus dem Star-Trek-Universum. Von dieser Referenz zeugen auch die sieben Seiten des Kubernetes-Logos.

Kuo sprach auch über die Zukunft des Projekts. Vor allem gehe es nun darum, das Kubernetes-Ökosystem um Plattformen und Frameworks zu erweitern. Dazu müsse das Projekt einige Features, die bei der Erweiterbarkeit helfen, noch stabilisieren, etwa Custom Resource Definitions (CRDs).

In Sachen Skalierbarkeit soll Kubernetes verschiedene Engpässe angehen, denn Skalierbarkeit sei ein mehrdimensionales Thema. Als Beispiel brachte sie Node-Status-Updates, die bislang recht datenintensiv ausfallen, was Etcd überlaste. Ein neues Node-Lease-API steuere dagegen.

Eines für alle

Schnittstellen waren auf der Konferenz ebenfalls ein sehr präsentes Thema. Sie erleichtern den Umgang mit APIs und Diensten in Service Meshes. So stellte Microsofts Gabe Monroy in einer nachmittäglichen Keynote das Service Mesh Interface (SMI) vor (Abbildung 1). Bei den Zuhörern führte die Ankündigung zu spontanem Applaus.

Abbildung 1: Microsofts Gabe Monroy kündigte auf der Kubecon eine einheitliche Schnittstelle für Service Meshes an.

Das Set von APIs soll die Interoperabilität verschiedener Service-Mesh-Technologien gewährleisten, darunter Istio, Linkerd und Consul Connect. “Das Problem ist, dass Entwickler, die sich der Mesh-Technologie zuwenden, einen Provider aussuchen und direkt dessen APIs adressieren müssen. Das erzeugt einen Lock-in für die Service-Mesh-Implementierung”, hieß es in Microsofts offizieller Ankündigung von SMI.

Generische Interfaces sollen diesen Vendor-Lock-in einerseits künftig verhindern. Andererseits sollen sie das Netzwerk smart machen. Während die Logik bislang meist in den Routern selbst steckte, würden Technologien wie Cloud Native, Kubernetes und Container intelligentere Netzwerke erfordern und auf den Weg bringen.

Neue Dienste

Jede Kubecon begleitet auch immer eine Reihe von Ankündigungen neuer Dienste und Services. So berichteten Ben Sigelmann und Morgan McLean über eine Fusion: Ihre beiden Projekte Open Tracing und Open Census wachsen zu einem zusammen. Open Telemetry [2] soll künftig mehr Transparenz in die Kubernetes-Installationen bringen und Logs, Traces sowie Metriken sichtbar machen.

Vijoy Pandey von Cisco stellte Network Service Mesh (NSM) vor. Das Projekt befindet sich im Sandbox-Stadium und soll Probleme auf den Netzwerkebenen 2 und 3 lösen. Eine einfache Einführung gibt es unter [3]. Interessant ist, dass das Konfigurieren von IP-Adressen, Subnetzen und Routern dank NSM entfällt. Nutzer müssen lediglich einige Yaml-Files anlegen, um etwa einen Tunnel ins Firmen-VPN zu legen.

Eduardo Silva sprach über Fluentd, das seit April zu einem der ausgereiften Projekte (Graduate) der CNCF gehört. Aktuell sei die Version 1.5, die unter anderem Transportverschlüsselung mit TLS für HTTP und Syslog sowie Keepalive für das Forward-Output-Plugin erlaube. Zudem habe das Projekt die Dokumentation überarbeitet und verwende jetzt Gitlab für die Continuous Integration.

Linkerd 2.3 ist ebenfalls kürzlich erschienen. Die neue Ausgabe verschlüsselt die Kommunikation der Proxys untereinander konfigurationsfrei mit mTLS. Die nächste Version 2.4 ist für Juni anvisiert und unterstützt dann Traffic Shifting.

Tiller ist Geschichte

Ebenfalls im Anmarsch ist die Helm-Version 3.0.0: Der Client-seitige Package-Manager schickt Tiller in den Ruhestand, was das anwesende Publikum offenbar erfreute. Helm 3 speichert zudem Release-Informationen im selben Namespace wie die Release selbst, was den Wechsel zwischen Namespaces erlauben soll. Nicht zuletzt lassen sich Chartwerte jetzt nach Json-Schema validieren.

Fazit

Geschichten aus der Praxis nahmen auf der bislang größten Kubecon Europe einen umfangreichen Raum ein. Unternehmen adoptieren Kubernetes, finden allerdings ganz unterschiedliche Ansätze, um die vielen Komponenten zu einer funktionierenden Infrastruktur zu orchestrieren. Besonders das Vereinheitlichen von Schnittstellen scheint aktuell ein Thema in der Kubernetes-Entwicklung zu sein. Zeugen dafür sind das Service Meshes Interface, das Cluster-API, NSM aber auch Open Telemetry.