Outcome
By the end of this lesson, you will be able to predict what ROSA discovery returns, recognise the five OpenShift-native kinds the workload view adds, and handle a cluster whose API server is private.
| Tier | Operator |
| JTBD | ”Know what I will and will not see once the cluster is connected.” |
| Personas | Platform Engineer · SRE |
| Prerequisites | M1.7.L2 |
| Time | 9 minutes |
| Bloom verb | Predict (Apply), Recognise (Remember), Handle (Apply) |
1. Concept
There are two layers here, and they come from the two trust domains in L1.
LAYER 1: DISCOVERY, via OCM Two resource types. Available as soon as the OCM credential is connected, before any cluster access.
openshift-cluster openshift-machinepool
LAYER 2: THE LIVE WORKLOAD VIEW, via the cluster API The full Kubernetes set plus five OpenShift-native kinds. Requires provisioned cluster access (L2).Machine pools, two names, one type
ROSA comes in two shapes, and this module calls each a topology: how the cluster’s control plane is arranged. Classic ROSA runs the control plane in your own account. Hosted Control Plane runs it in Red Hat’s.
The two shapes use different words for the same thing:
CLASSIC ROSA "machine pools"HOSTED CONTROL PLANE "node pools"
BOTH land as `openshift-machinepool`.That is deliberate. They mean the same thing, so ZopNight calls them the same thing, and a filter, a report or a group then works on both without you having to know which shape a cluster is.
The distinction does come back in L4, because the two shapes offer different autoscaler settings.
The five OpenShift-native kinds
The workload view shows everything you would expect from Kubernetes, plus five things that exist only on OpenShift:
Routes how OpenShift exposes a service to the outside; older than, and separate from, Kubernetes IngressDeploymentConfigs OpenShift's older way of describing a deploymentBuildConfigs the build pipeline definitionImageStreams the image reference abstractionProjects OpenShift's namespace wrapperThese are live-only: they are read from the cluster API for the workload view and are not persisted as discovered resource rows. So you can see a Route in the workload view and you cannot filter the global resource list for Routes.
They are shown beside their Kubernetes counterparts rather than in a separate vendor section. A Route sits next to Ingress, a DeploymentConfig next to Deployment. That is the right call for a reader who is trying to understand one application rather than trying to learn OpenShift.
The private API server case
A CLUSTER WHOSE API SERVER IS PRIVATE CANNOT BE REACHEDAT ALL.
On modern ROSA, PrivateLink is fixed at INSTALL TIME.It cannot be changed afterwards, so this is TERMINALrather than a configuration problem to work around.
The cluster is FLAGGED rather than hidden.Flagging rather than hiding is the right behaviour and worth understanding: a hidden cluster looks like a discovery gap and generates a support ticket, while a flagged one tells you the situation is permanent and lets you plan around it.
You still get everything that comes through Red Hat’s manager. The cluster appears, its machine pools appear, their configuration is readable, and L4’s settings still work, because none of that touches the cluster itself. What you lose is the workload view.
What discovery gives you before any cluster access
This is the part people underestimate. With only the OCM credential connected:
YOU CAN SEE every cluster in the organisation every machine pool, with its size or autoscaling range the cluster's configuration cost, through the underlying AWS spend
YOU CANNOT SEE workloadsFor a cost-focused use case that is frequently sufficient. Cluster access is what you provision when you need to reason about what is running, not what it costs.
2. Demo
What appeared, in the order it appeared:
STEP 1: OCM CREDENTIAL ONLY
Resources, provider=openshift: openshift-cluster 3 prod-rosa-01 hosted control plane staging-rosa-01 classic dev-rosa-01 classic openshift-machinepool 7 prod-rosa-01 / workers-a autoscaling 3-12 prod-rosa-01 / workers-b autoscaling 2-8 staging-rosa-01 / default fixed 4 dev-rosa-01 / default fixed 6...
Note both topologies present, both as openshift-machinepool. The classic/hosted distinction is visible on the cluster, not in the type name.
Cost already flowing, from the underlying AWS spend.
STEP 2: CLUSTER ACCESS ON staging-rosa-01
Workloads tab populated: Deployments, StatefulSets, DaemonSets, Services, Ingresses, ConfigMaps, PVCs... the usual set PLUS Routes 14 DeploymentConfigs 3 (legacy, pre-migration) BuildConfigs 9 ImageStreams 11 Projects 22
The three DeploymentConfigs were a finding in themselves: a migration to Deployments that had stalled two years earlier and that nobody had a list of.
STEP 3: prod-rosa-01
Workload view: FLAGGED, private API server.
PrivateLink, fixed at install. Terminal.
What still worked: the cluster and its two machine pools, from OCM their autoscaling ranges cost the L4 configuration path, because it goes through OCM and not the cluster API
What was lost: workload visibility on the production cluster, permanently, unless it is rebuilt.
WHAT THE TEAM DID Accepted it. They get cost and configuration on prod, and workload visibility on the two clusters where they can reach the API. The flag told them this immediately rather than after a week of debugging.3. Hands-on (6 min)
1. With only the OCM credential connected, count: openshift-cluster ______ openshift-machinepool ______
2. For each cluster, note its topology: ______________ classic / hosted ______________ classic / hosted (You will need this in L4: the two expose different autoscaler settings.)
3. On a connected cluster, open Workloads and find the five OpenShift-native kinds: Routes ____ DeploymentConfigs ____ BuildConfigs ____ ImageStreams ____ Projects ____
4. Any DeploymentConfigs? Those are usually a stalled migration nobody has a list of. How many, and in which projects? ______________________________________________
5. Try to filter the GLOBAL resource list for Routes. Can you? Y / N Why not? ______________________________________________4. Knowledge check
Q1
A classic ROSA cluster has “machine pools” and a hosted-control-plane cluster has “node pools”. In ZopNight they appear as:
A. Two separate resource types
B. Children of the cluster with no type of their own
C. One type, openshift-machinepool, for both
D. openshift-machinepool and openshift-nodepool respectively
Show answer
Correct: C. The two topologies name the same concept differently, and normalising them means a filter, report or group works across both without the reader needing to know which topology a cluster uses. The distinction does resurface in configuration: the two topologies expose different cluster-autoscaler settings, which is covered in L4.
Q2
A ROSA cluster’s API server is private. The consequence:
A. Workload visibility resumes once network access is granted
B. Only the automatic connection method works
C. The cluster is excluded from discovery
D. It is terminal
Show answer
Correct: D. PrivateLink is fixed at install time on modern ROSA, so it cannot be changed afterwards. The cluster is flagged rather than hidden, and OCM-side discovery, machine pools, cost and the configuration path all continue to work; only the workload view is lost. Flagging it rather than hiding it is deliberate. A cluster that has vanished looks like a bug and produces a support ticket. A cluster marked as permanently out of reach tells the team what is actually going on, and lets them plan around it.
Q3
Routes, DeploymentConfigs, BuildConfigs, ImageStreams and Projects are:
A. Discovered resource types you can filter the global resource list by
B. Available only on classic ROSA
C. Live-only kinds read from the cluster API for the workload view
D. Visible only with the automatic connection method
Show answer
Correct: C. They are not persisted as discovered resource rows, and they are shown beside their Kubernetes counterparts rather than in a separate vendor section. Placing a Route next to Ingress and a DeploymentConfig next to Deployment suits a reader trying to understand one application, rather than one trying to learn OpenShift’s vocabulary.
5. Apply
Connect the OCM credential first and see how far that gets you. For a purely cost-focused use case, cluster and machine-pool discovery plus the underlying AWS spend is frequently enough, and cluster access is what you add when you need to reason about workloads.
If a production cluster comes back flagged for a private API server, plan around it immediately rather than treating it as something to fix.
Related lessons
- L2: The three connection methods
- L4: Configuration through OCM (next)
- T1.M1.2.L1: What gets discovered
- T2.M2.6.L2: Cluster, namespace, workload hierarchy
Glossary terms touched
Route · DeploymentConfig · ImageStream · PrivateLink