Kubernetes stellt für jede Umgebung dieselbe API bereit. Deshalb gehen Teams meist davon aus, dass ihre Workloads nahtlos übertragbar sind. In der Praxis migriert die Anwendung, während der darunterliegende Layer unverändert bestehen bleibt. Identity Federation, Storage Classes, Ingress-Implementierung und Secret Management: Genau hier wird das eigentliche Migrationsbudget gebunden, und selbst die saubersten Manifeste ändern daran nichts.
Genau für diese Herausforderung wurde unser Produkt entwickelt. mogenius betreibt Kubernetes-Fleets über Public-Cloud-, On-Premises- und Air-Gapped-Umgebungen hinweg auf einer zentralen Plattform, unterstützt durch einen Open-Source-Operator und Policies, die im eigenen Cluster des Kunden vorgehalten werden. So bleibt das Operations Model auch bei einem Infrastrukturwechsel konsistent. Operations ist unser Baustein im Stack.
Open Source ist für uns kein Neuland. Wir betreuen den Renovate Operator, ein MIT-lizenziertes Tool für automatisierte Dependency-Updates auf Kubernetes, das als Standalone-Lösung ohne mogenius-Account lauffähig ist.
Alles unterhalb dieser Ebene liegt in der Verantwortung anderer. Jeder Vendor in diesem Markt bedient seinen eigenen Layer, und die Schnittstellen zwischen diesen Layern funktionieren nur, wenn sich die beteiligten Unternehmen auf gemeinsame Standards verständigen.
Aus diesem Grund ist mogenius der NeoNephos Foundation beigetreten, einer Initiative der Linux Foundation Europe, die gemeinsam mit Unternehmen wie SAP, Deutsche Telekom, STACKIT, SUSE, BWI und dem Fraunhofer ISST eine interoperable Cloud- und Edge-Infrastruktur für Europa aufbaut. Wir bringen dabei die Operations-Perspektive ein: wie eine offene Infrastruktur für die Platform Teams aussehen muss, die sie täglich im Betrieb steuern.
Kubernetes sorgt für die Portabilität von Workload-Definitionen. Manifeste, Helm-Charts und RBAC-Regeln greifen clusterübergreifend, unabhängig vom zugrundeliegenden Provider. Die darunterliegenden Layer bleiben jedoch provider-spezifisch, was den eigentlichen Aufwand verursacht: Identity Federation, verfügbare Storage Classes, die Bereitstellung von Ingress und Load Balancern sowie das an ein Provider-KMS angebundene Secret Management.
Die Identity-Integration verursacht in der Regel den höchsten Aufwand, gefolgt von Storage Classes und allen Komponenten, die über ein Provider-SDK angesprochen werden. Als bewährte Faustregel gilt: Alles, was über eine Provider-Konsole konfiguriert und nicht im Cluster deklarativ definiert wurde, muss neu aufgebaut werden.
Policies sollten als Kubernetes-native Objekte im Cluster hinterlegt und über einen Operator durchgesetzt werden, der auf jedem konformen Cluster läuft. Kubernetes-Management-Plattformen wie mogenius, die Cluster-Fleets über Cloud-, On-Premises- und Air-Gapped-Umgebungen hinweg steuern, verwalten Guardrails als CRDs im kundeneigenen Cluster. Dadurch ist sichergestellt, dass die Regelanwendung gemeinsam mit dem Workload wandert.
Eine im März 2025 unter dem Dach der Linux Foundation Europe gegründete Stiftung. Sie hosted providerübergreifende Open-Source-Projekte für Cloud- und Edge-Infrastrukturen. Zu den Mitgliedern zählen unter anderem SAP, Deutsche Telekom, STACKIT, SUSE, BWI, Fraunhofer ISST und mogenius. Die Stiftung betreut Komponenten, anstatt eigene Cloud-Dienste zu betreiben.
Newsletter abonnieren und immer auf dem aktuellen Stand bleiben
