Red Hat · Software · scheda YoctoIT

ACM

Il governo multi-cluster: policy, compliance e deployment coerenti su tutti gli OpenShift — data center, cloud, edge.

FOCUS · MOLTI CLUSTER, UNA REGIAQuando i cluster si moltiplicano serve un piano di controllo sopra i piani di controllo
Richiedi il Free Assessment Scopri di più
Materiale YoctoIT per clienti e partner · Red Hat, RHEL, OpenShift, Ansible e gli altri prodotti citati sono marchi di Red Hat, Inc. o di sue affiliate.
01 · Cos'è

Advanced Cluster Management, in chiaro.

Un OpenShift diventa presto tre (prod, test, DR), poi cinque con l'edge e il cloud. ACM li governa da un punto solo: creazione e aggiornamento dei cluster, policy di configurazione e sicurezza applicate ovunque, deployment GitOps multi-cluster e una vista unica di salute e compliance.

Hub & spoke
un cluster hub governa tutti gli altri, ovunque siano
Policy
la configurazione desiderata dichiarata e imposta su ogni cluster
GitOps
ArgoCD integrato: l'applicazione atterra su N cluster da un repo
Advanced Cluster Management
VESTE UFFICIALE RED HAT · ACM
ARCHITETTURA UFFICIALE · ACM MULTICLUSTER · FONTE: RED HAT DOCS
ARCHITETTURA UFFICIALE · ACM MULTICLUSTER · FONTE: RED HAT DOCS
02 · Come lo si usa bene

Le cose che fanno la differenza.

La regia multi-cluster

ACM hubinventario, policy, osservabilità
Prod
DR
Edge & cloud
gli spoke governati
Policy & placementcosa gira dove, dichiarato
GitOps repola verità versionata
Un punto di governo, N cluster conformi

Cluster lifecycle

Creare, aggiornare e dismettere cluster da console o da codice: l'upgrade season smette di essere un tour.

Policy di compliance

CIS, certificati, configurazioni di sicurezza: lo scarto è visibile e auto-remediato.

Placement intelligente

Le app vanno sui cluster giusti per label, capacità, regione: il placement è una regola, non un ricordo.

DR multi-cluster

Con ODF e ACM il failover applicativo tra siti si orchestra, non si spera.

03 · In profondità

Hub, policy e GitOps di flotta

ACM governa flotte di cluster: l'hub importa o crea i cluster (anche su cloud/bare metal via Hive/ZTP), le Policy dichiarano lo stato voluto (config, operator, sicurezza) con enforcement o solo audit, i PlacementRule decidono dove le app atterrano, l'integrazione ArgoCD fa GitOps multi-cluster con ApplicationSet. Observability aggrega metriche di flotta; il Submariner collega le reti tra cluster.

  • Policy framework — configurazione e compliance dichiarative: enforce o inform, per cluster set
  • ApplicationSet — un repo, N cluster: il deploy che segue le label
  • Hive/ZTP — provisioning dei cluster da hub: anche edge zero-touch
  • Cluster set — gruppi con RBAC: prod, dev, edge governati separati
  • Observability — metriche e alert di flotta in un solo Grafana
  • Submariner — service discovery e tunnel tra cluster: l'app multi-sito parla nativo
04 · Numeri e ciclo di vita

I numeri che contano.

1000+
i cluster gestibili da un hub (architettura a scala)
GitOps
ArgoCD integrato: la verità nel repo
2
modalità policy: inform (audit) ed enforce
EUS
allineato a OpenShift: gli upgrade orchestrati dall'hub
Molti cluster, un solo intento: policy, placement e GitOps li scriviamo una volta — la flotta converge da sola.
05 · Use case

Dove rende davvero.

Prod + DR + test

Tre cluster allineati senza triplicare il lavoro.

Edge distribuito

Decine di micro-cluster in stabilimenti, governati da uno.

Ibrido on-prem/cloud

Stesse policy dal data center ad AWS/Azure.

Più cluster non deve voler dire più caos: ACM è la regia, noi la teniamo accesa H24.