What is the current equivalent of kubectl run --generatorrun/v1
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
The --generator flag for kubectl run was deprecated in Kubernetes 1.18 and removed in 1.21. Previously, kubectl run --generator=run/v1 created a bare Pod, while other generators created Deployments, Jobs, or ReplicationControllers. The modern equivalent is simply kubectl run (which now only creates Pods) or using kubectl create for other resource types.
What the Generators Did
Before deprecation, kubectl run used generators to create different Kubernetes resources:
| Generator | Resource Created | Status |
run/v1 | Pod | Removed — use kubectl run |
run-pod/v1 | Pod | Removed — use kubectl run |
deployment/v1beta1 | Deployment | Removed — use kubectl create deployment |
deployment/apps.v1 | Deployment | Removed — use kubectl create deployment |
job/v1 | Job | Removed — use kubectl create job |
cronjob/v1beta1 | CronJob | Removed — use kubectl create cronjob |
Modern Equivalents
Creating a Pod (was --generator=run/v1)
With additional options:
Creating a Deployment
With more options:
Creating a Job
Creating a CronJob
kubectl run Options Reference
Modern kubectl run creates only Pods. Key options:
Generating YAML Manifests
Use --dry-run=client -o yaml to generate manifests without creating resources:
This is the recommended approach for creating initial manifest files that you then customize and version control.
Quick Debugging Pods
One of the most common uses of kubectl run is spinning up temporary debug pods:
Common Pitfalls
- Assuming kubectl run creates Deployments: Since Kubernetes 1.18+,
kubectl runcreates only bare Pods. For Deployments, usekubectl create deployment. If you see old tutorials usingkubectl runfor deployments, they are outdated. - Bare Pods vs Deployments: Pods created by
kubectl runare not managed by a controller. If the pod crashes or the node fails, it is not restarted. Use Deployments for production workloads. - --restart flag confusion: In the old generator system,
--restart=Neverselected the Job generator. Now it just sets the pod's restart policy.kubectl run --restart=Nevercreates a pod that runs once and stops. - --replicas removed:
kubectl run --replicas=3no longer works. Usekubectl create deployment --replicas=3instead. - API version changes: Old tutorials may reference
apps/v1beta1orextensions/v1beta1. These API versions were removed. Modern Kubernetes usesapps/v1for Deployments andbatch/v1for Jobs.
Summary
kubectl runnow creates only Pods — all generators were removed in Kubernetes 1.21- Use
kubectl create deploymentfor Deployments,kubectl create jobfor Jobs,kubectl create cronjobfor CronJobs - Use
--dry-run=client -o yamlto generate manifest files without creating resources kubectl run --rm -itis ideal for temporary debug pods- Bare Pods are not rescheduled on failure — always use controllers (Deployment, Job) for production workloads
Related reading
- What is the default memory allocated for a pod
- What is the difference between a Kubernetes Controller and a Kubernetes Operator?
- What is the difference between a pod and a deployment?
- What is the difference between a resourceVersion and a generation?
- What is the difference between a volume and persistent volume?
- What is the difference between always and on failure for Kubernetes restart policy?
- What is the difference between docker-compose up and docker-compose start?
- What is the difference between Docker Swarm and Kubernetes/Mesophere?

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.