Mit Kubecarrier ruft das Hamburger Unternehmen Kubermatic (vormals Loodse) ein neues Open-Source-Projekt ins Leben, um den Kunden von Kubernetes-Anbietern zu erlauben, den Lebenszyklus ihrer Kubernetes Operators zentral und über Cluster und Rechenzentren hinweg zu verwalten.

Die von Kubecarrier verwalteten Operators sind dabei selbst bereits Abstraktionen für Cloud Native Anwendungen und Dienste. Oder, wie es Kubernetes-Experte Kelsey Hightower ausdrückt, eine “Methode, um eine Kubernetes-Anwendung zu paketieren, zu verwalten und auszurollen.” Die Operators erleichtern in der Regel den Aufbau von Cloud-Native-Diensten und -Anwendungen in einem Kubernetes-Clusters.

Kommen mehrere Cluster, Public Clouds und Regionen zum Einsatz, wird es hingegen noch schnell unübersichtlich und ist bislang zum Teil Handarbeit angesagt. Kubecarrier soll auch diesen Prozess künftig vereinfachen. Mit der Software verwalten mehrere Kunden eines Kubernetes-Anbieters unabhängig voneinander ihre Operators und damit die Dienste und Anwendungen. Das Framework dient dabei als zentrales Service-Hub, um die Dienste zu verwalten.

Die aktuelle Version 0.3 von Kubecarrier steht unter der Apache-2.0-Lizenz, steckt noch in der Testphase und ist nicht produktionsreif. Künftige Versionen der Software, so steht es auf Github, können zu vorherigen Versionen inkompatibel sein.

Aufbauarbeit

Kubecarrier erzeugt Accounts, die jeweils über einen eigenen Namespace verfügen und in diesen Accounts so genannte Subjects, die verschiedene Rollen einnehmen, etwa “Provider” oder “Tenant” und über bestimmte Zugriffsrechte (RBAC) verfügen. Daneben besteht Kubecarrier aus verschiedenen Komponenten.

Zu diesen gehört etwa das Kubecarrier CLI, ein “kubectl”-Plugin, das als Kommandozeilen-Interface dient. Es überprüft die Umgebung, stößt die Installation an und interagiert mit den Kubecarrier-APIs. Ein Kubecarrier Operator läuft als Kubernetes Controller und behält die Kubecarrier-Installation permanent im Blick. Der Kubecarrier Manager ist die zentrale Komponente, die alle Kontrollstrukturen bereitstellt. Der API-Server ist eine “kube-apiserver”-Erweiterung, bietet ein öffentliches API mit eigenen Authentisierungsmechanismen an.

Dann gibt es noch Ferry, Catapult und Elevator. Die Ferry-Komponente verwaltet die Verbindungen mit einem Service-Cluster, realisiert Health Checks und initialisiert Namespaces im verbundenen Cluster. Catapult kümmert sich darum, “CustomResourceDefinitions” zwischen dem Management- und Service-Cluster abzugleichen. Eine Elevator-Instanz entsteht, wenn eine “DerivedCustomResource” eine “CustomResourceDefinition” generiert.

[Update, 10.8.]: Loodse heißt inzwischen Kubermatic, wir haben das korrigiert.