Red Hat · Software · ficha YoctoIT

ACM

El gobierno multi-clúster: políticas, compliance y despliegues coherentes en todos los OpenShift — data center, cloud, edge.

FOCUS · MUCHOS CLÚSTERES, UNA DIRECCIÓNCuando los clústeres se multiplican hace falta un plano de control sobre los planos de control
Solicita el Free Assessment Descubre más
Material YoctoIT para clientes y partners · Red Hat, RHEL, OpenShift, Ansible y los demás productos citados son marcas de Red Hat, Inc. o di sue affiliate.
01 · Qué es

Advanced Cluster Management, en claro.

Un OpenShift pronto se convierte en tres (prod, test, DR), luego cinco con el edge y el cloud. ACM los gobierna desde un solo punto: creación y actualización de los clústeres, políticas de configuración y seguridad aplicadas en todas partes, despliegues GitOps multi-clúster y una vista única de salud y compliance.

Hub & spoke
un clúster hub gobierna todos los demás, estén donde estén
Policy
la configuración deseada declarada e impuesta en cada clúster
GitOps
ArgoCD integrado: la aplicación aterriza en N clústeres desde un repo
Advanced Cluster Management
IMAGEN OFICIAL RED HAT · ACM
ARCHITETTURA UFFICIALE · ACM MULTICLUSTER · FONTE: RED HAT DOCS
ARQUITECTURA OFICIAL · ACM MULTICLUSTER · FUENTE: RED HAT DOCS
02 · Cómo usarlo bien

Las cosas que marcan la diferencia.

La dirección multi-clúster

ACM hubinventario, políticas, observabilidad
Prod
DR
Edge & cloud
los spokes gobernados
Policy & placementqué corre dónde, declarado
Repo GitOpsla verdad versionada
Un punto de gobierno, N clústeres conformes

Cluster lifecycle

Crear, actualizar y retirar clústeres desde consola o desde código: la temporada de upgrades deja de ser una gira.

Políticas de compliance

CIS, certificados, configuraciones de seguridad: la desviación es visible y auto-remediada.

Placement inteligente

Las apps van a los clústeres correctos por label, capacidad, región: el placement es una regla, no un recuerdo.

DR multi-clúster

Con ODF y ACM el failover de aplicaciones entre sitios se orquesta, no se espera.

03 · En profundidad

Hub, políticas y GitOps de flota

ACM gobierna flotas de clústeres: el hub importa o crea los clústeres (también sobre cloud/bare metal vía Hive/ZTP), las Policies declaran el estado deseado (config, operators, seguridad) con enforcement o solo auditoría, los PlacementRules deciden dónde aterrizan las apps, la integración ArgoCD hace GitOps multi-clúster con ApplicationSet. Observability agrega métricas de flota; Submariner conecta las redes entre clústeres.

  • Policy framework — configuración y compliance declarativas: enforce o inform, por cluster set
  • ApplicationSet — un repo, N clústeres: el deploy que sigue las labels
  • Hive/ZTP — provisioning de los clústeres desde el hub: también edge zero-touch
  • Cluster set — grupos con RBAC: prod, dev, edge gobernados por separado
  • Observability — métricas y alertas de flota en un solo Grafana
  • Submariner — service discovery y túneles entre clústeres: la app multi-sitio habla nativo
04 · Números y ciclo de vida

Los números que cuentan.

1000+
los clústeres gestionables desde un hub (arquitectura a escala)
GitOps
ArgoCD integrado: la verdad en el repo
2
modos de policy: inform (auditoría) y enforce
EUS
alineado con OpenShift: los upgrades orquestados desde el hub
Muchos clústeres, una sola intención: políticas, placement y GitOps los escribimos una vez — la flota converge sola.
05 · Casos de uso

Dónde rinde de verdad.

Prod + DR + test

Tres clústeres alineados sin triplicar el trabajo.

Edge distribuido

Decenas de micro-clústeres en plantas, gobernados por uno.

Híbrido on-prem/cloud

Mismas políticas del data center a AWS/Azure.

Más clústeres no debe significar más caos: ACM es la dirección, nosotros la mantenemos encendida 24/7.