kubectl Usage Conventions
Recommended usage conventions for kubectl.
Using kubectl in Reusable Scripts
For a stable output in a script:
- Request one of the machine-oriented output forms, such as
-o name,-o json,-o yaml,-o go-template, or-o jsonpath. - Fully-qualify the version. For example,
jobs.v1.batch/myjob. This will ensure that kubectl does not use its default version that can change over time. - Don’t rely on context, preferences, or other implicit states.
Best Practices
kubectl run
For kubectl run to satisfy infrastructure as code:
- Tag the image with a version-specific tag and don’t move that tag to a new version. For example, use
:v1234,v1.2.3,r03062016-1-4, rather than:latest(For more information, see Best Practices for Configuration). - Capture the parameters in a checked-in script, or at least use
--recordto annotate the created objects with the command line for an image that is lightly parameterized. - Check in the script for an image that is heavily parameterized.
- Switch to configuration files checked into source control for features that are needed, but not expressible via
kubectl runflags.
| Resource | api group | kubectl command |
|---|---|---|
| Pod | v1 | |
| Replication controller (deprecated) | v1 | |
| Deployment (deprecated) | extensions/v1beta1 | |
| Deployment (deprecated) | apps/v1beta1 | |
| Job (deprecated) | batch/v1 | |
| CronJob (deprecated) | batch/v1beta1 | |
| CronJob (deprecated) | batch/v2alpha1 |
| Generated Resource | Cluster v1.4 and later | Cluster v1.3 | Cluster v1.2 | Cluster v1.1 and earlier |
|---|---|---|---|---|
| Pod | --restart=Never |
--restart=Never |
--restart=OnFailure OR --restart=Never |
|
| Replication Controller | --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 |
--restart=Always, a Deployment is created; if you later specify--restart=Always
To check the final resource that was created, use the --dry-run
flag, which provides the object to be submitted to the cluster.
kubectl apply
- You can use
kubectl applyto create or update resources. For more information about using kubectl apply to update resources, see Kubectl Book.
Feedback
Was this page helpful?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.