Outcome
By the end of this lesson, you will be able to resize a worker pool and edit the cluster autoscaler through OCM, explain which settings each topology exposes, and name what the integration refuses to do.
| Tier | Operator |
| JTBD | ”Change a ROSA pool’s size without dropping to the OCM console.” |
| Personas | Platform Engineer · SRE |
| Prerequisites | M1.7.L3 |
| Time | 9 minutes |
| Bloom verb | Resize (Apply), Explain (Understand), Name (Remember) |
1. Concept
Configuration sits on a Settings tab next to the workload view, and it goes through Red Hat’s manager rather than through the cluster.
That matters twice over. It still works when the cluster’s own API is private and unreachable from outside. And it is applied the same way every other provider’s cluster configuration is applied, by a job that runs and reports back.
WHAT YOU CAN CHANGE a worker pool's size the cluster-wide autoscaler
WHAT YOU CANNOT everything elsePool resize: one mode at a time
A POOL IS EITHER FIXED SIZE e.g. 4 nodesor AN AUTOSCALING RANGE e.g. min 3, max 12
NOT BOTH. OCM refuses a pool carrying both, so the UImakes you choose a mode rather than letting you submitsomething OCM will reject.That rule is Red Hat’s, not ours. Presenting it as one choice between two modes, rather than two fields you could fill in together, is what stops you writing something that gets rejected when you save it.
The cluster autoscaler: topology decides what you get
This is where the classic/hosted distinction from L3 comes back.
HOSTED CONTROL PLANE: FOUR settings editable maxNodesTotal maxPodGracePeriod podPriorityThreshold maxNodeProvisionTime
CLASSIC: the above plus the rest, INCLUDING the wholescale-down group, which is classic-only in ROSA.So a scale-down tuning question has different answers on the two topologies, and on hosted the answer is that those knobs do not exist to turn.
The autoscaler cannot be switched off
ON EITHER TOPOLOGY.
On hosted, its lifetime is the CLUSTER'S: "off" is not astate it can be put into, because the autoscaler is nota separate thing with its own lifecycle there.If your intent is “stop this cluster scaling”, the available lever is a narrow range (min equal to max) rather than disabling the autoscaler. That achieves the practical effect without pretending a state exists that does not.
Adding and deleting pools is refused
ADD A POOL REFUSEDDELETE A POOL REFUSED
WHY: creating a pool LAUNCHES INSTANCES THAT DID NOTEXIST. Deleting one TERMINATES EVERY NODE IN IT.
Both are provisioning, and this integration does notprovision.That line is the boundary of the whole feature, and it is drawn in the same place as everywhere else in this curriculum: the platform will change the shape of something that exists, and it will not bring things into existence or destroy them here.
Configuration only, and the controls are withheld
NOTHING ELSE IS WRITTEN TO THE CLUSTER.
no workload create no manifest edit no delete no deploy
ZopDay reaches a ROSA cluster's Kubernetes API to READit, and reaches OCM to CONFIGURE it. That is the wholewrite surface.The controls are withheld in the UI rather than failing on submit. That is a small design decision with a real effect: you find out what is unavailable while you are deciding, not after you have made a plan around it.
And still nothing is schedulable
Restating from L1 because this is the lesson where people expect it to change:
Resizing a pool through OCM is a CONFIGURATION CHANGE,not scheduling.
You can set a pool to 3 nodes. You cannot attach it to aschedule that sets it to 3 at 8pm and 6 at 8am.
Worker nodes are Red Hat-managed; stopping them isoutside the service boundary.So an off-hours saving on ROSA is a manual configuration change, or a scripted one against OCM, and not a ZopNight schedule.
2. Demo
Two configuration changes and one refusal:
CHANGE 1: dev-rosa-01, classic, fixed pool Current: default pool, fixed 6 nodes Intent: drop to 3 outside business hours
Settings tab -> pool `default` mode: FIXED size: 6 -> 3 Applied by an update job. Two minutes to submit, a few minutes for OCM to converge.
THE FOLLOW-UP QUESTION "Can we schedule this?" No. This is a configuration change. The team scripted it against OCM on a cron of their own instead, and accepted that ZopNight shows the resulting size rather than driving it.
CHANGE 2: prod-rosa-01, HOSTED, autoscaling pool Intent: stop the cluster scaling past 20 nodes during a cost freeze
Settings tab -> cluster autoscaler Editable here: maxNodesTotal, maxPodGracePeriod, podPriorityThreshold, maxNodeProvisionTime maxNodesTotal: 40 -> 20
WHAT THEY ALSO WANTED AND COULD NOT HAVE scale-down delay tuning. That whole group is CLASSIC-ONLY in ROSA, so on a hosted cluster those settings do not exist. Not withheld by ZopNight: absent from the platform.
WHAT THEY ASKED NEXT "Can we just turn the autoscaler off for the freeze?" No, on either topology. On hosted its lifetime is the cluster's. The available lever is a narrow range, so they set min equal to max on the pool for the freeze window and reverted afterwards.
REFUSAL: staging-rosa-01 Intent: delete an unused second pool, 4 idle nodes, about $340/mo
The control is not offered. Deleting a pool terminates every node in it, which is provisioning.
They did it in the OCM console directly, which is the correct place for it, and ZopNight reflected the change on the next discovery cycle.
WHAT THIS BOUNDARY IS WORTH The team's initial reaction was that the refusals were limitations. By the end of the week their reading had changed: the integration does not hold a credential that can destroy their production capacity, and that is a property they wanted in a cost tool.3. Hands-on (6 min)
1. For one cluster, open the Settings tab. Which autoscaler settings are editable? ______________________________________________ How many? ______ Topology? classic / hosted (Four means hosted.)
2. Take a pool. What mode is it in? [ ] fixed size [ ] autoscaling range Try to set both a fixed size AND a range. Can you? Y / N
3. Try to add a pool. Is the control offered? Y / N Try to delete one. Offered? Y / N Where would you do those instead? ______________________________________________
4. Try to turn the autoscaler off. Can you? Y / N What is the nearest available lever? ______________________________________________
5. If you need an off-hours node reduction on ROSA, write the plan: ______________________________________________ (It will not involve a ZopNight schedule.)4. Knowledge check
Q1
On a hosted-control-plane ROSA cluster, four cluster-autoscaler settings are editable. The scale-down group is not available because:
A. ZopNight withholds it on hosted clusters
B. Those settings are classic-only in ROSA
C. It requires OCM Organization Administrator
D. Scale-down is managed by Red Hat on hosted clusters
Show answer
Correct: B. They are absent from the platform on hosted control planes rather than withheld by ZopNight, so the answer to a scale-down tuning question genuinely differs between the two topologies. The four that are editable on hosted are maxNodesTotal, maxPodGracePeriod, podPriorityThreshold and maxNodeProvisionTime. Knowing which topology a cluster uses (L3) is what tells you which conversation you are able to have.
Q2
Why does the integration refuse to add or delete a machine pool?
A. OCM does not expose those operations
B. They require a Kubernetes credential rather than an OCM one, which this particular connection does not hold
C. Both are provisioning: creating a pool launches instances that did not exist, and deleting one terminates every node in it
D. They are only available on classic clusters
Show answer
Correct: C. This integration changes the shape of things that exist and does not bring them into existence or destroy them. The controls are withheld in the UI rather than failing on submit, so you learn what is unavailable while deciding rather than after building a plan around it. The OCM console remains the correct place for those operations.
Q3
A team wants to reduce a ROSA pool from 6 nodes to 3 outside business hours, automatically. The accurate answer:
A. Attach the pool to a ZopNight schedule
B. Not available
C. Use the cluster autoscaler’s scale-down settings
D. Use an override with a time-bounded expiry
Show answer
Correct: B. Resizing a pool through OCM is a configuration change, not scheduling, and no ROSA resource is schedulable because worker nodes are Red Hat-managed. The options are to change it by hand, or to script it against OCM and run that as often as they like. C is tempting and wrong twice over: scale-down settings are classic-only, and the autoscaler responds to load rather than to a clock. This is the boundary of the managed service rather than a missing ZopNight feature.
5. Apply
Use the Settings tab for pool sizing and autoscaler bounds, and expect to drop to the OCM console for anything that creates or destroys capacity. That split is deliberate and it is the reason the integration does not hold a credential capable of terminating your production nodes.
For off-hours node reductions, plan a scripted OCM change rather than a ZopNight schedule.
Related lessons
- L3: Discovery and the workload view
- L1: Why ROSA is different
- T2.M2.4.L5: Apply, pause, resume, remove
- T2.M2.6.L3: Scheduling a Deployment to zero replicas
Glossary terms touched
Cluster autoscaler · maxNodesTotal · Hosted control plane · Update job