kubectlin Reusable Scripts
If you need stable output in a script, you should:
-o go-template, or
--output-version, since those output forms (other than
-o name) output the resource using a particular API version
--generatorto pin to a specific behavior forever, if using generator-based commands (such as
In order for
kubectl run to satisfy infrastructure as code:
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 runflags, switch to configuration files checked into source control.
kubectl run --generator=deployment/v1beta1
kubectl run allows you to generate the following resources (using
extension/v1beta1endpoint) - use
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|
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
--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
flag, which will provide the object to be submitted to the cluster.
kubectl applyto update resources, always create resources initially with
kubectl applyor with
--save-config. See managing resources with kubectl apply for the reason behind it.