kubectl scale: Set Replicas in CI
kubectl scale sets the desired replica count on a Deployment, ReplicaSet, StatefulSet, or ReplicationController.
Pipelines scale workloads to zero before a migration or up for a load test. scale changes the count directly without editing the manifest.
What it does
kubectl scale updates spec.replicas on the target workload. It can be made conditional with --current-replicas (only scale if the current count matches) or --resource-version (optimistic concurrency), which guards against racing another change.
Common usage
kubectl scale deployment/api --replicas=5
kubectl scale statefulset/db --replicas=0 -n data
# only scale if currently at 3 (avoids racing)
kubectl scale deploy/api --current-replicas=3 --replicas=6
# scale everything matching a label
kubectl scale deploy -l tier=web --replicas=2Options
| Flag | What it does |
|---|---|
| --replicas=<n> | Desired replica count |
| --current-replicas=<n> | Precondition: only scale if current count matches |
| --resource-version=<v> | Precondition on the resourceVersion |
| -l, --selector | Scale all workloads matching the label |
| --timeout=<dur> | How long to wait for the scale to register |
In CI
scale only sets the count; it does not wait for pods. Follow it with kubectl rollout status or kubectl wait if the job needs the new replicas ready. If an HPA manages this workload, a manual scale will be reverted on the next reconcile, so pause or remove the HPA first.
Common errors in CI
"Error from server (Conflict): ... the object has been modified" means another writer changed it; drop the --current-replicas/--resource-version precondition or retry. "Error from server (NotFound): deployments.apps \"api\" not found" means a wrong name or namespace. "error: cannot scale ... expected x replicas, got y" means the --current-replicas precondition did not hold.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes