How CNStack 2.0 Enables Multi‑Cloud, Multi‑Cluster Management with OCM

As Kubernetes adoption grows, enterprises need to manage workloads across multiple clouds and clusters. CNStack 2.0 addresses this by providing a cloud‑native multi‑cluster service (cnstack-multicluster) that unifies management of clusters created on the CNStack platform, Alibaba Cloud, customer‑owned, or other clouds.

Core Capabilities

Extended OCM cluster registration (OCM [1]) for richer lifecycle operations.

Multiple resource distribution modes: Pull (OCM ManifestWork) and Push (Cluster‑Gateway).

Multi‑tenant, unified authentication and authorization.

High‑availability cross‑cluster access between hub and managed clusters.

Architecture Overview

The service consists of several components:

UI Backend : Exposes APIs for the UI.

OCM Hub/Agent : Implements basic cluster registration using OCM components.

registration‑operator, registration, work : Hub and agent side operators (see GitHub links [2]‑[4]).

Cluster‑Gateway : An aggregated API server routing traffic to multiple clusters (GitHub [5]).

managed‑serviceaccount : Syncs ServiceAccount tokens from managed clusters to the hub (GitHub [6]).

CNStack Agent : Collects vendor and component status from clusters.

Declarative Cluster Registration

CNStack adopts a declarative model: creating a ManagedCluster resource triggers registration. To overcome OCM’s limitation where the OCM Agent only reports a CABundle during creation, CNStack automates OCM Agent deployment and patches the CABundle issue [7], enabling true declarative registration.

Full Lifecycle Management

Beyond registration, CNStack extends the ManagedCluster API to cover creation and deletion. Users can declare desired clusters, and CNStack handles provisioning (using Alibaba’s open‑source cluster image technology [sealer] and ACK distro [ackdistro]), scaling, and teardown. The service supports offline environments, multiple OSes, built‑in networking/storage plugins, health checks, and resource isolation.

Extended Registration Success Conditions

CNStack adds custom readiness gates (inspired by Kubernetes Pod Readiness Gates [8]) to the ManagedCluster status, allowing business‑specific criteria for considering a cluster fully registered.

Enhanced Unregistration

Unregistration now cleans up OCM resources (ManifestWork, ManagedCluster{Addon}) and allows users to add custom finalizers to control the order of resource deletion, preventing orphaned resources and namespace leaks.

Registration Modes

Auto : Hub and managed clusters can directly communicate; fully automated.

Manual : Only the managed cluster can reach the hub; intended for air‑gapped or high‑security scenarios (not yet exposed to users).

Resource Distribution: Pull vs. Push

Pull mode uses OCM ManifestWork, distributing workload to agents on each managed cluster (see architecture diagram). Push mode leverages Cluster‑Gateway, eliminating the need for agents on managed clusters and simplifying operations.

Performance Optimizations

Integrating Cluster‑Gateway with OCM introduced latency due to frequent hub API server calls. Adding a cache layer (Inforemer [9]) reduced request latency by 95%, making performance comparable to direct kubeconfig access.

Multi‑Tenant Authentication & Authorization

Tenant, role, and RBAC resources are distributed via OCM ManifestWork. Users access clusters through the platform UI or kubeconfig, passing through a Management Gateway that performs unified authentication. Impersonation headers are added and later restored by Cluster‑Gateway’s ClientIdentityPenetration feature gate, ensuring correct identity propagation.

Cross‑Cluster Communication

Management Gateway handles control‑plane traffic, while Ingress Controllers handle data‑plane traffic. Headless Services provide stable routing across changing IPs/ports. All API requests to managed clusters flow through Management Gateway → Cluster‑Gateway → managed cluster API server, offering transparent routing, consistent permissions, and secure communication.

Future Outlook

CNStack aims to extend multi‑cluster capabilities to support cross‑cluster failover, multi‑cluster Services, disaster recovery, and proximity‑based access, along with security and compliance policy management.

References

OCM: https://open-cluster-management.io/

registration‑operator: https://github.com/open-cluster-management-io/registration-operator

registration: https://github.com/open-cluster-management-io/registration

work: https://github.com/open-cluster-management-io/work

cluster‑gateway: https://github.com/oam-dev/cluster-gateway

managed‑serviceaccount: https://github.com/open-cluster-management-io/managed-serviceaccount

OCM Agent CABundle fix: https://github.com/open-cluster-management-io/registration/pull/270

Pod Readiness Gates: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate

Inforemer cache PR: https://github.com/oam-dev/cluster-gateway/pull/117

Impersonation docs: https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation

Alibaba sealer: https://github.com/sealerio/sealer

ACK distro: https://github.com/AliyunContainerService/ackdistro