Introduction

Kubernetes has no native "pause" or "stop" command for pods. Pods are either running or terminated — there is no suspended state. To effectively stop a pod, you scale its controlling Deployment or StatefulSet to zero replicas. To "pause" a pod (keep it running but idle), you can patch it with a command override that sleeps, use kubectl rollout pause, or suspend a CronJob. The right approach depends on whether you want to stop the workload temporarily, debug it, or prevent new instances from running.

Scale to Zero Replicas (Most Common)

1# Stop all pods in a Deployment
2kubectl scale deployment my-app --replicas=0
3
4# Verify pods are terminating
5kubectl get pods -l app=my-app
6# No resources found
7
8# Resume by scaling back up
9kubectl scale deployment my-app --replicas=3

This terminates all pods managed by the Deployment. The Deployment definition stays intact, so scaling back up restarts the pods with the same configuration.

For StatefulSets:

1kubectl scale statefulset my-database --replicas=0
2
3# Resume
4kubectl scale statefulset my-database --replicas=1

Pause a Deployment Rollout

kubectl rollout pause prevents new ReplicaSets from being created during updates but does not stop running pods:

1# Pause — prevents rollout of new changes
2kubectl rollout pause deployment my-app
3
4# Make changes without triggering a rollout
5kubectl set image deployment/my-app app=myimage:v2
6kubectl set env deployment/my-app ENV=production
7# No new pods are created
8
9# Resume — triggers a single rollout with all accumulated changes
10kubectl rollout resume deployment my-app

This is useful when you want to batch multiple config changes into a single rollout instead of triggering separate updates for each change.

Delete the Pod Directly

1# Delete a specific pod
2kubectl delete pod my-app-abc123
3
4# The Deployment/ReplicaSet immediately creates a replacement
5# To permanently stop, scale to 0 first or delete the controller

Deleting a pod managed by a Deployment causes the controller to spawn a replacement immediately. To stop the pod permanently, delete the Deployment or scale it to zero first.

Override the Pod Command (Sleep/Pause)

To keep the pod running but idle (for debugging), override its command:

1# patch-sleep.yaml
2spec:
3  template:
4    spec:
5      containers:
6      - name: my-container
7        command: ["sleep", "infinity"]

1kubectl patch deployment my-app --patch-file patch-sleep.yaml
2
3# The pod restarts with 'sleep infinity' instead of the real application
4# You can exec into it for debugging
5kubectl exec -it my-app-xyz789 -- /bin/sh

To resume, remove the command override:

kubectl patch deployment my-app --type json \
  -p '[{"op": "remove", "path": "/spec/template/spec/containers/0/command"}]'

Suspend a CronJob

1# Suspend — prevents new jobs from being scheduled
2kubectl patch cronjob my-job -p '{"spec": {"suspend": true}}'
3
4# Verify
5kubectl get cronjob my-job
6# NAME     SCHEDULE      SUSPEND   ACTIVE
7# my-job   */5 * * * *   True      0
8
9# Resume
10kubectl patch cronjob my-job -p '{"spec": {"suspend": false}}'

Suspending a CronJob does not terminate already-running Job pods. It only prevents new executions from starting.

Using kubectl debug for Inspection

1# Create a debug copy of the pod with a different command
2kubectl debug my-app-abc123 -it --copy-to=my-app-debug \
3  --container=my-container -- /bin/sh
4
5# The debug pod runs alongside the original
6# Useful for inspecting without modifying the running pod

YAML Examples

Scale to Zero in a Manifest

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: my-app
5spec:
6  replicas: 0  # Effectively "stopped"
7  selector:
8    matchLabels:
9      app: my-app
10  template:
11    metadata:
12      labels:
13        app: my-app
14    spec:
15      containers:
16      - name: app
17        image: myimage:latest

Using Kustomize to Toggle

1# kustomization.yaml
2resources:
3  - deployment.yaml
4
5patches:
6  - target:
7      kind: Deployment
8      name: my-app
9    patch: |
10      - op: replace
11        path: /spec/replicas
12        value: 0

Comparison of Methods

Common Pitfalls

• Deleting a pod without scaling down: If the pod is managed by a Deployment or ReplicaSet, deleting it causes Kubernetes to immediately create a replacement. Scale the Deployment to zero replicas first, then the pod terminates permanently.
• Confusing rollout pause with stopping pods: kubectl rollout pause only prevents new rollouts from proceeding. It does not stop or pause running pods. Existing pods continue running normally.
• Losing PersistentVolumeClaim data: Scaling a StatefulSet to zero keeps its PVCs by default, but scaling a Deployment to zero does not protect dynamically provisioned volumes unless the reclaim policy is Retain. Verify your PV reclaim policy before scaling down.
• Not accounting for graceful shutdown: When a pod is terminated, Kubernetes sends SIGTERM and waits up to terminationGracePeriodSeconds (default 30s) before sending SIGKILL. If your application needs more time to shut down cleanly, increase this value in the pod spec.
• Suspending a CronJob while a Job is running: suspend: true prevents new Jobs from starting but does not terminate the currently running Job. If you need to stop an active Job, delete its pods separately with kubectl delete job <job-name>.

Summary

• Kubernetes has no "pause pod" command — scale Deployments/StatefulSets to 0 replicas instead
• kubectl scale deployment <name> --replicas=0 is the standard way to stop pods
• kubectl rollout pause prevents new rollouts but does not stop running pods
• Override the container command to sleep infinity for a running-but-idle debug pod
• Use suspend: true on CronJobs to prevent new scheduled executions
• Deleting a pod managed by a controller causes immediate replacement — always scale down first