As the author of the problem let me explain a little bit the intention behind this deprecation. Just like Brendan explains in his answer,

kubectl run

per se is not being deprecated, only all the generators, except for the one that creates a Pod for you.

The reason for this change is two folds:

1. The vast majority of input parameters for

   kubectl run

   command is overwhelming for newcomers, as well as for the old timers. It's not that easy to figure out what will be the result of your invocation. You need to take into consideration several passed options as well as the server version.

2. The code behind it is also a mess to maintain given the matrix of possibilities is growing faster than we can handle.

That's why we're trying to move people away from using

kubectl run

for their daily workflows and convince them that using explicit

kubectl create

commands is more straightforward. Finally, we want to make the newcomers that played with docker or any other container engine, where they run a container, to have the same experience with Kubernetes where

kubectl run

will just run a Pod in a cluster.

Sorry for the initial confusion and I hope this will clear things up.

UPDATE (2020/01/10): As of https://github.com/kubernetes/kubernetes/pull/87077

kubectl run

will ONLY create Pods. All generators will be removed entirely.

you can use:

kubectl run --generator=run-pod/v1 --image=busybox busybox --dry-run --env=foo=bar

Which isn't being deprecated.

kubectl run

by default, will create a Deployment.

The command in its full extend is:

kubectl run --generator=deployment/apps.v1 <deployment_name> --image=<image_to_use_in_the_container_of_the_deployment's_pod>

So the

kubernetes

resource that will be created upon execution of the

run

command is defined by the value of the

--generator

flag.

What the deprecation message hints (and is also clarified by the answer provided by @soltysh) is that the particular practice will be removed.

So in future

kubernetes

versions, the

run

command will by default (and as only option) create pods (and not deployments), i.e. the command in its full extend will become:

kubectl run --generator=run-pod/v1 <pod_name> --image=<image_of_the_container_of_the_pod>

In case you want to create any other

kubernetes

resource type, this will be impossible via

run

command so you will have to resort to explicit imperative

create

or declarative

apply -f

, the later pointing to

kubernetes

yml

files with the corresponding resource defintition, as in

kubernetes apply -f <yaml_file_with_my_deployment.yml>

I noticed that running the following command WITHOUT specifying the generator parameter:

kubectl run <name> --image=<image>

It returns this error:

kubectl run --generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run --generator=run-pod/v1 or kubectl create instead.

What's very confusing about this message is that you never specified the --generator parameter in the first place. However the main point here is to explicitly specify the generator as directed by the error message as follows:

kubectl run --generator=run-pod/v1 <name> --image=<image>

Then it should run successfully. (they should have just defaulted the generator to run-pod/v1 to avoid this confusion and/or just encouraged the use of create).

However, based on @soltysh answer, it sounds as if they are now recommending 'create' over 'run.'

To run a pod, this simple command is enough:

kubectl run --restart=Never <name> --image=<image>

Check https://www.k8s-school.fr/resources/blog/1-kubectl-run-deprecated/#pod for additional informations.

When you run

kubectl run <name> --image=<image> --port=<port>

You are implicitly running

kubectl run --generator=deployment/apps.v1 run <name> --image=<image> --port=<port>

Which tells kubernetes what resource it needs to generate

It is quite overwhelming to deal with such a variety of parameters with

run

Hence, as of v1.15 and greater, all --generators apart from run-pod are deprecated.

See the table below

Pod	                                v1	                kubectl run --generator=run-pod/v1
ReplicationController (deprecated)	v1	                kubectl run --generator=run/v1
Deployment (deprecated)	        extensions/v1beta1	    kubectl run --generator=deployment/v1beta1
Deployment (deprecated)	        apps/v1beta1	        kubectl run --generator=deployment/apps.v1beta1
Job (deprecated)	            batch/v1	            kubectl run --generator=job/v1
CronJob (deprecated)	        batch/v2alpha1	        kubectl run --generator=cronjob/v2alpha1
CronJob (deprecated)	        batch/v1beta1       	kubectl run --generator=cronjob/v1beta1

Solution is to either use

create

or

apply -f

. The latter uses a yml file.

If your problem is doing some kubectl exercises following an old book, you can use a deprecated kubectl client to run the kubectl run command and the regular one to the others.

The kubectl 1.17 support the run argument.

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.17.md#client-binaries

Like the message said, you should use

kubectl create

. Just define a minimal pod yaml definition and use

kubectl create -f mypod.yml

As stated in many answers...

run

is just for pod creation. In the questioners context (temporary containers(ie. pod) for debugging reasons) this command is perfectly fine.

Just run the pod and

--expose

it; put some

--env

variables; jump in with a

--tty

and maybe

--rm

after you're done.

In this case

run

is not deprecated, in all other cases like deployment, DaemonSet, StatefulSet, etc. it is - for a good reason - it is too imperativish!