OpenShift Platform – Concept Overview

On this page

Summary
Applicable Principles
Architecture
Architecture Principles
Logical Architecture Overview
Phased Datacenter Strategy (Single-Active)
Key Integrations
Decisions
Future Enhancements
Related Material
Open Questions
Revision History

Summary

High-level view of the hybrid-cloud OpenShift platform across datacenters, covering cluster roles (management/application/virtualization/AI for DevOps acceleration), storage, networking, and developer services. Acts as the baseline for OpenShift design and references the phased rollout ADR.

Applicable Principles

Automation First — cluster lifecycle is governed via GitOps.
Self-Service Platform — OpenShift provides paved-road services.
Observability by Default — platform telemetry is mandatory.
Reliability and Resilience — OpenShift services meet availability targets.
Security by Design — cluster security baselines are enforced.

Architecture

Architecture Principles

Dedicated cluster roles: Separate management, application, virtualization, and AI workloads.
Central governance: Advanced Cluster Management (ACM) is the accepted production governance plane, with a single-hub model using one Red Hat Advanced Cluster Management installation on that hub cluster (see ADR-010); the transitional Location A OpenShift AI lane is explicitly excluded from ACM lifecycle deployment.
Externalized state: Persistent data and backups live outside clusters (Ceph, Cohesity).
Policy enforcement: policy-as-code admission control (OPA Gatekeeper) and container security (ACS), plus subnet isolation.
Declarative operations: CI/CD and Automation for consistent configuration.
Phased delivery: Single-active rollout with planned cutover (see adr-004-single-active-phased-rollout).

Logical Architecture Overview

Download draw.io source

Cluster Types

Cluster	Purpose
ACM cluster (red-hat-advanced-cluster-management)	Production governance plane for ACM control and fleet policy management.
Datacenter Services (clusters-as-a-service)	Shared-services target-state cluster role (see adr-005-datacenter-services-baseline); active in Location B during transitional rollout and imported into ACM (red-hat-advanced-cluster-management).
General-Purpose Virtualization	VM hosting via openshift-virtualization (OpenShift Virtualization); target scope and constraints are defined in openshift-virtualization-architecture.
Hosted control planes (HCP)	Hosted control planes use a `HostedCluster` control plane with `NodePool` workers; support is provider/version dependent (validate target platform).
OpenShift AI (red-hat-openshift-ai)	Implements data-science-and-ai (AI Workload Platform, ABB). GPU-backed cluster for coding-agent inference and evaluation; in Location A transitional production it runs as a standalone bootstrap-managed lane with tightly bounded scope.
Developer Hub	HCP cluster for developer services.
Serverless	HCP cluster for Knative serverless workloads.
Service Mesh control plane	Platform-managed control plane for service-mesh (implemented via openshift-service-mesh).

Shared Infrastructure

Storage: Dedicated Ceph platform via ODF external mode for RBD/CephFS.
Networking: Segregated subnets per cluster on the EVPN/VXLAN datacenter fabric; backbone connectivity uses L3 interconnect to L3VPN VRFs (service) over SR-MPLS transport. Production target profile uses CUDN-first routed attachment for participating workloads, with UDN reserved for scoped isolation and overlap cases under release-pinned supportability gates; application exposure continues through supported Service, ingress, and load-balancer patterns.
Registry: Tiered Red Hat Quay uses a main ACM-governed seed tier for approved platform content, DCS-internal platform Quay instances in AM1 and AM4 for cluster lifecycle pulls, and separated tenant-facing Quay endpoints for tenant image push/pull.
Observability: Central logging and metrics via ACM observability.
Backup / DR: Backup and Disaster Recovery using Cohesity with Ceph replication controls aligned to accepted DR gates.

Phased Datacenter Strategy (Single-Active)

Single-active across two locations; rollout and naming are defined in adr-004-single-active-phased-rollout.

Definitions

Single-active: One location hosts production workloads and control planes while the second location is built, validated, and used for non-production until cutover.
Static intent baseline: Stable network and platform configuration prioritizing determinism over continuous change.
Dynamic target platform: Automation-rich environment built in the second location to reach parity before cutover.
Clusters as a Service cluster: Shared services cluster role defined in adr-005-datacenter-services-baseline; activated in Location B for the transitional phase and imported into ACM.

Rollout Baseline (Summary)

Location A (baseline): Hosts the static intent baseline and initial production continuity workloads with minimal network changes; the single ACI pod is scoped to the restricted-network OpenShift AI cluster only.

Location B (target): Builds the dynamic platform, supports non-production validation, and validates readiness gates before cutover, including EVPN/VXLAN multi-tenant networking, platform services automation, the first DCS-internal Red Hat Quay platform tier, and the separated tenant-facing registry endpoint.
Cutover: Switches primary operations to Location B, keeping Location A as a fallback.

See adr-004-single-active-phased-rollout, adr-005-datacenter-services-baseline, and topic-datacenter-rollout-intent for the reasoning and supporting intent.

Cutover controls are executed through ADR-governed release evidence and workpackage validation scope (wp-01-dc3-0-network-and-supporting-services, wp-08-platform-services-automation, wp-16-business-continuity-and-disaster-recovery), with Location A lane boundaries enforced via topic-network-aci-location-a-ai-fasttrack and openshift-ai-cluster-setup.

Key Integrations

Integration	Description
Ceph (ceph) (storage)	Core persistence layer for all clusters.
Cohesity (cohesity)	Implements backup-and-disaster-recovery (Backup and Recovery, ABB).
Location A transitional network lane (dc-network-structure)	Single ACI pod, scoped strictly to the AI cluster use case.
Location B target network lane (dc-network-structure)	Implemented with cisco-nexus-9000 running cisco-nx-os. EVPN control-plane + VXLAN data-plane, with L3 VRF interconnect to backbone L3VPN services.
Identity Provider (federated-authentication)	Implemented with Keycloak (keycloak) for centralized authentication across clusters.

Decisions

adr-001-storage-backend (accepted) – Dedicated Ceph platform (ODF external mode) as backend storage.
adr-004-single-active-phased-rollout (accepted) – Single-active rollout and Datacenter Services cluster model.
adr-019-hybrid-network-rollout-aci-a-ai-only-evpn-b-target (accepted) – Hybrid network lane model for Location A and Location B.
adr-020-backbone-service-vs-transport-l3vpn-sr-mpls (draft) – Backbone service versus transport model.
adr-021-dc-evpn-to-backbone-l3vpn-interconnect (draft) – DC EVPN to backbone L3VPN interconnect pattern.
adr-005-datacenter-services-baseline (accepted) – Datacenter Services baseline and NetScaler BLX approach.
adr-022-openshift-ai-dc-a-transitional-production-exception (draft) – Transitional production exception guardrails for the DC-A OpenShift AI lane.

Future Enhancements

Evaluate Ceph mirroring for DR.
Extend ACM policies for tenant audit.
Add unified observability dashboards.
Pilot Hosted Control Planes for containers as a service.

Open Questions

Revision History

Version	Date	Author	Notes
0.1	2025-11-01	Wouter Moeken	Consolidated initial concept + Red Hat HLD content