# kubectl rollout restart: Command Reference for CI/CD

> Reference for kubectl rollout restart: trigger a fresh rolling restart with no spec change, to pick up a rotated Secret or ConfigMap, with a gated CI example.

Source: https://latchkey.dev/learn/command-reference/kubectl-rollout-restart-command-cli-reference  
Updated: 2026-06-26

Roll all pods without touching the spec, to pick up new config.

kubectl rollout restart triggers a fresh rolling restart of a workload with no spec change. It is how you make pods re-read a rotated Secret or ConfigMap that was mounted at start. This reference covers the command and its CI use.

## Common flags and usage

- rollout restart deploy/<name>: rolling restart, spec unchanged
- Works on Deployments, StatefulSets, and DaemonSets
- Adds a kubectl.kubernetes.io/restartedAt pod annotation
- Respects the workload maxUnavailable/maxSurge strategy
- Follow with rollout status to gate on completion

## Example

```shell
kubectl create secret generic db-creds \
  --from-literal=password=${DB_PASSWORD} \
  --dry-run=client -o yaml | kubectl apply -f -
kubectl rollout restart deploy/web
kubectl rollout status deploy/web --timeout=120s
```

## In CI

Pods do not automatically reload a Secret or ConfigMap consumed as an env var; restart forces a fresh rollout so the new value is picked up. It is a no-spec-change rollout, so always gate it with rollout status to confirm the new pods became Ready.

## 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.

```Terminal
# 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
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubectl rollout restart: Command Reference for CI/CD?

kubectl rollout restart triggers a fresh rolling restart of a workload with no spec change. It is how you make pods re-read a rotated Secret or ConfigMap that was mounted at start. This reference covers the command and its CI use.

### In CI?

Pods do not automatically reload a Secret or ConfigMap consumed as an env var; restart forces a fresh rollout so the new value is picked up. It is a no-spec-change rollout, so always gate it with rollout status to confirm the new pods became Ready.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt