On this page
Manage nodes and capacity
Review node capacity, request a scale change or replacement and verify cost, safety checks and the resulting operation in the browser.
These steps describe the intended customer path. Use the interface only after personal access and written confirmation of this capability in your pilot scope.
Before you start
Have a current cluster view, an approved node limit, a reason for the change, a maintenance window and cost approval. Scale and replacement operations exist in the self-hosted product code; Cloud entitlement and capacity changes require explicit pilot qualification. Do not assume an Add worker button is available to Cloud customers.
1. Classify the change
| You want to change | Use | Cost / risk |
|---|---|---|
| Application replicas | Application or workload view; uses existing capacity. | Can increase resource use without adding a worker; check quotas. |
| Worker count | Cluster capacity action or managed request. | Adds recurring infrastructure cost and a topology change. |
| Node size | Capacity change request; replacement may be required. | May restart workloads and alter the resource bill. |
2. Request capacity in the browser
- 01
Open Clusters → capacity
Verify organization, cluster and current node inventory. Record the last observed update time before starting a change.
- 02
Enter the delta
Enter the desired count or replacement shape, the workload reason and the maintenance window. Review the plan limit, capacity availability, storage/network implications and estimated recurring cost shown for your proposal.
- 03
Review safeguards
The page must identify disruption, drain/replace behavior, idempotency and a confirmation for destructive removal. If a preview is unavailable, stop and ask the operator for the change plan.
- 04
Confirm and follow
Confirm once, then use Activity or Operations for the operation ID and each step. Never infer completion from a browser redirect.
3. Verify the result
- ✓The intended node count and roles are visible and the cluster reports a current ready state.
- ✓Existing workloads remain Ready; a capacity change is not accepted solely because the node list changed.
- ✓Usage and the individual proposal show the new Compute/Storage/Network items and billing period.
- ✓The operation history contains the actor, requested delta, observed result and any recovery step.
4. If the change fails
Keep the operation open and read the bounded reason. Capacity conflict, quota denial, scheduling failure, timeout and degraded workload are different outcomes. Do not submit a second scale request while the first is unknown or still active.
Manage a cluster in the Cloud → · Monitor and troubleshoot in the browser →
Use this guide within your agreed pilot scope. Kubernetes examples are not evidence of a generally available Cloud capability.