CRDs ohne Kubernetes: Deklarative Infrastruktur ohne Cluster

  • Veröffentlicht

Kubernetes hat das Infrastrukturmanagement mit benutzerdefinierten Ressourcen (Custom Resource Definitions, CRDs) revolutioniert. CRDs ermöglichen Plattformteams, die Kubernetes-API zu erweitern, um alles zu modellieren und zu verwalten, von Datenbanken bis hin zu ganzen Cloud-Umgebungen.

Aber was, wenn man dieselbe Abstraktion nutzen möchte, ohne an Kubernetes gebunden zu sein?

Genau das ermöglicht Cloudomation, und zwar mit Custom Objects und Object Templates: Es ist eine leistungsstarke, technologieunabhängige Methode, um Infrastruktur- und Plattformdienste zu modellieren und zu verwalten, unabhängig von einer bestimmten Laufzeitumgebung.

Von CRDs zu Custom Objects

In Kubernetes ermöglichen CRDs die Definition eigener Ressourcentypen (MyDatabase, CloudEnvironment, AccessRequest, …) und deren Lebenszyklussteuerung mit Custom-Controllers. Dieses wurde so erfolgreich, dass Projekte wie Crossplane CRDs erweiterten, um auch Ressourcen außerhalb von Kubernetes zu verwalten, wie z. B. AWS RDS oder GCP Buckets. Dabei wurde außerdem dieselbe Kubernetes-native API und den Reconciliation-Loop genutzt.

Cloudomation geht noch einen Schritt weiter.

Mit Object Templates und Custom Objects ermöglicht Cloudomation die Definition eigener Ressourcentypen, genau wie CRDs, aber vollständig losgelöst von Kubernetes.

Alles modellieren — ohne Cluster-Lock-in

Cloudomations Objektmodell ist:

  • Technologieunabhängig — keine Abhängigkeit von Kubernetes oder einer bestimmten Plattform
  • Programmierbar — in Python geschrieben, keine DSLs oder YAML-Schemas, mit denen man kämpfen muss
  • Composable — benutzerdefinierte Objekte können sich aufeinander beziehen und Workflows auslösen
  • Integriert — Interaktion über REST-API oder Webhooks möglich

Du kannst benutzerdefinierte Objekttypen definieren für:

  • VMInstance auf OpenStack
  • ProjectEnvironment über AWS und GCP hinweg
  • CI/CDPipeline in GitLab
  • AppConfig für anwendungsbezogene Feature-Toggles
  • Alles andere, was deine Plattform verwaltet

Jedes benutzerdefinierte Objekt verfügt über Lifecycle-Hooks. Automatisierungspunkte wie before_create, on_create, on_update und on_delete, die:

  • Einmalige Automatisierungen auslösen können (z. B. das Bereitstellen einer Ressource)
  • Eine kontinuierliche State-Synchronisierung ermöglichen (z. B. Drift-Erkennung und -Behebung)
  • Ereignisbasierte Orchestrierung über verschiedene Tools hinweg steuern

Warum das wichtig ist

Platform Engineers verbringen viel Zeit damit, Abstraktionsschichten zu bauen, um Infrastruktur über APIs, GUIs oder CLIs nutzbar zu machen. CRDs waren ein Durchbruch, weil sie:

  • Eine standardisierte Möglichkeit boten, Ressourcen zu modellieren
  • Eine deklarative Schnittstelle für Devs bereitstellten
  • In einen leistungsstarken Reconciliation-Loop zum State-Management eingebunden waren

Cloudomation bietet all das, ohne einen Kubernetes-Cluster zu benötigen oder sich überhaupt für die zugrunde liegende Plattform zu interessieren.

Darum sind die technologieunabhängigen Custom Objects von Cloudomation wertvoll:

  • Befreit vom Kubernetes-Lock-in:
    Die meisten modernen Plattformautomatisierungslösungen setzen Kubernetes voraus oder sind eng daran gekoppelt. Cloudomation bietet die Vorteile deklarativer Ressourcenmodellierung, ganz ohne Cluster.
  • Vereinheitlichte Abstraktionsschicht über alle Infrastrukturen hinweg:
    Du kannst VMs, Cloud-Projekte, SaaS-Konten, CI-Pipelines oder beliebige andere Ressourcen auf konsistente Weise modellieren. Das vereinfacht den Aufbau und die Wartung von Plattformdiensten über verschiedene Technologien hinweg erheblich.
  • Volle Power durch Python-Automatisierung:
    Im Gegensatz zu CRDs, deren Controller oft in Go geschrieben sind, definierst du Lifecycle-Hooks und Workflows in Python, einer Sprache, mit der viele Plattformteams vertraut sind. Das ermöglicht schnellere Iterationen und einfachere Anpassungen.
  • Flexible Integration & Erweiterbarkeit:
    Custom Objects können Automatisierungen durch Ereignisse aus Git, REST-APIs oder anderen Systemen auslösen und fügen sich nahtlos in moderne GitOps- und ereignisgesteuerte Plattformarchitekturen ein.
  • Complexity-Creep vermeiden:
    Ohne Kubernetes gibt es weniger bewegliche Teile, die verwaltet, gewartet oder aktualisiert werden müssen. Besonders wichtig in regulierten oder On-Prem-Umgebungen, wo Kubernetes zusätzlichen Overhead verursachen kann.

Cloudomation bietet einen leistungsstarken, praxisnahen und zukunftssicheren Ansatz für Plattformautomatisierung, maßgeschneidert für die reale Komplexität und Vielfalt moderner IT-Landschaften.

Crossplane hat CRDs aus dem Cluster herausgeholt. Wir entfernen den Cluster komplett.

Crossplane erkannte das Potenzial von CRDs und erweiterte sie, um externe Infrastruktur direkt aus Kubernetes heraus zu verwalten. Damit bekamen Plattformteams die Möglichkeit, Self-Service-Infrastruktur über APIs bereitzustellen.

Cloudomation baut auf derselben Erkenntnis auf, entfernt jedoch die Abhängigkeit von Kubernetes vollständig. Unser Custom-Object-Modell:

  • Funktioniert mit Kubernetes, wenn du es willst
  • Funktioniert ohne Kubernetes, wenn du es nicht brauchst
  • Bietet dieselbe Abstraktionsschicht, nutzbar in On-Prem-, Hybrid- oder Multi-Cloud-Umgebungen
  • Unterstützt eine tiefe Integration mit Tools wie Git, Terraform, OpenStack, VMware und vielen anderen

Egal, ob du Kubernetes-Cluster, VMware-VMs oder Drittanbieter-SaaS-Tools verwaltest, du kannst deren Lebenszyklen auf konsistente Weise definieren und automatisieren.

Anwendungsfälle

  • Ein Team nutzt Custom Objects, um Development-Environments über AWS und OpenStack hinweg zu modellieren. Dieselben Lifecycle-Hooks stellen Ressourcen bereit, konfigurieren Zugriffe und entfernen sie wieder, unabhängig davon, wo sie laufen.
  • Ein anderes Team definiert Pipeline-Templates als Custom Objects, wodurch Devs neue Projekte in einem Git-basierten Katalog registrieren können. Cloudomation automatisiert dabei das Gerüst, die CI/CD-Integration und die Weiterleitung von Benachrichtigungen.
  • Service-Accounts werden als Custom Objects abgebildet. Die Automatisierung übernimmt deren Erstellung in Azure, das Rotationsmanagement und die Verteilung von Secrets.

API-Driven and Event-Driven

Custom objects in Cloudomation are first-class citizens in your automation landscape. They can be:

  • Queried and updated via REST API
  • Triggered via webhooks, e.g., on Git events
  • Managed via scripts, jobs, or long-running processes

They integrate easily into GitOps pipelines or event-based workflows — exactly as you would expect from a modern platform engineering tool.

API-gesteuert und ereignisgesteuert

Custom Objects in Cloudomation sind erstklassige Bausteine für deine Automatisierungslandschaft. Sie können:

  • Über die REST-API abgefragt und aktualisiert werden
  • Per Webhook ausgelöst werden, z. B. bei Git-Events
  • Über Skripte, Jobs oder langlaufende Prozesse verwaltet werden

Sie lassen sich mühelos in GitOps-Pipelines oder ereignisbasierte Workflows integrieren, genau so, wie man es von einem modernen Plattform-Engineering-Tool erwartet.

Fazit

Feature Kubernetes CRDs Crossplane Cloudomation Custom Objects
Infrastruktur-Abstraktion
Cloud-Ressourcenautomatisierung
❌ (Controllers benötigt)
Kubernetes benötigt
GitOps-kompatibel
Technologie-Agnostisch
❌ (Nur Kubernetes)
Python-basierte Logik

CRDs ohne Cluster

Custom Objects in Cloudomation bieten dir die Vorteile von CRDs, ganz ohne den Kubernetes-Overhead.

Wenn du eine interne Plattform aufbauen möchtest und flexible, deklarative sowie technologie-neutrale Ressourcenmodellierung suchst kannst du das mit Cloudomation tun. Ganz ohne Cluster.

Now that you're here...

Cloudomation Engine is a platform orchestrator that enables you to provide self-service tools, automate complex tasks, and gain full visibility into your infrastructure.

Let’s talk about how Cloudomation
can make that happen for you.