Imperative Management of Kubernetes Objects Using Configuration Files

    Install kubectl.

    You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. It is recommended to run this tutorial on a cluster with at least two nodes that are not acting as control plane hosts. If you do not already have a cluster, you can create one by using or you can use one of these Kubernetes playgrounds:

    To check the version, enter kubectl version.

    Trade-offs

    The kubectl tool supports three kinds of object management:

    • Imperative commands
    • Imperative object configuration
    • Declarative object configuration

    See for a discussion of the advantages and disadvantage of each kind of object management.

    How to create objects

    You can use kubectl create -f to create an object from a configuration file. Refer to the for details.

    • kubectl create -f <filename|url>

    Warning: Updating objects with the replace command drops all parts of the spec not specified in the configuration file. This should not be used with objects whose specs are partially managed by the cluster, such as Services of type LoadBalancer, where the externalIPs field is managed independently from the configuration file. Independently managed fields must be copied to the configuration file to prevent replace from dropping them.

    • kubectl replace -f <filename|url>

    How to delete objects

    You can use kubectl delete -f to delete an object that is described in a configuration file.

    • kubectl delete -f <filename|url>

    Note:

    If configuration file has specified the generateName field in the metadata section instead of the name field, you cannot delete the object using kubectl delete -f <filename|url>. You will have to use other flags for deleting the object. For example:

    How to view an object

    You can use kubectl get -f to view information about an object that is described in a configuration file.

    The -o yaml flag specifies that the full object configuration is printed. Use kubectl get -h to see a list of options.

    The create, replace, and delete commands work well when each object’s configuration is fully defined and recorded in its configuration file. However when a live object is updated, and the updates are not merged into its configuration file, the updates will be lost the next time a replace is executed. This can happen if a controller, such as a HorizontalPodAutoscaler, makes updates directly to a live object. Here’s an example:

    1. You create an object from a configuration file.
    2. Another source updates the object by changing some field.
    3. You replace the object from the configuration file. Changes made by the other source in step 2 are lost.

    If you need to support multiple writers to the same object, you can use kubectl apply to manage the object.

    Creating and editing an object from a URL without saving the configuration

    Migrating from imperative commands to imperative object configuration

    Migrating from imperative commands to imperative object configuration involves several manual steps.

    1. Export the live object to a local object configuration file:

    2. Manually remove the status field from the object configuration file.

    3. For subsequent object management, use exclusively.

    Warning: Updating selectors on controllers is strongly discouraged.

    The recommended approach is to define a single, immutable PodTemplate label used only by the controller selector with no other semantic meaning.

    Example label:

    What’s next