Das Problem

Bei Carrot & Company finden wir uns oft in der Situation wieder, an mehreren Kubernetes-Projekten parallel zu arbeiten, was häufiges Wechseln zwischen Kubernetes-Kontexten erfordert. Um ehrlich zu sein, ist es mir schon in der Vergangenheit passiert das ich Änderungen versehentlich im falschen Kontext ausgeführt habe - glücklicherweise nur auf einem lokalen Test-Kubernetes-Cluster. Diese Erfahrung brachte uns dazu, über Wege nachzudenken, wie wir unterschiedliche Kubernetes-basierte Projekte lokal mit kubectl von unseren Entwicklermaschinen aus sicher und effizient verwalten können.

Unser Lösungsansatz

Die parallele Entwicklung und Verwaltung mehrerer Software oder DevOps-Projekte erfordert von sich aus schon eine ordnungsgemäße Trennung; wir erreichen diese, indem wir sicherstellen, dass jedes Projekt so weit wie möglich in seinem eigenen Ordner selbstständig lebt. Daher sollten alle Konfigurationen, Abhängigkeiten und Werkzeuge auf den Ordner des jeweiligen Projekts beschränkt sein. Moderne Werkzeuge unterstützen diesen Ansatz, zum Beispiel npm mit der package.json und dem Ordner node_modules .

Wir haben eine ähnliche Strategie für unsere Kubernetes-Kontexte umgesetzt, die sowohl leicht zu pflegen und gleichzeitig auch einfach zu verstehen ist.

Einrichtung

Wie richten wir also unsere Projekte ein, um dies zu ermöglichen? Das Kernwerkzeug unseres Ansatzes ist ein kleines, aber leistungsstarkes Open-Source-Tool namens " direnv ". Es wurde zwar nicht speziell für Kubernetes entwickelt, ermöglicht uns aber das Wechseln des Shell-Environments basierend auf Projektordnern.

Mit direnv können wir eine .envrc -Datei erstellen, in der wir Umgebungsvariablen festlegen können, die nur gesetzt werden, wenn wir mit cd in den Projektordner wechseln, der die .envrc -Datei enthält. Verlassen wir den Projektordner mit cd .. , wird das vorherige Shell-Umfeld wiederhergestellt. Das ist schon mal nett, aber wie können wir das für unseren Kubernetes-Kontext nutzen? Ganz einfach. Wir setzen unsere KUBECONFIG -Umgebungsvariable in der .envrc -Datei wie folgt:

export KUBECONFIG=$(pwd)/.kube/config

Wie hilft uns das? Normalerweise befindet sich die Konfiguration für kubectl im Home-Verzeichnis des Benutzers unter ~/.kube/config . In dieser Datei können wir mehrere Kubernetes-Kontexte angeben, aber sie müssen manuell gewechselt werden und sind dann global gültig — nicht auf Shell-Basis, wie wir es gerne möchten.

Durch Überschreiben der KUBECONFIG -Umgebungsvariablen können wir jedoch kubectl und Werkzeuge wie Helm anweisen, eine andere Konfigurationsdatei zu verwenden. Hier wird .envrc nützlich: Es lenkt die KUBECONFIG -Umgebungsvariable auf eine lokale kubectl -Konfiguration im Projektordner um, anstatt im Home-Verzeichnis. Wenn beispielsweise unser Projektordner myproj ist, sollte die kubeconfig-Datei in myproj/.kube/config abgelegt werden. Natürlich kann dieser Ort geändert werden, aber um ein leicht zu verstehendes mentales Modell beizubehalten, verwenden wir einen ähnlichen Ort wie im Home-Verzeichnis des Benutzers.

Nachdem dies erledigt ist, sollte alles wie erwartet funktionieren, vorausgesetzt, ihr habt direnv gemäß der Dokumentation korrekt eingerichtet. Vergesst nicht den zweiten Schritt nach der Installation von direnv – die Konfiguration eurer Shell. (Das habe ich anfangs vergessen und mich gewundert, warum es nicht funktioniert.)

Vorteile

Im Gegensatz zum Standardverhalten bei der Arbeit mit kubectl , das einen globalen Kubernetes-Kontext verwendet, bietet ein ordnerspezifischer Kubernetes-Kontext mehrere Vorteile:

Ordnerspezifischer Kontext

Mit dem Kubernetes-Kontext, der auf den Ordner beschränkt ist, besteht kein Risiko, versehentlich Konfigurationen für einen anderen Cluster zu ändern, während man im Projektordner arbeitet. Das erhöht die Sicherheit und reduziert Fehler.

Mehrere Kubernetes-Kontexte parallel

Der ordnerbasierte Ansatz erleichtert die Arbeit an mehreren Projekten über mehrere Terminals hinweg, ohne sich Sorgen machen zu müssen, ob in jedem Terminal der richtige Kubernetes-Kontext gesetzt ist. Dieser nahtlose Betrieb ist mit dem beschriebenen Setup möglich und eliminiert die Notwendigkeit manueller Eingriffe.

Schnelles Wechseln zwischen Kubernetes-Projekten und -Kontexten

Das Wechseln zwischen verschiedenen Kubernetes-Projekten und ihren entsprechenden Kontexten ist so einfach wie das Wechseln von Verzeichnissen in eurem Terminal. Diese Methode ist super schnell und deutlich weniger fehleranfällig im Vergleich zum manuellen Ändern des Kontexts.

Demo

Anhand von zwei Beispielprojekten myproj und anotherproj , die beide mit diesem Ansatz eingerichtet wurden, sieht es so aus, wenn man ein Kubernetes-Projekt/Kontext wechselt:

Der Quellcode für diese Demo findet sich in diesem Repository .

Andere nützliche Tools

Zusätzlich zu direnv nutzen wir noch andere Tools, um unseren Kubernetes-Workflow für unsere Entwicklermaschinen zu optimieren:

• kube-ps1 (Zsh Plugin): Zeigt den aktuellen Kubernetes-Kontext und Namespace direkt im Shell-Prompt an und hält euch ständig über den Kontext, in dem ihr arbeitet, informiert, ohne dass zusätzliche Befehle ausgeführt werden müssen.
• kubectl (Oh My Zsh Plugin): Verbessert das Shell-Erlebnis, indem es eine Autovervollständigungsfunktion für kubectl hinzufügt, die sogar bis zur Ebene der Kubernetes-Ressourcen-ID reicht. Diese Funktion beschleunigt die Eingabe von Befehlen erheblich und reduziert Fehler.
• kubectx : Von diesem Tool nutze ich speziell den Befehl kubens für schnelles Wechseln zwischen Namespaces.
• ctlptl : Obwohl nicht direkt mit der Shell-UX verbunden, ist ctlptl ein tolles Werkzeug, das ich für das deklarative erstellen von lokalen Entwicklungskubernetes-Clustern mit nur einem einzigen Befehl verwende. Entwickelt vom Tilt Team, vereinfacht es die Verwaltung lokaler Cluster. Wenn ihr Tilt noch nicht ausprobiert habt, empfehle ich es wärmstens. Es ist ein hervorragendes Werkzeug für die lokale Kubernetes-Entwicklung mit super-schnellem Live-Reloading.

Wenn ihr daran interessiert seid, eure Fähigkeiten in der Webentwicklung zu erweitern, schaut euch doch die Web Development Masterclass an

Join the Web Development Masterclass