What Is OpenShift? Architecture, Features, and Monitoring

Kubernetes gives your team a scheduler and an application programming interface (API) that run on almost any infrastructure, and Red Hat OpenShift builds a complete application platform around that core. It ships the routing, security policy, continuous integration and continuous delivery (CI/CD), and upgrade automation that your platform team would otherwise select, wire together, and patch on its own.

This guide covers what OpenShift adds to upstream Kubernetes through its architecture and Operators, which deployment model fits your environment, and which signals you need to watch once clusters reach production.

What Is OpenShift?

OpenShift Container Platform (OCP) is Red Hat’s cloud-based Kubernetes platform for building, deploying, and managing enterprise container workloads, and it’s built on Red Hat Enterprise Linux (RHEL) and Kubernetes. The current OCP 4.22 release runs Kubernetes 1.35 with the CRI-O container runtime. Identical cluster software installs on bare metal, VMware vSphere, Red Hat OpenStack Platform, and the major public clouds, which lets you run one hybrid cloud container platform across all of them. Its API stays Kubernetes-compatible, so standard manifests and kubectl tooling work against it, subject to the security defaults covered in the next section.

Upstream Kubernetes gives you container orchestration without the surrounding tooling, and OpenShift fills that space with integrated components. It ships Tekton-based OpenShift Pipelines for CI/CD, an Argo CD-based GitOps Operator, a web console, a built-in image registry, and the oc command-line interface (CLI), which stays compatible with kubectl. Role-based access control (RBAC) and Security Context Constraints (SCCs) enforce pod security by default, and Operators push updates to the host operating system, the cluster, and application services. On vanilla Kubernetes, most of those pieces are separate projects your team has to select, install, and keep patched.

How OpenShift Differs from Plain Kubernetes

The differences surface the first time you expose a service or deploy a third-party image. On upstream Kubernetes, an Ingress resource has no effect until you install and run an Ingress controller yourself. OpenShift’s Ingress Operator runs by default and gives every new install an HAProxy-based ingresscontroller named default, which the Operator recreates if someone deletes it. Applications use the OpenShift-native Route object, which generates a hostname when you leave host unset, and OpenShift also creates managed Routes automatically from any Ingress you apply. The table below compares OpenShift with upstream Kubernetes across four areas.

Area	Upstream Kubernetes	OpenShift
External traffic	An Ingress controller you choose and install	A default HAProxy router serves Route and Ingress objects
Pod security	RBAC plus Pod Security Admission (PSA) profiles	RBAC plus SCCs, with restricted-v2 granted to every authenticated user
Add-on lifecycle	Manual manifests or Helm charts	Operator Lifecycle Manager (OLM) installs, upgrades, and resolves dependencies
Registry and console	Bring your own	Built-in image registry and web console

Third-party Helm charts usually run into restricted-v2 first. Each project receives a user ID (UID) range through the openshift.io/sa.scc.uid-range annotation, pods run as an arbitrary UID from that range, and the SCC drops all Linux capabilities. A chart that hardcodes root fails admission with a runAsUser error that lists the project’s allowed UID range, and the fix is to drop the hardcoded UID or bind a custom SCC to the chart’s service account. Coralogix, a cross-stack observability platform, takes the second route in its OpenTelemetry Helm chart, where setting distribution: "openshift" creates a dedicated SCC bound only to the node agent’s service account. The default costs you some porting work, but it blocks root containers before they reach a node and closes one common path to a security incident.

OpenShift Architecture from Control Plane to Add-Ons

An OpenShift 4 cluster runs the standard Kubernetes control plane of API server, etcd, controller manager, and scheduler, and adds the OpenShift API server and OpenShift controller manager to handle projects, routes, and templates. Every node runs Red Hat Enterprise Linux CoreOS (RHCOS), an immutable, container-focused build of RHEL, and CRI-O is the only container engine in OCP clusters. Admins don’t hand-edit nodes over Secure Shell (SSH), because the Machine Config Operator (MCO) applies operating system updates and configuration changes. When a node drifts from its rendered configuration, the MCO marks it Degraded, and the node keeps serving workloads but can’t take updates until someone resolves the drift. Tooling built against these shared APIs carries across bare metal, VMware, and public clouds, with exceptions where hardware features, cloud integrations, and install topologies differ.

Operators and the Operator Lifecycle Manager

An Operator is a custom controller that ships its own CustomResourceDefinition (CRD) objects and continuously reconciles the workload it manages, which the Operator SDK calls the Operand. Cluster Operators for components such as etcd and the API server install by default under the Cluster Version Operator, while OLM installs optional add-ons from OperatorHub through Subscription and InstallPlan objects. In that classic OLM model, each Operator declares dependencies on other packages or API groups, and OLM hands them to a Boolean satisfiability (SAT) solver that picks a compatible set before anything installs. For Day-2 control, you pin a version with startingCSV and installPlanApproval: Manual so upgrades wait for an explicit approval, and the more capable Operators also automate backups, scaling, and failover.

Service Mesh, GitOps, and Serverless

Red Hat packages three upstream projects as Operators you install from OperatorHub, and each one ships on its own release cadence, separate from OCP:

• Service Mesh (Istio): OpenShift Service Mesh 3 is a Red Hat distribution of Istio deployed through the Sail Operator, where you define an Istio resource, enforce STRICT mutual Transport Layer Security (mTLS) with PeerAuthentication, and label namespaces with istio.io/rev for sidecar injection. Service Mesh 3.2 made ambient mode generally available, though it doesn’t yet run on clusters in Federal Information Processing Standards (FIPS) mode.
• GitOps (Argo CD): OpenShift GitOps uses Argo CD as its declarative engine. ApplicationSets generate one Application per cluster matching a label selector, with prune: true and selfHeal: true keeping each cluster aligned to Git.
• Serverless (Knative): OpenShift Serverless wraps Knative Serving, Eventing, and Functions, with instances created in the knative-serving and knative-eventing namespaces. Services scale to zero by default through the Knative Pod Autoscaler, and setting autoscaling.knative.dev/min-scale keeps a warm replica for latency-sensitive services.

OLM upgrades all three through the same subscription workflow it uses for every other add-on. Each one still needs its own compatibility check against your OCP version before a cluster upgrade.

Key OpenShift Features for Platform Teams

OpenShift features split across editions. A standard OCP subscription covers these capabilities in practice:

• Developer self-service console: The web console’s Topology view shows applications, components, and build status, and Quick Search imports new components. Since OCP 4.19 the Developer perspective is off by default, so cluster admins decide whether to expose it.
• Built-in CI/CD: OpenShift Pipelines is based on Tekton and releases on its own cadence, separate from OCP. Each Pipelines version supports a specific range of OCP releases, so its release notes belong on your pre-upgrade checklist.
• Automated security controls: RBAC and SCCs ship with OCP and OpenShift Kubernetes Engine, and new pods get restricted-v2 plus the default seccomp profile. Image scanning comes from Red Hat Advanced Cluster Security (RHACS), which has used Scanner V4 as its default scanner since release 4.8 and ships with Platform Plus or as a separate purchase.
• Virtualization: OpenShift Virtualization, built on KubeVirt and the Kernel-based Virtual Machine (KVM) hypervisor, runs virtual machines (VMs) next to pods on the same cluster. It supports live migration, so a node can drain for maintenance without stopping the VMs on it.
• Hybrid consistency: OCP installs on Amazon Web Services (AWS), Azure, Google Cloud, vSphere, Nutanix, IBM Z, and bare metal, among other targets. Red Hat Advanced Cluster Management (ACM) adds lifecycle and governance across those clusters from one console.

The edition you buy decides which of these capabilities you actually receive. Who runs the control plane is the other half of that decision.

Choosing Among OpenShift Deployment Models

OpenShift deployment models fall into self-managed editions, cloud services editions that a provider runs for you, and a community build:

• OpenShift Container Platform (self-managed): You run the control plane and workers on your own hardware or cloud accounts. Upgrades, capacity, and monitoring retention settings all stay with your team.
• Red Hat OpenShift Service on AWS (ROSA): Red Hat and AWS jointly manage and support it, and AWS bills it. Its hosted control planes architecture runs the control plane in a Red Hat-owned AWS account and workers in yours, while ROSA classic keeps both in your account.
• Azure Red Hat OpenShift (ARO): Red Hat and Microsoft jointly manage it, Azure bills it, and clusters deploy into your Azure subscription.
• Red Hat OpenShift Dedicated: Red Hat hosts and fully manages it on Google Cloud or AWS. On Google Cloud deployments, Red Hat bills for OpenShift and Google Cloud bills for the infrastructure.
• Red Hat OpenShift on IBM Cloud: IBM manages the control plane and backs it with a 99.99 percent service-level agreement (SLA), versus 99.95 percent for ROSA, ARO, and Dedicated.
• OKD: The free, Apache 2.0-licensed community distribution, formerly OpenShift Origin, has run on CentOS Stream CoreOS since 4.16 after earlier releases used Fedora CoreOS. Red Hat provides no commercial support for OKD installations.

OpenShift runs in your data center and as a managed service on AWS, Azure, Google Cloud, and IBM Cloud, so one team can keep regulated workloads on-premises under OCP and run customer-facing services on ROSA or ARO with the same tooling. Mixed fleets like that also split your telemetry across as many monitoring stacks as you have clusters, which the monitoring section below returns to.

OpenShift Use Cases in Production

Each use case below pairs a production workload with the OpenShift component that supports it:

• Application modernization: OpenShift Virtualization runs legacy VMs alongside containers on one scheduler. Teams can bring VMs onto the cluster first and decide later which ones to refactor.
• AI and machine learning (ML) acceleration: On graphics processing unit (GPU) servers, the NVIDIA GPU Operator containerizes the drivers, CUDA libraries, and supporting software the hardware needs. Machine learning operations (MLOps) workloads then run on the same cluster as every other service.
• Regulated industries: The Compliance Operator automates scans against profiles such as the Center for Internet Security (CIS) OpenShift Container Platform 4 Benchmark, though it reports findings and doesn’t act as an auditor. Teams that route scan results and audit logs to the Coralogix Compliance pipeline keep them in their own Amazon Simple Storage Service (S3) bucket for as long as auditors require.
• Mission-critical applications: RHCOS delivers operating system upgrades as an atomic unit through rpm-ostree, and one rollback and reboot returns a node to its previous state. An upgrade either applies completely or not at all, so a failed patch can’t leave a node half-updated during a maintenance window.

Every one of these workloads produces telemetry data that OpenShift’s default stack only partially covers.

Monitoring OpenShift Beyond the Built-In Stack

OpenShift ships a preinstalled container monitoring stack in the openshift-monitoring namespace, where the Cluster Monitoring Operator deploys Prometheus, Alertmanager, and Thanos Querier. Prometheus keeps 15 days of platform metrics and 24 hours for user-defined projects by default, which is too short to compare this week’s behavior against last month’s upgrade. Log management and distributed tracing need the separate Loki, Tempo, and OpenTelemetry (OTel) Operators, and no default alert covers out-of-memory (OOM) kills or SCC admission failures. A production cluster needs these signals wired into its Kubernetes monitoring setup:

• Cluster health: etcdHighFsyncDurations fires on slow write-ahead log fsyncs (etcd_disk_wal_fsync_duration_seconds_bucket), and etcd_server_leader_changes_seen_total shows leader churn. KubeAPIErrorBudgetBurn fires on sustained API server errors or slow requests.
• Workload performance: KubePodCrashLooping fires after 15 minutes in CrashLoopBackOff, but the platform alerting rules scope it to the openshift-, kube-, and default namespaces. OOM kills need a custom rule on kube_pod_container_status_last_terminated_reason.
• Node saturation: KubeNodeNotReady, KubeMemoryOvercommit, and NodeFilesystemSpaceFillingUp cover node readiness, memory overcommit, and disks on track to fill.
• Security events: PodSecurityViolation fires when audit evaluations show a workload would break its namespace’s PSA profile, and it says nothing about SCC rejections. The Quay Container Security Operator records vulnerable images in running pods as ImageManifestVuln objects, but only for registries that run image scanning, and it doesn’t raise an alert on its own.

Per-cluster Prometheus can’t connect these signals on its own, because an OOM kill on a worker, the log line before it, and the trace that hit the pod usually sit in three separate backends. Coralogix collects OpenShift logs, metrics, and traces through its OpenTelemetry-native integration and shows every cluster in one set of Kubernetes dashboards. The integration’s cluster collector reports each container’s last termination reason, OOMKilled included, as a metric by default, and Streama© alerts on it in flight, so one alert definition covers every cluster instead of a custom rule per Prometheus instance. When you need the cause behind the alert, you can ask Olly, Coralogix’s autonomous observability agent, why the container died, and it answers from the logs, metrics, and traces around the kill. Every signal lands in your own cloud bucket in open Parquet format, which removes the 15-day ceiling on how far back that comparison can reach.

Running OpenShift in Production with Correlated Telemetry

OpenShift extends Kubernetes with Routes, SCCs, Operators, and a choice of self-managed or managed deployment, and those defaults remove a lot of assembly work for your platform team. The trade-offs show up in day-2 operations, where platform metrics expire after 15 days, user-defined metrics after 24 hours, and logs and traces need two more Operators before you can correlate anything. Teams running mixed fleets of OCP, ROSA, and ARO feel it most, since each cluster carries its own monitoring stack.

Coralogix addresses each of those limits directly, with an OTel chart that installs under OpenShift’s own SCC model, OOM alerts that work across the whole fleet, and a full telemetry history in your own bucket for Olly to investigate. None of it depends on a proprietary agent, because the collection layer is 100 percent OpenTelemetry-native and stays portable if you ever change backends. Coralogix offers a free 14-day trial with an eight-unit quota and no credit card required, so you can set distribution: “openshift” in its OpenTelemetry integration chart on one cluster and trace your next OOM kill across metrics, logs, and traces from your own production data.

Frequently Asked Questions About OpenShift

Is OpenShift a cloud platform?

OpenShift is a hybrid platform that runs on hardware you own and as a managed service from the major cloud providers. You can self-host OCP or OKD, or buy ROSA, ARO, OpenShift Dedicated, or OpenShift on IBM Cloud. Its cluster API stays Kubernetes-compatible everywhere it runs, so the same tooling and skills carry across environments.

What are the alternatives to OpenShift?

Upstream Kubernetes provides the building blocks but leaves CI/CD, routing, and security policy for your team to assemble. SUSE Rancher Prime manages Cloud Native Computing Foundation (CNCF) certified distributions across clusters, and VMware vSphere Kubernetes Service (formerly Tanzu Kubernetes Grid Service) targets vSphere environments. Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE) run managed control planes, while OKD offers OpenShift itself without a Red Hat subscription.

Can you learn OpenShift without prior Kubernetes experience?

You can, though Kubernetes knowledge shortens the path, since OpenShift builds on the same objects you’d use on upstream Kubernetes. Red Hat’s administration track starts with DO180, which covers containers and Kubernetes alongside OpenShift, and the EX280 exam expects RHEL administration skills before OpenShift-specific ones. The 30-day Developer Sandbox gives you a hosted OpenShift cluster to practice on at no cost.

What kinds of jobs use OpenShift?

OpenShift skills show up most often in platform engineering, site reliability engineering (SRE), DevOps, and cloud infrastructure roles. Listings that mention OpenShift usually pair it with Kubernetes and CI/CD experience, particularly in organizations that keep regulated workloads on-premises. Passing EX280 earns the Red Hat Certified System Administrator in OpenShift credential, and EX380 leads to the Advanced System Administrator in OpenShift certification.