Interviewserie: Justin Lamp zu Kubernetes

Jede Geschichte beginnt mit Menschen, die etwas bewegen. In unserer Interviewserie kommen genau diese Menschen zu Wort: Mitarbeiter von NWS, die ihre Erfahrungen, Ideen und Erkenntnisse mit uns teilen. Wir wollen wissen, was sie antreibt und was wir alle von ihnen lernen können.

Wir setzen unsere Interviewserie mit Justin Lamp, Senior Systems Engineer, fort.

Was ist deine Position bei NETWAYS Managed Services und wofür bist du zuständig?

Ich arbeite als Senior Systems Engineer bei NETWAYS Managed Services. Mein Kerngeschäft liegt im Kubernetes-Bereich, wo ich für alle Kubernetes-Cluster im weitesten Sinne zuständig bin. Dabei unterstütze ich vor allem bei der Orchestrierung und bin für den Zustand der Cluster verantwortlich. Zusätzlich kümmere ich mich um den gesamten Lifecycle rund um das Thema Kubernetes – vom Starten des Clusters über das Resizing bis hin zur Löschung. Zudem bin ich beim Thema OpenStack dabei und kümmere mich dabei vor allem um die Netzwerk-Themen, also um den Netzwerkaufbau, Bare Metal, OpenStack-Controller, Hypervisoren und die Anbindung von Hardware an das Netzwerk.

An welchen Stellen greifst du aktiv in Architektur- oder Designentscheidungen ein?

Ich gebe meine Meinung an den Stellen ab, wo ich weiß, dass ich die notwendige Erfahrung habe, vielleicht eine Alternative kenne und es mir sinnvoll erscheint. Bei uns im Team ist das sehr offen gestaltet. Alle Mitarbeitenden sind sehr offen für Ideen und Verbesserungsvorschläge. Wenn mir etwas einfällt, dann gebe ich gerne meine Meinung dazu.

Welche Tools und Frameworks sind aus deiner Sicht unverzichtbar im Kubernetes-Betrieb?

Mittlerweile sehe ich den Cert-Manager als das wichtigste Tool, um Zertifikate zu verwalten. Das ist für Kubernetes zwingend notwendig, um Dienste nach außen zu legen. Ebenfalls wichtig ist mir die Gateway API. Das spielt für mich mittlerweile auch eine zentrale Rolle. Aktuell wird sie zwar noch nicht gerne in den Bestandsclustern genutzt, aber das wird sich bald ändern. Es gibt inzwischen viele Implementierungen zur Ablöse von Ingress-Controllern. Daher ist es einfach die neue Methode, um Dienste nach außen zu legen, weshalb ich die Gateway API auch sehr wichtig finde. Sie ist ein sehr integrales Tool für Kubernetes. Zusätzlich finde ich Operator im weitesten Sinne unverzichtbar. Das ist der große Vorteil für Kubernetes: Mit Operatoren lassen sich Dienste und Workflows vereinfachen und optimieren, indem sie bestimmte Dienste verwalten. Wenn man sich z. B. ein PostgreSQL-Cluster (Datenbankcluster) vorstellt, gibt es einen Operator namens CNPG (Cloud Native PostgreSQL), der sich um den kompletten Lifecycle des Datenbankclusters kümmert, inklusive horizontaler Skalierung, Backups und Snapshots. Das vereinfacht den Ablauf vielerlei Dienste, wenn man Cluster betreibt.

Wie setzt du Themen wie RBAC, NetworkPolicies und Secret-Management um?

Es gibt sehr viele Nuancen und Dinge, die man beachten kann, muss und sollte. Das hängt davon ab, in welcher Hinsicht man das betrachtet. Was man auf jeden Fall sagen muss, ist, dass man viel testen muss. Wenn man beispielsweise eigene Operatoren schreibt, müssen diese auch mit der Kubernetes-API kommunizieren. Dabei muss man darauf achten, die richtigen RBACs zu verwenden und entsprechend das freizugeben, was minimal nötig ist. Bei den NetworkPolicies kann man mit Cilium Hubble viel erreichen. Cilium Hubble wird bei uns standardmäßig mit ausgeliefert und bietet die Möglichkeit, den Netzwerkverkehr zu sehen, an welcher Stelle welche Flows gedroppt werden und wo der Traffic nicht weitergeleitet oder erlaubt wird. Damit kann man die NetworkPolicies erstellen und nach und nach mehr freigeben, bis alles wie gewünscht funktioniert. Für das Secret-Management nutze ich aktuell Sealed Secrets. Das bietet einfache Möglichkeiten, Kubernetes-Secrets zu verwenden, zu verschlüsseln und in Git abzuspeichern. Dann kann man diese mit dem GitOps-Tool der Wahl ausrollen und in einem Public Repository speichern, ohne dass man Gefahr läuft, dass irgendwelche Secrets geleakt werden. Es gibt auch andere Möglichkeiten, wie den External Secrets Operator, bei dem man das natürlich auf andere Weise in anderen Stores außerhalb von Kubernetes definieren kann.

Wie fließt Kundenfeedback in technische Verbesserungen der Plattform ein?

Wir sind jederzeit bereit, Kundenfeedback anzunehmen. Je nach Feedback setzen wir es auch fast immer um. Ein Beispiel ist das Kubernetes-API-Thema, bei dem der Wunsch geäußert wurde, dass es intern bleiben und nicht von außen erreichbar sein soll. Das ist durch Feedback entstanden. Daher setzen wir Ideen und Wünsche von Kunden sehr gerne um und evaluieren dazu die neuesten Technologien. Aktuell ist beispielsweise der Dualstack-Loadbalancer ein Thema, den wir gerne für einen Kunden umsetzen möchten.

Was war dein komplexestes Kubernetes-Problem – und wie hast du es gelöst?

Das komplexeste Kubernetes-Problem war Gardener selbst, unsere neue Plattform, um Kubernetes zu deployen. Da dort vieles ineinander verschachtelt ist und ineinandergreift. So benötigt man beispielsweise zunächst ein initiales Cluster, um überhaupt Gardener deployen zu können. Somit kann man seinen eigenen Cluster erstmal nicht selbst managen. Dadurch entsteht ein Henne-Ei-Problem, sodass man sich mit anderen Tools behelfen muss.

Welche Kubernetes-Features oder -Trends findest du aktuell besonders spannend?

Da kann ich noch einmal auf das zurückkommen, was ich vorhin gesagt habe: Gateway API. Die Gateway API ist ja der Ingress 2.0, also die Ablöse dafür. Das finde ich aktuell sehr spannend, weil vieles möglichst universell gehalten wird, ohne die Differenzierung zwischen Implementationen zu vernachlässigen. Hier muss man nicht wie bei Ingress zig Annotations setzen, die leider zu häufig Sicherheitsproblem bereiten, siehe Ingress-Nginx. Bei Gateway API wird versucht, die API möglichst universell zu halten, sodass man seinen Gateway-API-Controller im Fall der Fälle einfach austauschen könnte. Daher denke ich, dass das in Zukunft noch sehr spannend werden kann. Ebenso bietet die Gateway API Möglichkeiten, KI-Modelle per API verfügbar zu machen und den Zugriff zu kontrollieren. Auf der KubeCon war es das Thema.

Was motiviert dich persönlich an der Arbeit mit Kubernetes?

Kubernetes bietet die Möglichkeit, gewisse Zustände zu deklarieren und jederzeit dorthin zurückzukehren, ohne dass man selbst Hand anlegen muss. Zudem kann man etwas spezifizieren, das dann wie von Geisterhand mit Operatoren ausgerollt wird, was einem das Leben vereinfacht. Zugegeben, die Einstiegshürde ist sehr groß. Aber sobald man sich damit auseinandergesetzt hat, ist es ein wunderbares Tool, um seine Workloads auszuführen und seine Anwendungen darauf aufzubauen.