Kubernetes als Steuerungsebene für alles: Crossplane v2

Hier ist eine häufige Situation. Ein Entwickler braucht eine Datenbank für einen neuen Dienst. Sie öffnen ein Ticket. Jemand im Einsatzteam schreibt Terraform, öffnet eine Anfrage, wartet auf die Überprüfung, wendet sie an und sendet die Verbindungsdetails zurück. Zwei Tage später kann der Entwickler endlich anfangen.

Crossplane stellt eine andere Frage: Was wäre, wenn der Entwickler einfach eine kleine YAML-Datei schreiben könnte, so wie sie ihre App bereitstellen, und eine ordnungsgemäß konfigurierte Datenbank wenige Minuten später bekommt?

Die Idee in einem Absatz

Kubernetes ist in einer Sache sehr gut: Sie beschreiben, was Sie wollen, und die Controller arbeiten weiter, bis die Realität übereinstimmt. Crossplane erweitert diese Idee über Container hinaus. Es fügt Controller hinzu, die Cloud-Ressourcen erstellen und verwalten: Datenbanken, Eimer, Warteschlangen, Netzwerke, DNS-Einträge. Sie schreiben YAML, Crossplane spricht mit AWS, Azure oder Google Cloud und hält die Ressource im von Ihnen beschriebenen Zustand.

Das wirklich Interessante ist nicht die Verwaltung von Roh-Cloud-Ressourcen. Es ist... Erstellen Sie Ihre eigenen APIs Ich habe sie über ihnen.

Kompositionen: Ihre eigene Plattform API

Mit Crossplane definiert das Plattformteam eine einfache, firmenspezifische Ressource, zum Beispiel Database, wobei nur die Felder, die Entwickler interessieren sollten:

apiVersion: platform.example.com/v1alpha1
kind: Database
metadata:
  name: orders-db
  namespace: shop
spec:
  engine: postgres
  size: small

Hinter den Kulissen Zusammensetzung macht das zu allem, was das Unternehmen braucht: eine RDS-Instanz mit der richtigen Version, Verschlüsselung, Backups, eine Subnetzgruppe, Sicherheitsgruppenregeln, Überwachung und ein Kubernetes-Geheimnis mit den Verbindungsdetails. Der Bauherr sieht fünf Zeilen. Das Plattformteam kontrolliert die anderen 200.

Das Schema dieser benutzerdefinierten Ressource ist in einem Die Definition der CompositeResource (XRD)- Ich weiß . Das ist, wo Sie setzen, was erlaubt ist: vielleicht nur small, medium und largeVielleicht nur Postgres.

Crossplane ermöglicht es dem Plattformteam, "wie wir Datenbanken hier machen" in eine API statt einer Wiki-Seite zu verwandeln.

Was hat sich in V2 geändert?

Crossplane v2 vereinfachte das Modell in einigen wichtigen Punkten:

• - Die Ressourcen sind standardmäßig mit Namen ausgeteilt. In v1 benötigte man normalerweise eine cluster-scoped zusammengesetzte Ressource plus einen Namespaced "Claim". V2 lässt zusammengesetzte Ressourcen direkt im Namespace eines Teams leben, so dass die Claim-Schicht meist verschwinden wird.
• Komponie alles. Kompositionen können nun jede Kubernetes-Ressource enthalten, nicht nur die von Crossplane verwalteten Cloud-Ressourcen. Sie können eine Bereitstellung, einen Service und eine Cloud-Datenbank in einer höheren API "App" bündeln.
• Die Zusammensetzung ist die Standardform um die Logik in YAML-Vorlagen, Go, Python oder KCL zu schreiben, anstelle des alten Patch-and-Transform-Stils.

Wenn Sie vor ein paar Jahren Crossplane ausprobiert haben und es schwer gefunden haben, ist V2 einen zweiten Blick wert.

- Crossplane oder Terraform?

Diese Frage kommt immer auf, und die ehrliche Antwort ist: Sie sind gut in verschiedenen Dingen.

Terraform (oder OpenTofu) ist ideal für Infrastruktur, die das Plattformteam besitzt und absichtlich ändert: Netzwerke, Cluster, Konten. Es läuft, wenn du es machst, zeigt einen Plan und stoppt.

Überlaufflugzeug ist großartig für Self-Service-Ressourcen, die viele Teams oft benötigen: Datenbanken, Eimer, Warteschlangen pro Dienst. Es läuft kontinuierlich, fixiert automatisch Drift und passt in GitOps mit Argo CD oder Flux.

Viele Teams verwenden beides. Terraform baut das Fundament, einschließlich des Clusters, das Crossplane betreibt. Crossplane bietet die Selbstbedienungsschicht oben.

Erstellen einer "Gib mir eine Datenbank" API

Wenn ich Crossplane zum ersten Mal probieren würde, würde ich den Bereich klein halten:

1. Crossplane mit Helm in eine Testgruppe installieren.
2. Installieren Sie den Provider für Ihre Cloud und geben Sie ihm Anmeldeinformationen über Workload-Identität anstelle statischer Schlüssel.
3. Schreiben Sie eine XRD für ein Database mit zwei Feldern.
4. Schreiben Sie eine Komposition, die eine kleine verwaltete Datenbank und ein Verbindungsgeheimnis erstellt.
5. Erstellen Sie eine Database in einem Namespace und sehen Sie, wie es in Ihrer Cloud-Konsole erscheint.

Dann zeig es einem Entwickler und frage ihn, ob es nützlich ist. Dieses Gespräch ist wertvoller als jedes Architekturdiagramm.

Was man beachten sollte

• Fehlerbehebung ist schwieriger als einen Terraform-Plan zu lesen. Lernen kubectl describe und Crossplane's Spurenwerkzeug früh.
• Löschung ist real. Das Löschen der YAML löscht die Datenbank. Verwenden Sie Löschrichtlinien und schützen Sie Produktionsressourcen.
• Größe des Anbieters. Einige Anbieter installieren Hunderte von CRDs. Verwenden Sie die kleineren "Familien" - Dienstleister nur für die Dienstleistungen, die Sie benötigen.

Meine Meinung: Crossplane glänzt, wenn man es als eine Möglichkeit betrachtet, seine eigene Plattform-API zu erstellen, nicht nur eine andere Möglichkeit, Infrastruktur zu schreiben.

Desly