Ein Kubernetes-Operator für S3

Als SRE-Berater für interne Teams sah ich immer wieder dasselbe Muster. Die meisten Ausfälle begannen mit einem manuellen Eingriff.

Einer davon begann mit einer Firewall­regel. Jemand korrigierte sie von Hand und vergass, den Code anzupassen. Das nächste Deployment brachte die alte Regel zurück. Die Verbindungen brachen erneut ab.

Also versuchten wir, einen Kubernetes-Operator für die Firewall­regeln zu bauen. Doch der Ablauf hatte manuelle Freigabe­stufen. Jede Freigabe mussten wir in die Events von Kubernetes zurückspeisen. Eine Freigabe gehört ins Code-Review, bevor der Operator läuft. Dieser spezifische Ablauf liess das nicht zu.

Beim Speicher war es noch schlimmer. Die meisten Handgriffe waren CLI-Befehle in einem Pod. Lief ein Befehl zweimal, konnte er Schaden anrichten. Und Kubernetes wusste nicht, wie es um den Speicher stand.

Mit Houston vermeide ich solche Fallstricke bei ObjectGateway. Teams beschreiben ihren Speicher als Code, und ihr Review-Prozess gibt ihn frei. Houston hält alle Komponenten im gewünschten und erwarteten Zustand. Damit es um 3 Uhr nachts keinen Unfall gibt, lehnen das CLI ogw und die Console Änderungen ab, die als Code verwaltet werden.

Zuerst ein Prototyp

Die erste Version von Houston war ein Prototyp: ca. 39’000 Zeilen Code, 18 Custom Resources und 5 Prozesse und Jobs. Er war auf Funktionen ausgelegt, die Core noch nicht hatte, und wurde dadurch aufgebläht. Die Funktionen, die auf fehlende APIs warteten, wurden nie getestet.

Deshalb baut die neue Version nur auf dem auf, was Core bereits heute unterstützt.

Wo der Prototyp scheiterte

Der Prototyp nutzte einen einzelnen Schlüssel für alles. Selbst die Anfragen der Teams liefen mit dem Schlüssel des System-Accounts. Der Operator musste die einzelnen Teams auseinanderhalten, um die Berechtigungen zu kontrollieren.

Der heikelste Teil war die Verteilung der Schlüssel an die Teams. Sie liefen verschlüsselt über mehrere Hilfs­programme. Fiel einer dieser Schritte aus, war der Fehler kaum zu beheben.

Auch im Alltag war der Prototyp anfällig. Das Löschen eines Namespaces blieb oft hängen, und jemand musste von Hand aufräumen. Zudem musste jede Änderung erst durch einen Webhook. Bei einem Ausfall des Webhooks liess sich nichts mehr ändern.

Was sich geändert hat

Die neue Version übernimmt das Bewährte und lässt den Rest weg.

• Die Trennung der Teams übernimmt jetzt das Gateway statt des Operators. Jeder Namespace erhält einen Service-Account in seinem Account. Kein Team erreicht mit seinen Anfragen den Account eines anderen.
• Schlüssel landen direkt in einem Kubernetes-Secret, und Core rotiert sie. Anwendungen lesen sie über die üblichen AWS-Variablen und müssen nicht angepasst werden.
• Beim Löschen bleiben die Daten standardmässig erhalten. Ein übergeordnetes Objekt wird erst gelöscht, wenn alle untergeordneten Objekte entfernt sind.
• Beim Anwenden einer Ressource prüft das Schema jedes Feld automatisch, auch wenn Houston nicht läuft.
• Houston hat keinen eigenen S3-Client. Die Schlüssel von Houston selbst können keine Objekte lesen oder schreiben. Versionierung und Lifecycle-Regeln verwalten Teams weiterhin in S3, mit ihren gewohnten Tools.

Ein Kubernetes-Operator funktioniert am besten, wenn der Zustand nur an einem Ort liegt. Ohne Schutz könnten aber auch das CLI und die Console dieselben Ressourcen ändern. Deshalb vermerken die Ressourcen von ObjectGateway jetzt, wer sie verwaltet. Was Houston verwaltet, ändern das CLI und die Console nicht.

Seit Core OIDC unterstützt, können Teams ihre Identity Provider auch direkt in Houston einrichten.

Einfacher im Betrieb

Die Architektur ist deutlich einfacher als beim Prototyp. Houston kommt mit halb so viel Code und 9 statt 18 Custom Resources aus. Statt 5 Prozessen und Jobs läuft nur noch 1 Prozess.

Für Sie heisst das: weniger bewegliche Teile. Sie überwachen einen Prozess und lesen ein Log. Wenn etwas schiefgeht, müssen Sie nur an einer Stelle suchen.

Die Startseite zeigt, wie die Ressourcen von Houston aussehen.