kubectl
in Reusable ScriptsIf you need stable output in a script, you should:
-o name
, -o json
, -o yaml
, -o go-template
, or -o jsonpath
--output-version
, since those output forms (other than -o name
) output the resource using a particular API version--generator
to pin to a specific behavior forever, if using generator-based commands (such as kubectl run
or kubectl expose
)kubectl run
In order for kubectl run
to satisfy infrastructure as code:
:v1234
, v1.2.3
, r03062016-1-4
, rather than :latest
(see Best Practices for Configuration for more information.)--record
, to annotate the created objects with the command line.kubectl run
flags, switch to configuration files checked into source control.kubectl run --generator=deployment/v1beta1
kubectl run
allows you to generate the following resources (using --generator
flag):
run-pod/v1
.run/v1
.extensions/v1beta1
endpoint - use deployment/v1beta1
(default).apps/v1beta1
endpoint - use deployment/apps.v1beta1
(recommended).job/v1
.cronjob/v2alpha1
.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 and later | 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 |
Cron 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
kubectl apply
to update resources, always create resources initially with kubectl apply
or with --save-config
. See managing resources with kubectl apply for the reason behind it.