Open Cluster Management (OCM) becomes a CNCF Incubating Project
Originally developed by IBM and Red Hat, the open source project joined the CNCF Sandbox in November 2021 before progressing to the incubation tier.
By Dillip Chowdary • Nov 11, 2026 • Source: CNCF Blog
In this post
The Cloud Native Computing Foundation Technical Oversight Committee voted to accept Open Cluster Management as an incubating project, according to CNCF Blog's report. Originally developed by IBM and Red Hat, the open source project joined the CNCF Sandbox in November 2021 before progressing to the incubation tier. The platform simplifies Kubernetes fleet management across cloud, on-premises, and edge footprints using declarative APIs and an asynchronous hub-and-spoke model.
This breakdown examines Open Cluster Management's progression through CNCF governance, its modular architecture, and its real-world implementation across production multi-cluster fleets. The analysis is structured for platform engineers, site reliability teams, and infrastructure architects evaluating distributed Kubernetes management strategies. It outlines key release milestones, core components, and ongoing integrations across cloud-native GitOps and workload distribution ecosystems.
01Incubation status and development milestones
Open Cluster Management entered the CNCF Sandbox in November 2021 and delivered its 1.0 release in June 2025. Over the subsequent sixteen months, the community released four minor versions, advancing through version 1.4 in October 2026.
The technical portfolio includes 1,100 GitHub stars, 1,370 merged pull requests, and contributions from 537 individuals representing 84 organizations across 16 countries. Governance is steered by 27 maintainers from eight distinct entities, including Red Hat, Guidewire, eBay, AppsCode, and Spectro Cloud.
The version 1.0 release introduced Common Expression Language cluster selection alongside an Argo CD pull-model add-on. Version 1.1 added gRPC-based hub-and-spoke networking together with integrations for Kueue MultiKueue and OpenTelemetry.
Subsequent engineering in version 1.2 brought advanced placement configurations, automated hosting cluster resolution, and argocd-agent connectivity for scalable GitOps synchronization. Version 1.3 refined ManifestWork resource sequencing while graduating the AddOnTemplate API to v1beta1, and version 1.4 aligned PlacementDecisions with Kubernetes SIG Multicluster APIs while introducing security network policies.
Advancement to the incubation tier places Open Cluster Management under the operational governance of the Linux Foundation alongside systems like Backstage, Thanos, and Tekton. CNCF Technical Oversight Committee member Karena Angell stated that the advancement reflects technical maturity, a growing contributor community, and meaningful adoption across multicluster environments without reliance on proprietary solutions. The foundation provides vendor-neutral intellectual property stewardship, formal release oversight, and structured graduation criteria as the community expands.
02Hub and spoke control plane architecture
Open Cluster Management decouples fleet administration using a centralized Cluster Manager hub and edge-deployed Klusterlet agents running on individual managed clusters. Cluster registration relies on a double opt-in handshake secured via mutual TLS with automated certificate rotation.
Each registered managed cluster receives an isolated, dedicated namespace on the central hub. The clusteradm command-line utility provides operational commands to bootstrap new hubs and join external clusters into the control plane inventory.

Workload distribution operates through the ManifestWork API, which delivers raw Kubernetes resources to spokes with configurable conflict resolution, update cadences, and execution status feedback loops. The system uses an asynchronous pull architecture where local Klusterlet agents fetch tasks from the hub rather than accepting inbound commands.
This design prevents sensitive spoke credentials or kubeconfig tokens from ever residing on the centralized hub. Maintainer Mike Ng noted that the pull pattern preserves spoke cluster autonomy and ensures that control plane communication disruptions do not interrupt running container workloads.
Dynamic scheduling relies on the Placement API, which interrogates cluster labels, compute capacities, and operational metrics to compute cluster target assignments. The scheduler writes outcomes directly to standard PlacementDecision objects that third-party controllers can consume. A pluggable add-on framework provides standardized lifecycle management, registration, and telemetry collection, allowing external utilities to inherit distributed infrastructure routing without writing bespoke multicluster networking logic.
Advertisement
Tech Pulse Daily
Get tomorrow's pulse first
Join engineers who read Tech Pulse before stand-up. Free, weekday mornings.
03Ecosystem tooling and GitOps integration
The platform aligns its internal scheduling constructs with the upstream Kubernetes SIG Multicluster standards. In production GitOps pipelines, Open Cluster Management supplies downstream cluster decisions directly into Argo CD, while pairing with Cluster API to handle infrastructure provisioning and bare cluster lifecycle operations. Built-in extension libraries provide policy controllers focused on configuration governance, risk detection, and regulatory compliance across environments.
Cloud-native projects including KubeVela, KubeStellar, Kueue, and Meshery maintain formal documentation and integration pathways for Open Cluster Management APIs. The core repository distributes prebuilt add-ons and implementation references for Fluid data caching and OpenTelemetry trace aggregation. By using declarative Custom Resource Definitions, third-party operators can treat external clusters as standard Kubernetes resources, scheduling deployment manifests across diverse host networks without specialized infrastructure proxies.
The integration with argocd-agent enables pull-based GitOps rollouts that scale past the communication bottlenecks of centralized push architectures. By shifting manifest rendering and local status tracking to the spoke agent, the system maintains complete application visibility while reducing latency across remote clouds. Central administrators can monitor drift and reconcile configuration states across hundreds of target endpoints while retaining isolated cryptographic boundaries.
04Enterprise adoption across production fleets
Production rollouts span enterprise end-users and commercial software providers, including Alibaba Cloud, AppsCode, Guidewire, Red Hat, and Spectro Cloud. At eBay, engineering teams manage application delivery across more than 190 Kubernetes clusters using Open Cluster Management integrated with Argo CD. This deployment coordinates manifest distribution across heterogeneous production clusters while maintaining synchronized application state through GitOps repositories.
Financial technology firm Groww uses the platform to orchestrate progressive rollouts across internal Kubernetes environments, decoupling application release stages to reduce operational deployment risk. Artificial intelligence infrastructure platform VESSEL AI deploys Open Cluster Management to oversee distributed GPU server clusters, orchestrating computational resources and routing machine learning workloads across distinct cloud service provider boundaries.
These implementations demonstrate the platform's suitability for edge networks and multi-cloud footprints where spoke clusters experience intermittent network partitions. Because Klusterlet agents operate autonomously once manifests are pulled, managed workloads run unimpeded during hub downtime. Clusters can be registered, monitored, and decommissioned without interrupting active compute workloads, providing consistent administrative controls across geographically separated infrastructure.
05Roadmap priorities and rollout automation
Engineering maintainers are targeting simplified operational onboarding and expanded rollout safety controls as primary goals for upcoming releases. Project lead Mike Ng highlighted that future roadmaps focus on reducing setup friction for clusteradm while enhancing progressive workload delivery mechanisms across distributed environments. Maintainers aim to deliver native canary deployment pipelines and phased cluster group updates directly within the core placement engine.
The project continues expanding its interoperability with the Kubernetes SIG Multicluster PlacementDecision specification, establishing consistent behavioral semantics between upstream standards and production add-on controllers. Ongoing security hardening efforts include automated generation of restrictive network policies, tighter RBAC enforcement between hub namespaces, and improved observability pipelines for ManifestWork execution status.
The community is also refining support for compute-intensive workloads, building closer ties with scheduling tools like Kueue MultiKueue to manage shared AI infrastructure queues. As multi-cloud enterprise deployments expand into edge sites and specialized GPU environments, Open Cluster Management aims to maintain a modular footprint that avoids the overhead of monolithic multi-cluster management platforms.
Cluster Management (OCM) becomes a CNCF FAQ
What is Open Cluster Management?
Open Cluster Management is an open source project that simplifies the management of Kubernetes clusters across cloud, on-premises, and edge environments using a hub-and-spoke architecture and open APIs.
Which organizations maintain and use Open Cluster Management?
The project is led by 27 maintainers from eight organizations, including Red Hat, Guidewire, eBay, AppsCode, and Spectro Cloud, and is used in production by companies such as eBay, Groww, and VESSEL AI.
How does Open Cluster Management handle cluster credentials and security?
It uses an asynchronous pull model where Klusterlet agents pull work from the central hub, ensuring the hub never stores managed cluster credentials, while securing connections with mutual TLS and dedicated hub namespaces.
What did the project introduce between version 1.0 and version 1.4?
Key updates included CEL cluster selection, an Argo CD pull add-on, gRPC hub-and-spoke networking, argocd-agent integration, Kueue MultiKueue add-ons, ManifestWork resource ordering, and alignment with SIG Multicluster PlacementDecision APIs.
Sources
Author
Dillip Chowdary
Writes Tech Bytes coverage of AI, engineering, and the tools that actually ship. Editor of Tech Pulse Daily.
Related on Tech Bytes
Advertisement