kubectl Usage Conventions

    • Request one of the machine-oriented output forms, such as -o name, -o json, -o yaml, -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 --subresource alpha flag for kubectl commands like get, patch, edit and replace to fetch and update subresources for all resources that support them. Currently, only the status and scale subresources are supported.
    • 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).
    • 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 run flags.

    • You can use kubectl apply to create or update resources. For more information about using kubectl apply to update resources, see Kubectl Book.