Scaling, releases & upgrades

Before you start

You have a provided pilot cluster, a trusted kubeconfig, kubectl and access to an agreed namespace. Set KUBECONFIG, CP_CONTEXT and CP_NAMESPACE using the access guide before running the commands. The examples use a POSIX shell and a single access file. Grouped blocks stop at missing settings without closing your terminal; they do not provision infrastructure or grant permissions. Connect to your cluster →

Use a reviewed manifest and an application with a known release/recovery path. Confirm whether a GitOps or other controller owns the workload: direct edits can be overwritten by that controller.

Three different changes

The Cloud UI, automatic infrastructure scaling and supported upgrade operations must be confirmed for the pilot. These workload commands are not promises of a self-service Cloud lifecycle interface.

Scale a stateless application deliberately

In the disposable cloud-demo exercise, after confirming the application supports multiple replicas and the quota/capacity can fit them, this changes the Deployment to two replicas. It does not add a worker node. If a controller owns the Deployment, make the same change in its source configuration instead.

(
: "${KUBECONFIG:?Set KUBECONFIG from your handover}"
: "${CP_CONTEXT:?Set CP_CONTEXT from your handover}"
: "${CP_NAMESPACE:?Set CP_NAMESPACE from your handover}"
case "$CP_CONTEXT:$CP_NAMESPACE" in
  YOUR_*|*:YOUR_*) printf '%s\n' 'Replace the YOUR_ context and namespace placeholders first.' >&2; exit 1 ;;
esac
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" scale deployment/cloud-demo --replicas=2
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" rollout status deployment/cloud-demo --timeout=300s
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" get pods -l app=cloud-demo
)

HPA requires appropriate metrics and limits and can conflict with a manually owned replica count. Confirm its availability, maximum scale and capacity/cost handling before enabling it. Two replicas on one failure domain are not an HA guarantee.

Release with an observable rollback path

1. 01

   Review the candidate

   Pin the approved image, review changes to configuration and database schema, and run server dry-run/diff. Keep the previous manifest and image available.

2. 02

   Watch the result

   Apply through the owner of the workload, check rollout and test the application's key user journey. Ready status is necessary but does not prove business behavior.

3. 03

   Choose recovery based on the failure

   A Deployment rollback restores an earlier Pod template. It does not undo a database migration, a changed Secret or external side effects. Use the application-specific recovery plan for those changes.

(
: "${KUBECONFIG:?Set KUBECONFIG from your handover}"
: "${CP_CONTEXT:?Set CP_CONTEXT from your handover}"
: "${CP_NAMESPACE:?Set CP_NAMESPACE from your handover}"
case "$CP_CONTEXT:$CP_NAMESPACE" in
  YOUR_*|*:YOUR_*) printf '%s\n' 'Replace the YOUR_ context and namespace placeholders first.' >&2; exit 1 ;;
esac
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" rollout history deployment/cloud-demo
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" rollout status deployment/cloud-demo --timeout=300s
)

For a manually managed, stateless exercise only, set CP_REVISION to the verified prior revision. Review compatibility first, then perform the change below. For declaratively managed workloads, restore the reviewed source manifest instead.

(
: "${KUBECONFIG:?Set KUBECONFIG from your handover}"
: "${CP_CONTEXT:?Set CP_CONTEXT from your handover}"
: "${CP_NAMESPACE:?Set CP_NAMESPACE from your handover}"
case "$CP_CONTEXT:$CP_NAMESPACE" in
  YOUR_*|*:YOUR_*) printf '%s\n' 'Replace the YOUR_ context and namespace placeholders first.' >&2; exit 1 ;;
esac
: "${CP_REVISION:?Set the verified prior revision}"
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" rollout undo deployment/cloud-demo --to-revision="$CP_REVISION"
kubectl --kubeconfig="$KUBECONFIG" --context="$CP_CONTEXT" --namespace="$CP_NAMESPACE" rollout status deployment/cloud-demo --timeout=300s
)

Prepare Kubernetes maintenance together

• ✓
  Confirm the target version and application/API compatibility; test the candidate configuration first.
• ✓
  Agree interruption limits, maintenance window, named contacts and monitoring during the operation.
• ✓
  Check replicas, disruption policies, schedulable headroom and data recovery before worker replacement.
• ✓
  Define post-maintenance application acceptance and recovery ownership. A version downgrade is not an assumed rollback strategy.

Do not run node drain, operating-system updates or cluster upgrade commands from these customer guides. Request the agreed managed operation and preserve its result in your change record.