Kapitan an der Spitze von Kubernetes

Treffen Sie Kapitan . Es hilft Ihnen, Schönheit und Ordnung in Ihre Kubernetes- Konfiguration zu bringen.

Kapitan verdient einen guten Ruf durch zufriedene Nutzerbewertungen und verzichtet daher auf umfangreiche Dokumentation und teures Marketing. Wir haben genug Stars und ein paar Erwähnungen von Kubernetes Bloggern und Predigern. Kapitan wurde sogar zum Protagonisten eines ganzen Kapitels des Buches . Vor allem erregte er die Aufmerksamkeit mehrerer vielversprechender Unternehmen, da Kapitan wie kein anderer in der Lage ist, die mit dem Seeknoten verbundene Konfiguration zu enträtseln.

Auf kubernetes.slack.com hat #kapitan es geschafft, eine kleine, aber engagierte Community zusammenzubringen (mach mit!). Wir sind also stolz auf unsere Arbeit :)

Viele glauben immer noch, dass Kapitan eine Mischung aus jsonnet und jinja ist, aber sie verpassen den Punkt.
In diesem Beitrag werde ich Ihnen erklären, wie Kapitan Kubernetes-Bereitstellungen verwaltet, aber im Allgemeinen kann es mehr. Dies ist wichtig: Kapitan ist universell und nicht auf ein Kubernetes fixiert. Kubernetes ist einfach eine von vielen Anwendungen.

Dies ist kein Leitfaden (obwohl ich auch einen Leitfaden verspreche). Ich möchte Ihnen nur sagen, warum wir es getan haben und welche Probleme mit der Bereitstellung von Kubernetes-Konfigurationen es lösen sollte.

Was mir nicht gefallen hat

Ich habe 2015 angefangen, mit Kubernetes zu experimentieren und mich sofort verliebt.
Es stimmt, es gibt einige Nachteile, die ich nicht ertragen möchte:

• Kontext . Für mich ist dies eines der am schwierigsten zu verstehenden Konzepte von Kubernetes - und eines der gefährlichsten. Der Kontext bezieht sich auf den Client, ist schwer zu verstehen, wird verwirrt aufgerufen und sorgt beim Ausführen von kubectl- Befehlen für Verwirrung. Ich hasse Kontexte in Kubectl!
• Ausführliche verschachtelte Konfiguration (yaml!) . Ich musste schwitzen, um jede Ebene der Yaml-Konfiguration im Manifest herauszufinden. Was bringt es, Etiketten zwei- bis dreimal an mehreren Stellen zu wiederholen?
• Ein Durcheinander mit imperativen und deklarativen Teams . Neulinge in Kubernetes werden von imperativen Teams ermutigt, zu lernen, obwohl es klar ist, dass normale Menschen sie nicht benutzen. Meiner Meinung nach ist es nur schwieriger, Kubernetes in die richtige Bereitstellungsstrategie für Ihr Unternehmen zu integrieren. Spoiler: Es gibt keine einzige „richtige Strategie“.
• Laufzeitkonfiguration . Jesse Suen hat Recht, wenn er davon abrät, Konfigurationsparameter an die Steuerbefehlszeile (oder an kubectl und ähnliche) zu übergeben. Mit Parametern kann derselbe Befehl jedes Mal anders ausgeführt werden.
• Anwendungskonfiguration Wir haben gelernt, wie man mit Yaml-Manifesten in Kubernetes umgeht. Wir sind großartig. Das ist knapp unter und Deploy - das ist eine leere Schüssel. Die Anwendung muss weiterhin mit ihrer gesamten Konfiguration schweben.
• Entwickler wollen Urlaub , und der Workflow bei Kubernetes ist immer noch etwas verschwommen. Kubernetes-Fans zwingen alle, es genau dort zu tun. Ist es notwendig Gehorche Kelsey Hightower!
• Betreiber Ich habe gemischte Gefühle für sie, also verlasse dieses Thema jetzt :) Ich kann nur sagen, dass sie oft missbraucht werden.
• Idempotenz . Eher ihre Abwesenheit. Wenn wir alle oben genannten Mängel addieren, erhalten wir unzureichend idempotente Workflows, was für Kubernetes traurig ist.

Was zu tun ist?

Ich habe versucht, diese Probleme zu lösen und ein kleines Template-System zusammengestellt, das j2cli und ein paar Bash-Skripte zur Verwaltung der Kubernetes-Konfigurationen verwendet.

Das System hat alles in die Datei environmentA.yaml eingefügt und in der Jinja2-Vorlage verwendet. Das Bereitstellen von Anwendungen im Microservice-Stil aus mehreren Komponenten war mit einem einfachen Befehl möglich:

bin/apply.sh environments/environmentA.yaml 

Cool! Bei Yaml ging es nur um den Einsatz. Dies ist sehr praktisch, da ich dieselbe Datei als Informationsquelle für etwas anderes verwenden könnte. Sagen Sie für ... Bash-Skripte !

Ich habe herausgefunden, wie man Werte aus yaml in Skripte importiert, um ähnliche Befehle auszuführen:

 bin/create_kafka_topics.sh environments/environmentA.yaml 

Und dann geriet alles auf einmal außer Kontrolle :

• Ich konnte mit der Struktur in der Yaml-Datei nichts anfangen. Es war ein Mischmasch aus denselben Feldern, Werten und einer verwirrten Konfiguration.
• Sie werden nie wissen, wie Sie sich bei der Bereitstellung in der Umgebung verhalten, bis Sie es versuchen. Dies war häufig auf Änderungen in jinja2-Vorlagen zurückzuführen, die auf einen neuen Inventarwert (z. B. feature_X) zurückzuführen waren, der in Umgebungen, in denen diese Funktion nicht definiert ist, nicht funktionierte.
• Das gleiche Problem mit Skripten: Wenn Sie es nicht versuchen, wissen Sie es nicht.
• Manchmal änderten sich Kubernetes so schnell, dass es mich störte, die Manifeste für verschiedene Versionen ständig zu ändern, insbesondere wenn ich mit Anmerkungen zu den Werten herumspielte.
• Externer Faktor : Das Entwicklungsteam wechselte von Konfigurationsdateien zu Befehlszeilenparametern. Eine so kleine Änderung verwirrte uns alle Karten und wir mussten über eine neue Lösung nachdenken.
• Am wichtigsten : Das Schablonieren von Yaml mit Jinja (oder Go-Vorlagen) macht keinen Spaß! Wir hatten dann ein Rätsel: „ Was sieht aus wie Text, liest sich wie Text, riecht nach Text, aber nicht nach Text? ". Oder, wie Lee Briggs es treffend ausdrückte: „ Warum zum Teufel sind wir Schablonen-Yaml? ""

Kapitan: Werden

Wir sammelten all unsere bitteren Erfahrungen und begannen zusammen mit Ricardo Amaro, über ein ideales Konfigurationsmanagementsystem zu phantasieren. Dann hatten wir noch kein klares Bild, aber wir wussten, dass wir liebten und dass wir nicht liebten.

Liebe :

• Git.
• Musterung im Allgemeinen: Daten / Werte getrennt von Mustern.
• Separate Werte für verschiedene Aspekte (Anwendung, Kubernetes, Laufzeit ...).
• Objektorientierter Ansatz.
• Vereinfachtes Yaml als Schnittstelle, um die Komplexität von Kubernetes zu verbergen.
• Ein klares Verständnis dafür, was passiert und warum.
• Wiederverwendung von Werten in verschiedenen Komponenten.
• Und Skripte sollten Zugriff auf Werte haben.

Wir mögen nicht :

• Kubectl-Kontexte
• Textvorlagen-Engines zum Erstellen von Yaml.
• {{ toYaml .Values.resources | indent 10 }} Einrückungen: {{ toYaml .Values.resources | indent 10 }} {{ toYaml .Values.resources | indent 10 }} .
• Magie: Alles sollte klar und deutlich sein. Keine Tricks.
• Manuelle Verwaltung von Passwörtern und Geheimnissen der Anwendung.
• Pinnenansatz: Wir wollten die Verwendung von Manifesten kontrollieren.
• Git-Crypt-Ansatz: Geheimnisse auf der Festplatte werden nicht verschlüsselt.
• Template-Pipeline direkt zu kubectl.
• Befehlszeilenoptionen übergeben.

Und dann passierten zwei Dinge :

1. Wir haben Dave Cunninghams jsonnet entdeckt, um yaml / json in einer objektorientierten Sprache zu erstellen.
2. Gustavo Buriola zeigte uns die Neueinstufung , und ohne ihn wären wir nicht weit gegangen.

Ricardo Amaro machte sich an die Arbeit, und bald setzte sich das gesamte Team bei Kapitan zusammen - einige arbeiteten an der Hauptfunktionalität, andere an der Verwendung in unseren internen Projekten. Secrets Management, gpg \ kms Support, benutzerdefinierte Funktionen: Jetzt ist Kapitan ein vollwertiges Produkt, das mehr als versprochen leistet.

Wer ist Kapitan?

Kapitan versucht, alle (oder fast alle) Probleme zu lösen, über die ich gesprochen habe.

Aus technischer Sicht ist Kapitan sehr einfach:

• Inventar : Eine hierarchische Sammlung von Werten, die die Bereitstellung basierend auf Yaml beschreiben. Basierend auf Neueinstufung. Wie hiera.
• Template Engines : Jetzt ist es Jinja2, Jsonnet, Kadet. Sie führen eine Bestandsaufnahme durch und erstellen Dateien (Yaml-, JSON-, Dokumentations- oder Bash-Skripte).
• Geheimnisse : Vorlagengeheimnisse, und Kapitan wird sich mit ihnen befassen.

Wir verwenden jsonnet, um Manifeste zu erstellen , und Jinja, um den Rest zu erledigen.

Manchmal beschweren sich die Leute, dass sich die jsonnet-Datei völlig von derselben yaml-Datei unterscheidet. Daher fällt es ihnen schwer, zu jsonnet zu wechseln.

Wir haben versucht, dieses Problem mit Kadet zu lösen, indem wir yaml in Python verpackt haben. Nehmen Sie Ihr Lieblings-Yaml als Basis und fügen Sie Python hinzu.

Betrachten Sie dies als ein Python-Exoskelett für Yaml! Irgendwie werde ich darüber reden.

Im Workflow zeigt Kapitan sofort den Charakter:

• Wahlfreiheit : Wir schreiben keine Arbeitsprozesse und Technologien vor, sondern arbeiten normalerweise nach den unten beschriebenen Prinzipien. In der Tat kann Kapitan verwendet werden, wie Sie möchten. Sie müssen git nicht verwenden, Sie dürfen keine Dateien darin kompilieren und können sogar auf jsonnet verzichten! Mach was du willst.
• GitOps zum Knochenmark: alles in Git, alles in einem Meisterlicht , das unsere Absicht widerspiegelt.
• Deklarierbarkeit : Kapitan begrüßt die Zusammenstellung von Manifestvorlagen in bestimmten Darstellungen. Und Sie kompilieren Ihre Skripte.
• Kontrollierter Kontext : Wir verwenden kompilierte Skripte, um unsere Arbeit zu vereinfachen, beispielsweise beim Festlegen von Kontexten und beim Konfigurieren von Clustern.
  Kubernetes-Konfiguration: compiled/target_A/setup/setup.sh
  Änderungen übernehmen: compiled/target_A/setup/apply.sh
• Idempotenz : Mit Kapitan können Sie Vorlagen und Code-Refactoring-Tools ändern. Kompilierte Manifeste und Code ändern sich nicht ohne Ihren Befehl, sodass Sie beim Refactoring nichts zu befürchten haben.
• Ursache und Wirkung : Wir sind für einen Workflow, bei dem Änderungen am Inventar oder an Vorlagen und kompilierten Dateien in einer Zusammenführungsanforderung enthalten sind. So kann der Prüfer Ihre Änderungen und ihre tatsächlichen Folgen bewerten. Es ist gut zu wissen, ob sich eine Änderung in der Vorlage auf ein, zwei oder mehr Ziele auswirkt.
• Und schließlich : Kapitan ist nicht an Kubernetes gebunden. Es werden nur Dateien erstellt. Die Bereitstellung von Änderungen betraf kubectl . Wir geben nur eine Shell für Befehle, die auf konsistente Weise ausgeführt werden sollen.

Brauche ich es

Lassen Sie uns klarstellen: Sie brauchen Kapitan wahrscheinlich (noch) nicht.

Aber alles hängt davon ab, was Sie versuchen und wie kompliziert Ihr System ist.

Kapitan ist ein leistungsstarkes Anlageinstrument. Verwenden Sie es in komplexen Szenarien, in denen Sie eine Reihe von Anwendungen auf einem Haufen von Clustern bereitstellen müssen.

Wenn Sie Standardanwendungen haben, gerade Kubernetes lernen oder bereits mit Ihrem Workflow zufrieden sind, funktioniert Helm oder seine aktuelle Alternative.

Ich stelle mir Helm als passend für Kubernetes vor , und Kapitan ist so etwas wie Marionette .

Im nächsten Beitrag werde ich konkrete Beispiele geben und das Inventar detailliert beschreiben. Schreiben Sie in diesem Beitrag darüber, was Sie wissen möchten oder was Sie zustimmen / nicht zustimmen.

Vielen Dank an Jacek Gruzewski .