Reference Documentation

Design docs, concept definitions, and references for APIs and CLIs.

Edit This Page

Using kubectl in Reusable Scripts

If you need stable output in a script, you should:

Best Practices

kubectl run

In order for kubectl run to satisfy infrastructure as code:


kubectl run allows you to generate the following resources (using --generator flag):

Additionally, if you didn’t specify a generator flag, other flags will suggest using a specific generator. Below table shows which flags force using specific generators, depending on your cluster version:

Generated Resource Cluster v1.4 Cluster v1.3 Cluster v1.2 Cluster v1.1 and eariler
Pod --restart=Never --restart=Never --generator=run-pod/v1 --restart=OnFailure OR --restart=Never
Replication Controller --generator=run/v1 --generator=run/v1 --generator=run/v1 --restart=Always
Deployment --restart=Always --restart=Always --restart=Always N/A
Job --restart=OnFailure --restart=OnFailure --restart=OnFailure OR --restart=Never N/A
Scheduled Job --schedule=<cron> N/A N/A N/A

Note that these flags will use a default generator only when you have not specified any flag. This also means that combining --generator with other flags won’t change the generator you specified. For example, in a 1.4 cluster, if you specify --restart=Always, a Deployment will be created; if you specify --restart=Always and --generator=run/v1, a Replication Controller will be created instead. This becomes handy if you want to pin to a specific behavior with the generator, even when the defaulted generator is changed in the future.

Finally, the order in which flags set the generator is: schedule flag has the highest priority, then restart policy and finally the generator itself.

If in doubt about the final resource being created, you can always use --dry-run flag, which will provide the object to be submitted to the cluster.

kubectl apply


Create Issue Edit This Page