kubectl Usage Conventions
Recommended usage conventions for
kubectl in Reusable Scripts
For a stable output in a script:
- Request one of the machine-oriented output forms, such as
-o go-template, or
- 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.
- You can use the
--subresourcealpha flag for kubectl commands like
replaceto fetch and update subresources for all resources that support them. Currently, only the
scalesubresources are supported.
- The API contract against a subresource is identical to a full resource. While updating the
statussubresource to a new value, keep in mind that the subresource could be potentially reconciled by a controller to a different value.
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
r03062016-1-4, rather than
:latest(For more information, see Best Practices for Configuration).
- 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
You can use the
--dry-run=client flag to preview the object that would be sent to your cluster, without really submitting it.
- You can use
kubectl applyto create or update resources. For more information about using kubectl apply to update resources, see Kubectl Book.
Last modified November 04, 2022 at 11:37 AM PST: Updates page weights in reference docs section (98f310ab58)