Kubernetes Object Management [page]deterministic
The `kubectl` command-line tool supports several different ways to create and manage Kubernetes [objects](#gloss:object). This document provides an overview of the different approaches. Read the [Kubectl book](https://kubectl.docs.kubernetes.io) for details of managing objects by Kubectl.
## Management techniques
> Warning: A Kubernetes object should be managed using only one technique. Mixing and matching techniques for the same object results in undefined behavior.
| Management technique | Operates on |Recommended environment | Supported writers | Learning curve | |----------------------------------|----------------------|------------------------|--------------------|----------------| | Imperative commands | Live objects | Development projects | 1+ | Lowest | | Imperative object configuration | Individual files | Production projects | 1 | Moderate | | Declarative object configuration | Directories of files | Production projects | 1+ | Highest |
## Imperative commands
When using imperative commands, a user operates directly on live objects in a cluster. The user provides operations to the `kubectl` command as arguments or flags.
This is the recommended way to get started or to run a one-off task in a cluster. Because this technique operates directly on live objects, it provides no history of previous configurations.
### Examples
Run an instance of the nginx container by creating a Deployment object:
```sh kubectl create deployment nginx --image nginx ```
### Trade-offs
Advantages compared to object configuration:
- Commands are expressed as a single action word.
- Commands require only a single step to make changes to the cluster.
Disadvantages compared to object configuration:
- Commands do not integrate with change review processes.
- Commands do not provide an audit trail associated with changes.
- Commands do not provide a source of records except for what is live.
- Commands do not provide a template for creating new objects.
## Imperative object configuration
In imperative object configuration, the kubectl command specifies the operation (create, replace, etc.), optional flags and at least one file name. The file specified must contain a full definition of the object in YAML or JSON format.
See the [API reference](/docs/reference/generated/kubernetes-api//) for more details on object definitions.
> Warning: The imperative `replace` command replaces the existing spec with the newly provided one, dropping all changes to the object missing from the configuration file. This approach should not be used with resource types whose specs are updated independently of the configuration file. Services of type `LoadBalancer`, for example, have their `externalIPs` field updated independently from the configuration by the cluster.
### Examples
Create the objects defined in a configuration file:
```sh kubectl create -f nginx.yaml ```
Delete the objects defined in two configuration files:
```sh kubectl delete -f nginx.yaml -f redis.yaml ```
Update the objects defined in a configuration file by overwriting the live configuration:
```sh kubectl replace -f nginx.yaml ```
### Trade-offs
Advantages compared to imperative commands:
- Object configuration can be stored in a source control system such as Git.
- Object configuration can integrate with processes such as reviewing changes before push and audit trails.
- Object configuration provides a template for creating new objects.
Disadvantages compared to imperative commands:
- Object configuration requires basic understanding of the object schema.
- Object configuration requires the additional step of writing a YAML file.
Advantages compared to declarative object configuration:
- Imperative object configuration behavior is simpler and easier to understand.
- As of Kubernetes version 1.5, imperative object configuration …(trimmed)