|
|
|
@@ -14,7 +14,7 @@ A _Deployment_ controller provides declarative updates for [Pods](/docs/concepts
|
|
|
|
|
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 %}}
|
|
|
|
@@ -103,7 +103,7 @@ nginx-deployment-2035384211-qqcnn 1/1 Running 0 18s app
|
|
|
|
|
The created ReplicaSet ensures that there are three nginx Pods 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`). That is, don't overlap with other controllers (including other Deployments, ReplicaSets,
|
|
|
|
|
StatefulSets, etc.). Kubernetes doesn't stop you from overlapping, and if multiple
|
|
|
|
|
controllers have overlapping selectors, those controllers may fight with each other and won't behave
|
|
|
|
@@ -113,7 +113,7 @@ correctly.
|
|
|
|
|
### Pod-template-hash label
|
|
|
|
|
|
|
|
|
|
{{< note >}}
|
|
|
|
|
**Note:** Do not change this label.
|
|
|
|
|
Do not change this label.
|
|
|
|
|
{{< /note >}}
|
|
|
|
|
|
|
|
|
|
Note the pod-template-hash label in the example output in the pod labels above. This label is added by the
|
|
|
|
@@ -125,7 +125,7 @@ and in any existing Pods that the ReplicaSet may 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 >}}
|
|
|
|
|
|
|
|
|
@@ -270,7 +270,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 we can facilitate simultaneous manual- or auto-scaling.
|
|
|
|
@@ -318,7 +318,7 @@ nginx-deployment-3066724191-eocby 0/1 ImagePullBackOff 0 6s
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
{{< note >}}
|
|
|
|
|
**Note:** The Deployment controller will stop the bad rollout automatically, and will stop scaling up the new
|
|
|
|
|
The Deployment controller will stop the bad rollout automatically, and will stop scaling up the new
|
|
|
|
|
ReplicaSet. This depends on the rollingUpdate parameters (`maxUnavailable` specifically) that you have specified.
|
|
|
|
|
Kubernetes by default sets the value to 1 and spec.replicas to 1 so if you haven't cared about setting those
|
|
|
|
|
parameters, your Deployment can have 100% unavailability by default! This will be fixed in Kubernetes in a future
|
|
|
|
@@ -596,7 +596,7 @@ nginx-3926361531 3 3 3 28s
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
{{< note >}}
|
|
|
|
|
**Note:** You cannot rollback a paused Deployment until you resume it.
|
|
|
|
|
You cannot rollback a paused Deployment until you resume it.
|
|
|
|
|
{{< /note >}}
|
|
|
|
|
|
|
|
|
|
## Deployment status
|
|
|
|
@@ -669,13 +669,13 @@ attributes to the Deployment's `status.conditions`:
|
|
|
|
|
See the [Kubernetes API conventions](https://git.k8s.io/community/contributors/devel/api-conventions.md#typical-status-properties) for more information on status conditions.
|
|
|
|
|
|
|
|
|
|
{{< note >}}
|
|
|
|
|
**Note:** Kubernetes will take no action on a stalled Deployment other than to report a status condition with
|
|
|
|
|
Kubernetes will take no action on a stalled Deployment other than to report a status condition with
|
|
|
|
|
`Reason=ProgressDeadlineExceeded`. Higher level orchestrators can take advantage of it and act accordingly, for
|
|
|
|
|
example, rollback the Deployment to its previous version.
|
|
|
|
|
{{< /note >}}
|
|
|
|
|
|
|
|
|
|
{{< note >}}
|
|
|
|
|
**Note:** If you pause a Deployment, Kubernetes does not check progress against your specified deadline. You can
|
|
|
|
|
If you pause a Deployment, Kubernetes does not check progress against your specified deadline. You can
|
|
|
|
|
safely pause a Deployment in the middle of a rollout and resume without triggering the condition for exceeding the
|
|
|
|
|
deadline.
|
|
|
|
|
{{< /note >}}
|
|
|
|
@@ -780,7 +780,7 @@ this Deployment you want to retain. The rest will be garbage-collected in the ba
|
|
|
|
|
all revision history will be kept. In a future version, it will default to switch to 2.
|
|
|
|
|
|
|
|
|
|
{{< note >}}
|
|
|
|
|
**Note:** Explicitly setting this field to 0, will result in cleaning up all the history of your Deployment
|
|
|
|
|
Explicitly setting this field to 0, will result in cleaning up all the history of your Deployment
|
|
|
|
|
thus that Deployment will not be able to roll back.
|
|
|
|
|
{{< /note >}}
|
|
|
|
|
|
|
|
|
@@ -831,7 +831,7 @@ from `.spec.template` or if the total number of such Pods exceeds `.spec.replica
|
|
|
|
|
Pods with `.spec.template` if the number of Pods is less than the desired number.
|
|
|
|
|
|
|
|
|
|
{{< note >}}
|
|
|
|
|
**Note:** You should not create other pods whose labels match this selector, either directly, by creating
|
|
|
|
|
You should not create other pods whose labels match this selector, either directly, by creating
|
|
|
|
|
another Deployment, or by creating another controller such as a ReplicaSet or a ReplicationController. If you
|
|
|
|
|
do so, the first Deployment thinks that it created these other pods. Kubernetes does not stop you from doing this.
|
|
|
|
|
{{< /note >}}
|
|
|
|
|
Rui Chen