52

I'm using kubectl run with environment parameters to create temporary docker containers for me (e.g. some forwarding for debugging purposes). Since several weeks kubectl is complaining about kubectl run being deprecated. Unfortunately I can't find an appropriate replacement.

This is the old command:

$KUBECTL run -i -t --attach=false --image djfaze/port-forward --env="REMOTE_HOST=$REMOTE_HOST" --env="REMOTE_PORT=$REMOTE_PORT" $POD_NAME

When issuing this, kubectl complains with this message:

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

Any ideas how to replace this run command?

BartoszKP
  • 34,786
  • 15
  • 102
  • 130
peez80
  • 1,583
  • 2
  • 15
  • 32
  • 1
    If you ended here from following the kubernetes in action book, you might find this addition helpful: https://medium.com/@marko.luksa/kubernetes-in-action-introducing-replication-controllers-aaa2c05e0b4e Using the yaml file + create action to create a replication controller instead. – Marius Pop May 19 '20 at 13:05

8 Answers8

69

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.

soltysh
  • 1,464
  • 12
  • 23
  • 3
    It would make more sense to translate the `kubectl run` command in question to `kubectl create` command without using an external json/yaml file. Mind doing that as part of your answer? – karthiks Feb 04 '19 at 07:21
  • I'm not sure I understand your request. Basically you can use any `kubectl create` sub-commands instead of using json/yaml files. I'm not mentioning any particular since we don't cover all resources, yet, but at least the main ones. – soltysh Feb 05 '19 at 08:42
  • Unfortunately the documentation is flooded with examples of 'kubectl run..' – jersey bean Sep 12 '19 at 23:01
  • 2
    But there does not seem to be `kubectl create pod`? – Andrew Savinykh Dec 22 '19 at 23:24
  • 3
    I think what @karthiks is saying is the question asks how to replace the run command with one that has the same effect, but does not generate a deprecation warning. Sure, I get we're supposed to "use kubectl create", but can you show us how exactly with an example, instead of just explaining why there is a warning? I suspect most of us don't really care why it's being replaced, just want to know how to do what you want us to do now. – deed02392 Mar 18 '20 at 09:45
  • 1
    I hope this answers your question, in short if you run `kubectl create -h` you'll get a list of possible sub-commands which allow creating the following resources: clusterrole, clusterrolebinding, configmap, cronjob, deployment, job, namespace, poddisruptionbudget, priorityclass, quota, role, rolebinding, secret, service, serviceaccount. Running `kubectl create job -h`, for example, should give you sample usage of the command. – soltysh Mar 22 '20 at 11:23
  • I found the kubectl run very useful in atleast creating a base yaml config which I can further edit as per my requirement . If maintainability is an issue then I think the better option is not to make it "deprecated" instead just stop adding further features/arguments on the "kubernetes run" command. – Abdul Mohsin Aug 26 '21 at 02:04
  • how can we use the serviceaccount, looks like that flag is deprecated, how can i pass the serviceaccount when using kubectl run – user_01_02 Mar 02 '22 at 00:27
20

you can use:

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

Which isn't being deprecated.

Brendan Burns
  • 724
  • 3
  • 3
  • 1
    All of the generators other than for pod is deprecate as per v1.15. See https://kubernetes.io/docs/reference/kubectl/conventions/ – Ryan Aug 16 '19 at 08:08
16

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>
pkaramol
  • 16,451
  • 43
  • 149
  • 324
8

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

jersey bean
  • 3,321
  • 4
  • 28
  • 43
3

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.

Fabrice Jammes
  • 2,275
  • 1
  • 26
  • 39
3

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.

kooskoos
  • 4,622
  • 1
  • 12
  • 29
0

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

Fabrício Ceolin
  • 456
  • 5
  • 7
-1

Like the message said, you should use kubectl create . Just define a minimal pod yaml definition and use kubectl create -f mypod.yml

Nicolas Pepinster
  • 5,413
  • 2
  • 30
  • 48
  • 1
    That's not quite accurate, `kubectl create` has several sub-commands which allow you to create resources **without** writing yaml, there's no pod creation, but that part of `kubectl run` is **not being** deprecated. – soltysh Oct 28 '18 at 06:16