Add support for kubectl rollout restart --all --all-namespaces

[merihilgor]

What would you like to be added?

Please add support for the following usage patterns:

bash
CopyEdit
kubectl rollout restart --all
kubectl rollout restart --all --all-namespaces

These would restart all rollout-capable resources (e.g., Deployment, StatefulSet, DaemonSet, possibly ReplicaSet) either:

• in the current namespace (--all), or

• across the whole cluster (--all --all-namespaces).

This would make rollout restart behave consistently with other kubectl verbs like get, describe, delete, etc., which allow generic use of --all and --all-namespaces.

Why is this needed?

Today, if I want to restart everything in a namespace or cluster, I need to write scripts like:

bash
CopyEdit
kubectl get deployments,statefulsets,daemonsets --all-namespaces -o name \
  | xargs -n1 kubectl rollout restart

This is:

• Inelegant

• Not aligned with kubectl CLI ergonomics

• Difficult to remember for newcomers or use in CI pipelines

There is no natural or native equivalent to:

bash
CopyEdit
kubectl delete pods --all --all-namespaces

But there should be a safe, controller-respecting alternative that uses rollout restart.

Benefits:

• Safer cluster-wide restarts after config changes

• Improved automation and scripting

• Better developer experience

• Prevents misuse of kubectl delete pods

Suggested Behavior:

Command | Behavior -- | -- kubectl rollout restart --all | Restarts all rollout-compatible resources in the current namespace kubectl rollout restart --all --all-namespaces | Restarts all rollout-compatible resources cluster-wide Optionally support --resource-types to filter | For example: --resource-types=deployments,statefulsets

Example Use Cases:

• Restart everything after ConfigMap or Secret change

• CI/CD rollback or redeploy logic

• Cluster-wide rolling restarts in dev/test environments

• Reboot mitigation without deleting pods

---

Would you like me to submit this issue on your behalf, or would you like to submit it yourself with this content?

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.