Neu in der CNCF-Landschaft

Kubernetes-Virtualisierungs-API und -Laufzeit, mit der sich virtuelle Maschinen neben Containern als Kubernetes-Ressourcen definieren und betreiben lassen. Laut landscape.yml seit 06.09.2019 im Sandbox-Bereich aufgenommen und seit 19.04.2022 Incubating. Das Graduation-Issue cncf/toc#1822 ist geschlossen, die Abstimmung (gitvote) bestanden. Für Betreiber, die VM-Workloads und Container auf einer Plattform führen wollen, hat die Virtualisierungsschicht damit denselben Reifegrad wie der Cluster darunter.

Messaging-System, das Nachrichtenaustausch, Streaming und Zustand in einem Echtzeit-System bündelt, von der Cloud bis zum Edge. Laut landscape.yml seit 15.03.2018 aufgenommen und Incubating, seit 02.11.2026 graduiert. Das Graduation-Issue cncf/toc#2042 ist geschlossen, die Abstimmung (gitvote) bestanden. Wer NATS als Messaging-Rückgrat einsetzt, bekommt damit den höchsten CNCF-Reifegrad als Argument in der Plattformbewertung.

Karmada verteilt Kubernetes-Ressourcen unverändert über mehrere Cluster und Clouds: PropagationPolicy legt die Zielcluster fest, OverridePolicy die clusterspezifischen Abweichungen, etwa Image-Präfix je Region oder StorageClass je Cloud. Laut Graduation-Due-Diligence verteilen sich die 8 Maintainer auf 6 Organisationen, eine dokumentierte Regel begrenzt jede Organisation auf höchstens 50 % der Maintainer-Sitze. Das Third-Party-Audit (Shielder im Auftrag von OSTIF, gegen v1.11.0) ist abgeschlossen, alle High- und Medium-Findings sind seit v1.12.0 behoben. Releases kommen im Drei-Monats-Takt, unterstützt werden die drei jüngsten Minor-Versionen, aktuell v1.19.0 vom 31.08.2026. Laut README setzt Karmada die Linie von Kubernetes Federation v1 und v2 (KubeFed) fort.

Werkzeugkasten für ML- und AI-Plattformen auf Kubernetes: Pipelines, Trainer (vormals Training Operator), Notebooks, Katib. Für Betreiber heißt Graduation, dass die AI-Plattform-Schicht denselben Governance- und Wartungsstand erreicht hat wie der Cluster darunter. Das Serving-Stück ist als KServe seit 29.09.2025 ein eigenes Incubating-Projekt.

Cloud Native Buildpacks bauen OCI-Images direkt aus Quellcode, ohne Dockerfile, und tauschen das Basis-Image per Rebase, ohne die Anwendung neu zu bauen. Genau dieser Rebase-Pfad macht CVE-Patching an der Basisschicht zur Minutenaufgabe statt zum Rebuild aller Services.

Spezifikation, SDKs und Collector für Traces, Metriken und Logs, mit OTLP als herstellerneutralem Transportformat. Graduation nimmt das letzte Argument gegen OTLP als Pflichtformat in der Instrumentierungs-Policy und macht den Collector zum belastbaren Umschlagpunkt vor dem Backend.

Policy Engine, die Regeln als Kubernetes-Ressourcen in YAML ausdrückt, mit JMESPath-Ausdrücken in der klassischen ClusterPolicy und CEL in den policies.kyverno.io-Typen, ohne separate Sprache wie Rego. Sie validiert, mutiert und generiert Ressourcen. In regulierten Umgebungen ist der Admission-Pfad damit im selben YAML- und GitOps-Workflow auditierbar wie die Workloads.

Offener Standard für Multi-Cluster-Management von Kubernetes mit Hub-Spoke-Architektur. Laut landscape.yml seit 09.11.2021 im Sandbox. Damit steht neben Karmada ein zweites Multi-Cluster-Projekt auf einem höheren Reifegrad als Sandbox, mit anderem Ansatz: Hub und Spokes statt Verteilung per Policy.

Kubernetes-Operator für PostgreSQL, laut landscape.yml seit 21.01.2025 im Sandbox. Der Reifegrad-Sprung zählt für alle, die Datenbanken im Cluster über einen Operator statt über einen verwalteten Dienst betreiben.

Plattform für Design und Betrieb von Kubernetes-Infrastruktur, gestartet als Service-Mesh-Manager, mit visueller Oberfläche und modellbasierter Erweiterung über mehr als 380 Integrationen, seit 22.06.2021 im Sandbox. Die Incubation-Due-Diligence prüft als Kern meshery, meshery-operator, meshsync, meshkit, schemas und die Mesh-Adapter. Extensions in der Org meshery-extensions folgen einer eigenen Governance und tragen ein Support-Tier (Official oder Community), Kanvas gehört nicht mehr zum Kern. Wer Meshery mit Extensions einsetzt, bewertet deren Reifegrad also getrennt.

Globales Load Balancing über mehrere Kubernetes-Cluster per DNS, ohne zentrale Control Plane und ohne proprietären GSLB-Appliance-Stack. Der Failover-Pfad zwischen Regionen bleibt damit deklarativ im Cluster beschrieben.

Führt Pods in Trusted Execution Environments aus und belegt den Zustand per Remote Attestation. Der Anwendungsfall ist Isolation gegen den Infrastrukturbetreiber selbst, also genau die Anforderung, die sonst gegen geteilte Plattformen spricht.

Virtualisierungsschicht für heterogene Beschleuniger, teilt GPUs zwischen Pods auf und setzt Speicher- und Rechenkontingente durch. Damit lässt sich GPU-Kapazität quotieren, statt ganze Karten exklusiv zu vergeben.

Macht aus vorhandenen API-Artefakten (OpenAPI, AsyncAPI, gRPC/Protobuf, GraphQL-Schema, Postman-Collections, SoapUI-Projekte) laufende Mocks und nutzt dieselben Artefakte für Contract-Conformance- und Non-Regression-Tests gegen die Implementierung, angebunden über CLI an Jenkins, GitHub Actions oder Tekton. Seit 22.06.2023 im Sandbox. Damit wird der API-Vertrag selbst zum Testfall in der Pipeline, statt handgepflegter Stubs.

CI/CD-Framework, das Tasks und Pipelines als Kubernetes-CRDs beschreibt und Builds im Cluster ausführt. Tekton wurde nicht über Sandbox eingefädelt, sondern am selben Tag aufgenommen und auf Incubating gesetzt.

Datenorchestrierung und Caching für datenintensive Workloads, abstrahiert entfernten Objektspeicher als lokal gecachten Datensatz. Verkürzt bei Training und Batch-Inference die Wartezeit auf Daten, die sonst je Job neu über das Netz gezogen werden.

Proxy-Server und Framework für cloud- und KI-native Workloads. Das Repository liegt unter praxis-proxy/praxis. Wer Proxy und Gateway auswählt, findet neben Envoy und kgateway damit einen weiteren Sandbox-Kandidaten, ohne dass das Level etwas über Reife im Betrieb sagt.

Kubernetes-native Orchestrierung für Flotten von KI-Coding-Agenten, die Software-Repositories selbstständig pflegen. Das Repository liegt unter hivecommons/hive.

Policy-gesteuerte, abgeschottete Laufzeitumgebungen für autonome KI-Agenten. Das Repository liegt unter NVIDIA/OpenShell, die Dokumentation bei NVIDIA.

Ausführungsumgebung für KI-Agenten, die Sandboxes standardmäßig absichert und auf Millionen paralleler Sandboxes ausgelegt ist. In landscape.yml steht für das Projekt noch kein Aufnahmedatum.

Backup und Restore von Kubernetes-Ressourcen und Persistent Volumes, in der Public Cloud oder on-premises, auch für Migration und Replikation zwischen Clustern (vormals Heptio Ark, bisher unter vmware-tanzu). Das Repository liegt jetzt unter velero-io/velero, GitHub leitet die alte URL derzeit weiter. Für den Backup- und DR-Pfad steht damit ein herstellerneutral verwaltetes Projekt in der CNCF.

Kubernetes-natives Framework für verteilte LLM-Inference auf Basis von vLLM und der Gateway API Inference Extension: prefix-cache-bewusstes Routing, Prefill/Decode-Disaggregation, gestaffeltes KV-Cache-Offloading auf CPU oder Disk. Gegründet von Red Hat, Google Cloud, IBM Research, CoreWeave und NVIDIA. Am 20.10.2026 erschien v1.0.0, die Konfigurations-API des Routers steht damit auf v1.

Das Sandbox-Projekt für eine standardisierte Workflow-DSL steht seit 22.08.2026 unter neuem Namen im Landscape. Das Spezifikations-Repository zog von serverlessworkflow/specification nach open-workflow-specification/specification, Homepage und LFX-Slug wechselten mit, GitHub leitet die alte Repo-URL derzeit weiter. Die SDKs liegen laut README weiterhin unter serverlessworkflow/. Wer die Spezifikation per Repo-URL pinnt oder in SBOMs referenziert, zieht die Quelle nach. Der Reifegrad bleibt Sandbox.

In-Memory-Datenmanager für Zwischenergebnisse in Analytics-Pipelines, seit 2021 im Sandbox. Wer das Projekt in einer Datenpipeline stehen hat, plant jetzt den Ersatz: Sicherheits-Fixes kommen aus der CNCF nicht mehr.

Orchestrierung von IAM-Policies über verschiedene Zielsysteme hinweg, seit 2022 im Sandbox. Wer Hexa für die IAM-Policy-Verteilung nutzt, plant den Ersatz: Sicherheits-Fixes kommen aus der CNCF nicht mehr.