Kubebuilder und ein Custom CRD – Möge die Macht mit dir sein!

Die Kubernetes API stellt bereits eine ganze Menge an verschiedensten Ressourcen für die Container-Orchestrierung bereit: Services, Deployments, Ingress-Objekte, Namespaces, RBAC und viele mehr. Allerdings kann es manchmal nötig sein, diese API um weitere Typen zu erweitern. Sei es, um ggf. einen externen Webservice anzusprechen und aber diesen zur Laufzeit wie ein Kubernetes-Objekt zu behandeln. Eine gute Möglichkeit, dies zu erreichen, sind sogenannte Custom Resource Definitions (CRD). Um die Implementierung dieser zu vereinfachen, wurde im Juli von der Kubernetes API Machinery SIG das Tool Kubebuilder veröffentlicht. Ziel von Kubebuilder ist es, die Implementierung von CRDs durch Abstraktion zu vereinfachen und gleichzeitig die bereits bestehenden Vorteile von Kubernetes (kubectl, RBA etc.) direkt mit zu unterstützen.

Doch was macht es und wie funktioniert es? Welche weiteren Möglichkeiten gibt es?

Kubebuilder – Was und wie?

Stand heute ist Kubebuilder in der Version 1.0.5 verfügbar. Ziel des Frameworks ist die Implementierung der CRD über das sog. Controller Pattern . Ein klassischer Controller benötigt von Grund auf das Handling mit diversen weiteren Komponenten der Kubernetes API (Lister, Informer etc.). Darüber hinaus müssen im klassischen Ansatz diverse Dateien von Hand erstellt werden, damit ein Code-Generator fehlende Teile generieren kann. Kubebuilder nimmt einem dies ab. Er übernimmt die komplette Generierung eines Projektes. Von den Controllern über die Resource Models, Tests, CRDs, RBAC Settings und vieles mehr. Dies ermöglicht einem die Fokussierung auf die Implementierung des eigentlichen Use Cases.

Ablauf

Die offizielle Dokumentation zu Kubebuilder gibt bereits einen guten Überblick über die notwendigen Schritte zum Starten eines Projektes. Zuerst muss die Kubebuilder Binary auf dem eigenen Rechner installiert werden. Ist dies geschafft, ist es tatsächlich nicht mehr als ein:

1kubebuilder init --domain meinedomain.tld --license <license der Wahl> --owner

Die darauf folgende Anfrage sollte mit „y“ beantwortet werden, um das lokale Vendoring mit dem Dependency Manager dep zu initialisieren.

Sobald das geschafft ist, existiert bereits ein lauffähiges Projekt. Allerdings ohne einen CRD. Dieser kann einfach über

1kubebuilder create api --group <group> --version v1beta1 --kind <kind>

erzeugt werden.

Innerhalb des Verzeichnisses pkg/apis/… findet sich der CRD-Code wieder, zu dem nach Belieben z. B. Felder hinzugefügt werden können. Der Platz für die Controller-Implementierung findet sich unter pkg/controller/…

Demo-Implementierung

Um dem Ganzen ein bisschen näher zu kommen, habe ich ein Demo-Projekt vorbereitet. Dieses benutzt den Custom CRD „Starship“, um sich entsprechende Daten aus der bekannten Star Wars API zu laden.

Dies bedeutet für den zusammengefassten Ablauf:

• Ein Starship wird im Cluster deployed
• Controller bemerkt Änderung und bekommt die Spec des Starships
• Nimmt designierten Namen des Schiffes aus dem Spec
• Durchsuchung der API nach dem Schiff
• Objektstatus mit entsprechenden Daten aktualisieren

Hat alles geklappt, kann das Objekt per kubectl ganz einfach abgefragt werden und man bekommt die folgenden Antworten:

Weitere Informationen, wie ihr das Ganze z.B. selber einmal testen könnt, findet ihr auf dem GitHub Repository .

Weitere Möglichkeiten

Weitere Möglichkeiten, vereinfacht eine derartige Implementierung zu bekommen, ist das Operator Framework von RedHat/CoreOS oder Metacontroller der Google Cloud Platform. Beide Projekte verfolgen einen ähnlichen Ansatz, zeigen aber dennoch Unterschiede auf.

Fazit

Kubebuilder macht das Entwickeln von Custom CRDs deutlich einfacher. Verglichen mit einer CRD-Implementierung von Grund auf ist der vorgestellte Ansatz deutlich einfacher und schneller. Ob die daraus resultierende, starrere Struktur auch in komplexen Szenarien funktioniert, kann ich noch nicht beurteilen. Interessant ist dieser Ansatz aber auf jeden Fall.