Red Hat · Software · YoctoIT tech page

ACM

Multi-cluster governance: consistent policies, compliance and deployments across all your OpenShift clusters — data center, cloud, edge.

FOCUS · MANY CLUSTERS, ONE DIRECTIONWhen clusters multiply you need a control plane above the control planes
Request the Free Assessment Learn more
YoctoIT material for clients and partners · Red Hat, RHEL, OpenShift, Ansible and the other products mentioned are trademarks of Red Hat, Inc. or its affiliates.
01 · What it is

Advanced Cluster Management, made clear.

One OpenShift soon becomes three (prod, test, DR), then five with edge and cloud. ACM governs them from a single point: cluster creation and updates, configuration and security policies applied everywhere, multi-cluster GitOps deployments and a single view of health and compliance.

Hub & spoke
one hub cluster governs all the others, wherever they are
Policy
the desired configuration declared and enforced on every cluster
GitOps
integrated ArgoCD: the application lands on N clusters from one repo
Advanced Cluster Management
OFFICIAL RED HAT BRANDING · ACM
ARCHITETTURA UFFICIALE · ACM MULTICLUSTER · FONTE: RED HAT DOCS
OFFICIAL ARCHITECTURE · ACM MULTICLUSTER · SOURCE: RED HAT DOCS
02 · How to use it well

The things that make the difference.

The multi-cluster direction

ACM hubinventory, policies, observability
Prod
DR
Edge & cloud
the governed spokes
Policy & placementwhat runs where, declared
GitOps repothe versioned truth
One point of governance, N compliant clusters

Cluster lifecycle

Creating, updating and retiring clusters from console or code: upgrade season stops being a tour.

Compliance policies

CIS, certificates, security configurations: drift is visible and auto-remediated.

Smart placement

Apps go to the right clusters by label, capacity, region: placement is a rule, not a memory.

Multi-cluster DR

With ODF and ACM, application failover between sites is orchestrated, not hoped for.

03 · In depth

Hub, policies and fleet GitOps

ACM governs fleets of clusters: the hub imports or creates clusters (on cloud/bare metal too via Hive/ZTP), Policies declare the desired state (config, operators, security) with enforcement or audit only, PlacementRules decide where apps land, the ArgoCD integration does multi-cluster GitOps with ApplicationSet. Observability aggregates fleet metrics; Submariner connects networks across clusters.

  • Policy framework — declarative configuration and compliance: enforce or inform, per cluster set
  • ApplicationSet — one repo, N clusters: the deploy that follows the labels
  • Hive/ZTP — cluster provisioning from the hub: zero-touch edge too
  • Cluster set — groups with RBAC: prod, dev, edge governed separately
  • Observability — fleet metrics and alerts in a single Grafana
  • Submariner — service discovery and tunnels across clusters: the multi-site app speaks natively
04 · Numbers and lifecycle

The numbers that matter.

1000+
the clusters manageable from one hub (architecture at scale)
GitOps
integrated ArgoCD: the truth in the repo
2
policy modes: inform (audit) and enforce
EUS
aligned with OpenShift: upgrades orchestrated from the hub
Many clusters, one intent: policies, placement and GitOps written once — the fleet converges on its own.
05 · Use cases

Where it really pays off.

Prod + DR + test

Three clusters aligned without tripling the work.

Distributed edge

Dozens of micro-clusters in plants, governed by one.

On-prem/cloud hybrid

Same policies from the data center to AWS/Azure.

More clusters must not mean more chaos: ACM is the direction, we keep it on 24/7.