website/docs/tutorials/object-management-kubectl/object-management.md

178 lines
6.5 KiB
Markdown
Raw Normal View History

2017-01-17 20:57:19 +00:00
---
2017-01-20 21:54:12 +00:00
title: Kubernetes Object Management
2017-01-17 20:57:19 +00:00
---
{% capture overview %}
2017-01-20 21:54:12 +00:00
The `kubectl` command-line tool supports several different ways to create and manage
Kubernetes objects. This document provides an overview of the different
2017-01-17 20:57:19 +00:00
approaches.
{% endcapture %}
{% capture body %}
2017-01-20 21:54:12 +00:00
## Management techniques
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
**Warning:** A Kubernetes object should be managed using only one technique. Mixing
2017-01-17 20:57:19 +00:00
and matching techniques for the same object results in undefined behavior.
2017-01-20 21:54:12 +00:00
| Management technique | Operates on |Recommended environment | Supported writers | Learning curve |
2017-01-17 20:57:19 +00:00
|----------------------------------|----------------------|------------------------|--------------------|----------------|
2017-01-20 21:54:12 +00:00
| 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 |
2017-01-17 20:57:19 +00:00
## Imperative commands
When using imperative commands, a user operates directly on live objects
2017-01-20 21:54:12 +00:00
in a cluster. The user provides operations to
the `kubectl` command as arguments or flags.
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
This is the simplest way to get started or to run a one-off task in
a cluster. Because this technique operates directly on live
2017-01-17 20:57:19 +00:00
objects, it provides no history of previous configurations.
2017-01-20 21:54:12 +00:00
### Examples
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
Run an instance of the nginx container by creating a Deployment object:
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
```sh
kubectl run nginx --image nginx
```
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
Do the same thing using a different syntax:
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
```sh
kubectl create deployment nginx --image nginx
```
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
### Trade-offs
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
Advantages compared to object configuration:
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
- Commands are simple, easy to learn and easy to remember.
- Commands require only a single step to make changes to the cluster.
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
Disadvantages compared to object configuration:
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
- 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.
2017-01-17 20:57:19 +00:00
## 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 [resource reference](https://kubernetes.io/docs/resources-reference/{{page.version}}/)
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.
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
### Examples
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
Create the objects defined in a configuration file:
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
```sh
kubectl create -f nginx.yaml
```
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
Delete the objects defined in two configuration files:
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
```sh
kubectl delete -f nginx.yaml -f redis.yaml
```
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
Update the objects defined in a configuration file by overwriting
the live configuration:
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
```sh
kubectl replace -f nginx.yaml
```
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
### Trade-offs
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
Advantages compared to imperative commands:
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
- 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.
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
Disadvantages compared to imperative commands:
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
- Object configuration requires basic understanding of the object schema.
- Object configuration requires the additional step of writing a YAML file.
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
Advantages compared to declarative object configuration:
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
- Imperative object configuration behavior is simpler and easier to understand.
- As of Kubernetes version 1.5, imperative object configuration is more mature.
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
Disadvantages compared to declarative object configuration:
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
- Imperative object configuration works best on files, not directories.
- Updates to live objects must be reflected in configuration files, or they will be lost during the next replacement.
2017-01-17 20:57:19 +00:00
## Declarative object configuration
When using declarative object configuration, a user operates on object
2017-01-20 21:54:12 +00:00
configuration files stored locally, however the user does not define the
operations to be taken on the files. Create, update, and delete operations
are automatically detected per-object by `kubectl`. This enables working on
directories, where different operations might be needed for different objects.
2017-01-17 20:57:19 +00:00
**Note:** Declarative object configuration retains changes made by other
writers, even if the changes are not merged back to the object configuration file.
2017-01-20 21:54:12 +00:00
This is possible by using the `patch` API operation to write only
observed differences, instead of using the `replace`
2017-01-17 20:57:19 +00:00
API operation to replace the entire object configuration.
2017-01-20 21:54:12 +00:00
### Examples
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
Process all object configuration files in the `configs` directory, and
create or patch the live objects:
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
```sh
kubectl apply -f configs/
```
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
Recursively process directories:
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
```sh
kubectl apply -R -f configs/
```
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
### Trade-offs
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
Advantages compared to imperative object configuration:
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
- Changes made directly to live objects are retained, even if they are not merged back into the configuration files.
- Declarative object configuration has better support for operating on directories and automatically detecting operation types (create, patch, delete) per-object.
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
Disadvantages compared to imperative object configuration:
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
- Declarative object configuration is harder to debug and understand results when they are unexpected.
- Partial updates using diffs create complex merge and patch operations.
2017-01-17 20:57:19 +00:00
{% endcapture %}
{% capture whatsnext %}
- [Managing Kubernetes Objects Using Imperative Commands](/docs/tutorials/object-management-kubectl/imperative-object-management-command/)
- [Managing Kubernetes Objects Using Object Configuration (Imperative)](/docs/tutorials/object-management-kubectl/imperative-object-management-configuration/)
- [Managing Kubernetes Objects Using Object Configuration (Declarative)](/docs/tutorials/object-management-kubectl/declarative-object-management-configuration/)
- [Kubectl Command Reference](/docs/user-guide/kubectl/{{page.version}}/)
- [Kubernetes Object Schema Reference](/docs/resources-reference/{{page.version}}/)
2017-01-17 20:57:19 +00:00
2017-01-20 21:54:12 +00:00
{% comment %}
{% endcomment %}
2017-01-17 20:57:19 +00:00
{% endcapture %}
{% include templates/concept.md %}