You describe a _desired state_ in a Deployment object, and the Deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.

{{< note >}}

**Note:**You should not manage ReplicaSets owned by a Deployment. All the use cases should be covered by manipulating the Deployment object. Consider opening an issue in the main Kubernetes repository if your use case is not covered below.

You should not manage ReplicaSets owned by a Deployment. All the use cases should be covered by manipulating the Deployment object. Consider opening an issue in the main Kubernetes repository if your use case is not covered below.

{{< /note >}}

{{% /capture %}}

@@ -57,7 +57,7 @@ In this example:

as long as the Pod template itself satisfies the rule.

{{< note >}}

**Note:**`matchLabels` is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map

`matchLabels` is a map of {key,value} pairs. A single {key,value} in the `matchLabels` map

is equivalent to an element of `matchExpressions`, whose key field is "key", the operator is "In",

and the values array contains only "value". The requirements are ANDed.

**Note:**You may specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`. It is useful for future instrospection, for example to see the commands executed in each Deployment revision.

You may specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`. It is useful for future instrospection, for example to see the commands executed in each Deployment revision.

{{< /note >}}

Next, run `kubectl get deployments`. The output is similar to the following:

The created ReplicaSet ensures that there are three `nginx` Pods running at all times.

{{< note >}}

**Note:**You must specify an appropriate selector and Pod template labels in a Deployment (in this case,

You must specify an appropriate selector and Pod template labels in a Deployment (in this case,

`app: nginx`). Do not overlap labels or selectors with other controllers (including other Deployments and StatefulSets). Kubernetes doesn't stop you from overlapping, and if multiple controllers have overlapping selectors those controllers might conflict and behave unexpectedly.

{{< /note >}}

###Pod-template-hash label

{{< note >}}

**Note:**Do not change this label.

Do not change this label.

{{< /note >}}

The `pod-template-hash` label is added by the Deployment controller to every ReplicaSet that a Deployment creates or adopts.

@@ -163,7 +163,7 @@ and in any existing Pods that the ReplicaSet might have.

##Updating a Deployment

{{< note >}}

**Note:**A Deployment's rollout is triggered if and only if the Deployment's pod template (that is, `.spec.template`)

A Deployment's rollout is triggered if and only if the Deployment's pod template (that is, `.spec.template`)

is changed, for example if the labels or container images of the template are updated. Other updates, such as scaling the Deployment, do not trigger a rollout.

{{< /note >}}

@@ -307,7 +307,7 @@ In any case, if you need to perform a label selector update, exercise great caut

all of the implications.

{{< note >}}

**Note:**In API version `apps/v1`, a Deployment's label selector is immutable after it gets created.

In API version `apps/v1`, a Deployment's label selector is immutable after it gets created.

{{< /note >}}

* Selector additions require the pod template labels in the Deployment spec to be updated with the new label too,

@@ -326,7 +326,7 @@ By default, all of the Deployment's rollout history is kept in the system so tha

(you can change that by modifying revision history limit).

{{< note >}}

**Note:**A Deployment's revision is created when a Deployment's rollout is triggered. This means that the

A Deployment's revision is created when a Deployment's rollout is triggered. This means that the

new revision is created if and only if the Deployment's pod template (`.spec.template`) is changed,

for example if you update the labels or container images of the template. Other updates, such as scaling the Deployment,

do not create a Deployment revision, so that you can facilitate simultaneous manual- or auto-scaling.