Ramatech Innovation

Insights · OpenShift

OpenShift Multi-Cluster Management for Distributed Fleets

Overview

OpenShift multi cluster management becomes unavoidable when a single kube-apiserver is no longer a viable blast-radius boundary — geographic distribution, regulatory data residency, team autonomy, or DR requirements push platform leaders toward fleets of clusters unified by policy, Git, and observability rather than one giant control plane.

Red Hat Advanced Cluster Management (ACM) provides a hub cluster that registers spoke OCP and Kubernetes clusters, enforces policies, and visualizes health. Alternatively, GitOps-centric organizations manage spokes purely through Argo CD ApplicationSets without ACM — each model has trade-offs in compliance enforcement, UI visibility, and operational headcount.

This article maps hub-spoke architecture, cluster lifecycle (create, upgrade, retire), policy propagation with Kyverno or ACM ConfigurationPolicy, and the GitOps patterns that keep fifty clusters from drifting into fifty snowflakes.

Hub-Spoke Architecture and Fleet Topology

The hub cluster hosts management tooling — ACM controllers, Argo CD, observability aggregators — and should itself be hardened, backed up, and treated as tier-zero infrastructure. Spoke clusters run application workloads and minimal management agents. Avoid running customer traffic on the hub; its compromise affects the entire fleet.

Name clusters consistently: region-environment-purpose (e.g., ap-south-1-prod-payments). Label clusters in ACM or Argo secrets with environment, compliance tier, and upgrade wave. Upgrade waves stagger CVO bumps — non-prod week one, prod region A week two — limiting simultaneous failure domains.

Network connectivity between hub and spokes requires stable API reachability and often firewall rules allowing klusterlet or Argo CD agents to poll or push. Disconnected spokes need dedicated Git mirrors and container registries; do not assume every cluster reaches github.com.

Hub cluster failure domains should differ from spoke regions — hosting the management hub in the same AZ as your largest prod spoke defeats DR purpose. Treat hub backup and etcd with tier-zero RPO matching your most critical spoke.

ACM Cluster Lifecycle and Governance

ACM ClusterInstance or imported clusters join via bootstrap kubeconfig or hive provisioning on supported clouds. Hive automates cluster creation from ClusterDeployment CRs — useful for repeatable ROSA-like patterns on self-managed infrastructure. Document who owns cluster deletion — orphaned cloud resources are a finance problem months later.

Governance policies propagate PlacementBindings targeting ManagedClusterSets — dev, staging, prod. ConfigurationPolicy enforces must-have operators, namespace labels, or LimitRanges; CertificatePolicy validates TLS cert expiry. Non-compliance surfaces in ACM console and metrics; integrate with Alertmanager for paging when prod clusters violate encryption requirements.

Observability add-on forwards metrics and logs from spokes to hub or corporate backends. Tune cardinality — labeling every pod across fifty clusters into one Prometheus needs Thanos or hierarchical federation to remain queryable.

ACM klusterlet version skew during hub upgrades can temporarily disconnect spokes from policy enforcement — schedule hub upgrades outside spoke change freezes and verify ManagedCluster Available condition after hub bumps.

GitOps Fleet Repositories and OpenShift Multi Cluster Management

Structure Git repos for fleet scale: platform-infra (cluster-scoped), shared-services (logging, monitoring agents), and tenant-apps separated. ApplicationSet cluster generators read cluster-secret labels and deploy baseline manifests to every spoke matching selector.

Promotion uses branch or overlay progression — main syncs to all dev spokes; release-X branch syncs to staging; tagged releases sync to prod with manual approval on Argo Applications. Drift detection at fleet scale requires automated reports — daily cron listing OutOfSync production apps.

Secrets per cluster live in vault paths referenced by External Secrets Operator; never duplicate kubeconfigs in Git. Rotate hub-stored credentials on the same schedule as human access reviews.

Fleet Git repos benefit from monorepo vs polyrepo decisions documented upfront — monorepos simplify ApplicationSet generators; polyrepos isolate blast radius when one team breaks main. OpenShift multi cluster management governance includes repo structure, not only cluster labels.

Policy, Identity, and Consistent RBAC Across Clusters

Identity federation should be identical across spokes — same OAuth issuer, same group IDs — so RBAC templates work everywhere. Central IdP changes propagate to all clusters; test group mapping changes in dev spokes before prod lockout incidents.

Kyverno ClusterPolicies replicated via GitOps or ACM policy channels enforce standards: require resource requests, ban privileged pods, label namespaces for cost allocation. Exceptions use policy exceptions with expiry dates audited monthly.

Service mesh multi-cluster (ISTio east-west gateways) is advanced; most enterprises first solve config consistency before cross-cluster service discovery. Document which applications truly need cross-cluster traffic vs centralized ingress in one region.

Certificate trust bundles must be consistent across spokes when mTLS spans clusters — automate cert-manager ClusterIssuer deployment via GitOps to avoid thumbprint mismatches during failover.

Day-2 Fleet Operations and Cost of Complexity

OpenShift multi cluster management adds coordination overhead — more kubeconfigs, more upgrade windows, more certificates. Automate cluster onboarding checklists: monitoring enrolled, logging forwarded, backup configured, GitOps root app synced. Manual onboarding forgets steps.

Right-size hub infrastructure and staff platform SREs for fleet ratio targets — e.g., one FTE per fifteen production spokes at steady state, higher during migration waves. Tooling without headcount becomes shelfware.

When fleet count is small (two to three clusters), heavyweight ACM may be overkill — paired Argo CD instances and shared Git repos suffice. Scale tooling with cluster count; our OpenShift GitOps article covers the single-cluster foundation this model extends.

Fleet-wide change windows require executive air cover — one holdout team blocking policy deployment across clusters undermines OpenShift multi cluster management programs. Align incentives via mandatory platform standards with exception paths, not exception culture.

Cluster lifecycle retirement matters — decommission spokes via documented teardown that deletes cloud resources, revokes credentials, and archives Git config. Zombie clusters continue billing silently.

Edge, Disconnected, and Constrained Spokes

Edge OpenShift deployments (Single Node OpenShift, compact clusters) trade HA for footprint — ACM still manages them if klusterlet can reach hub intermittently.

Disconnected spokes sync Git and images from local mirrors — hub policies must not assume continuous internet on spokes. Policy bundles ship via USB or regional mirror in some regulated sites.

Latency-tolerant GitOps with longer sync intervals suits satellite links — tune Argo timeout and retry settings so flaky links do not mark Applications failed permanently.

Standardize cluster labels across ACM and Argo — environment, region, cost-center, compliance-tier — so generators and policies select consistently.

Coordinated Fleet Upgrades and OpenShift Multi Cluster Management

Upgrade waves propagate via Git bump to ClusterVersion desired version per cluster folder — never ssh to fifty clusters manually.

Canary cluster per wave validates operators and workloads before prod wave — one bad edge in graph blocks entire fleet if you skip canary.

ACM visualizes version skew — remediate stragglers before they become security exceptions with open CVE exposure.

OpenShift multi cluster management without coordinated upgrades is fifty independent snowflakes — coordination is the product ACM and GitOps sell.

Explore further

Related technology

Related reading

Need help with OpenShift?

Talk to engineers who implement these patterns in production—not generic advisory decks.

Book a consultationOpenShift services