kubectl scaleChange the replica count of a workload
kubectl scale sets how many pods a Deployment, ReplicaSet or StatefulSet should run. It's the quick lever for a traffic spike or a maintenance window, but an HPA or your next GitOps sync may set it right back.
kubectl scale (TYPE NAME | -f FILE | TYPE -l SELECTOR) --replicas=N [--current-replicas=M] [-n NS]A marketing campaign starts in ten minutes and the api has no autoscaler yet. Add two replicas now.
kubectlThe Kubernetes CLI.
kubectl sends a PATCH to the workload's scale subresource (/apis/apps/v1/namespaces/prod/deployments/api/scale) changing spec.replicas; with --current-replicas it includes a precondition so the update fails if the value changed. That is all kubectl does. The Deployment controller then sets the new count on the current ReplicaSet; the ReplicaSet controller compares desired and actual pods and creates or deletes pods. Scaling down picks victims by rules (pending before running, unready before ready, newer before older on the same node, and pods with a lower pod-deletion-cost first). StatefulSets scale one ordinal at a time by default: up creates redis-3, redis-4 in order; down removes the highest ordinal first and never deletes PVCs automatically unless a retention policy says so. The HorizontalPodAutoscaler writes to the same field, so it overrides manual changes on its next sync (about every 15 seconds).
--replicas=NNew desired replica count (required)--current-replicas=NPrecondition: only scale if currently N-l SELECTORScale every matching workload--allAll workloads of that type in the namespace--timeout=DURATIONHow long to wait for the scale to be accepted--dry-run=serverValidate without changing-n NSNamespacekubectl scale deploy/api --replicas=10 when an HPA targets itThe HPA overwrites spec.replicas on its next sync, within seconds to minutes.
kubectl patch hpa api -p '{"spec":{"minReplicas":10}}' # and update GitScaling to 0 to 'pause' a database StatefulSet without checking clientsAll pods stop; anything connected fails immediately and the Service has no endpoints.
Announce it, drain clients first, and note the PVCs are keptScaling up and assuming capacity appearsNew pods stay Pending if the nodes can't fit their requests and no autoscaler adds nodes.
kubectl get pods -l app=api; kubectl describe pod on any Pending oneUsing kubectl scale as the permanent fixThe manifest in Git still says 3; the next deploy or GitOps sync puts it back.
Change replicas (or HPA min/max) in Git and applyTry these on a Linux machine of your own. Each task has a hint and a solution.
Write the command to scale the Deployment checkout in namespace shop to 0, but only if it currently runs 4 replicas.
Read this HPA row and say whether a manual scale to 6 will stick: 'api Deployment/api cpu: 85%/70% 3 10 5 41d'
In AWS Lab > EKS > your cluster > Run kubectl (lab), deploy the sample app and scale it to 3 replicas, then back to 1.
kubectl scaleChange the replica count of a workload
kubectl scale sets how many pods a Deployment, ReplicaSet or StatefulSet should run. It's the quick lever for a traffic spike or a maintenance window, but an HPA or your next GitOps sync may set it right back.
kubectl scale (TYPE NAME | -f FILE | TYPE -l SELECTOR) --replicas=N [--current-replicas=M] [-n NS]A marketing campaign starts in ten minutes and the api has no autoscaler yet. Add two replicas now.
kubectlThe Kubernetes CLI.
kubectl sends a PATCH to the workload's scale subresource (/apis/apps/v1/namespaces/prod/deployments/api/scale) changing spec.replicas; with --current-replicas it includes a precondition so the update fails if the value changed. That is all kubectl does. The Deployment controller then sets the new count on the current ReplicaSet; the ReplicaSet controller compares desired and actual pods and creates or deletes pods. Scaling down picks victims by rules (pending before running, unready before ready, newer before older on the same node, and pods with a lower pod-deletion-cost first). StatefulSets scale one ordinal at a time by default: up creates redis-3, redis-4 in order; down removes the highest ordinal first and never deletes PVCs automatically unless a retention policy says so. The HorizontalPodAutoscaler writes to the same field, so it overrides manual changes on its next sync (about every 15 seconds).
--replicas=NNew desired replica count (required)--current-replicas=NPrecondition: only scale if currently N-l SELECTORScale every matching workload--allAll workloads of that type in the namespace--timeout=DURATIONHow long to wait for the scale to be accepted--dry-run=serverValidate without changing-n NSNamespacekubectl scale deploy/api --replicas=10 when an HPA targets itThe HPA overwrites spec.replicas on its next sync, within seconds to minutes.
kubectl patch hpa api -p '{"spec":{"minReplicas":10}}' # and update GitScaling to 0 to 'pause' a database StatefulSet without checking clientsAll pods stop; anything connected fails immediately and the Service has no endpoints.
Announce it, drain clients first, and note the PVCs are keptScaling up and assuming capacity appearsNew pods stay Pending if the nodes can't fit their requests and no autoscaler adds nodes.
kubectl get pods -l app=api; kubectl describe pod on any Pending oneUsing kubectl scale as the permanent fixThe manifest in Git still says 3; the next deploy or GitOps sync puts it back.
Change replicas (or HPA min/max) in Git and applyTry these on a Linux machine of your own. Each task has a hint and a solution.
Write the command to scale the Deployment checkout in namespace shop to 0, but only if it currently runs 4 replicas.
Read this HPA row and say whether a manual scale to 6 will stick: 'api Deployment/api cpu: 85%/70% 3 10 5 41d'
In AWS Lab > EKS > your cluster > Run kubectl (lab), deploy the sample app and scale it to 3 replicas, then back to 1.