Update deployments.md
This commit is contained in:
@@ -478,8 +478,7 @@ equals or exceeds the number required by the Deployment strategy.
|
|||||||
* All of the replicas associated with the Deployment have been updated to the latest version you've specified, meaning any
|
* All of the replicas associated with the Deployment have been updated to the latest version you've specified, meaning any
|
||||||
updates you've requested have been completed.
|
updates you've requested have been completed.
|
||||||
|
|
||||||
You can check if a Deployment has completed by using `kubectl rollout status`. Zero exit code will be returned
|
You can check if a Deployment has completed by using `kubectl rollout status`. If the rollout completed successfully, `kubectl rollout status` returns a zero exit code.
|
||||||
in case it has completed successfully.
|
|
||||||
|
|
||||||
```
|
```
|
||||||
$ kubectl rollout status deploy/nginx
|
$ kubectl rollout status deploy/nginx
|
||||||
@@ -500,9 +499,7 @@ Your Deployment may get stuck trying to deploy its newest ReplicaSet without eve
|
|||||||
* Limit ranges
|
* Limit ranges
|
||||||
* Application runtime misconfiguration
|
* Application runtime misconfiguration
|
||||||
|
|
||||||
For any Pod creation or deletion failure, you will be notified with a Deployment status condition of `ReplicaFailure`
|
One way you can detect this condition is to specify specify a deadline parameter in your Deployment spec: ([`spec.progressDeadlineSeconds`](#progress-deadline-seconds)). `spec.progressDeadlineSeconds` denotes the number of seconds the Deployment controller waits before indicating (via the Deployment status) that the Deployment progress has stalled.
|
||||||
type. You can also specify a deadline parameter in the spec ([spec.progressDeadlineSeconds](#progress-deadline-seconds))
|
|
||||||
that denotes the number of seconds to wait for your Deployment to report any progress.
|
|
||||||
|
|
||||||
The following `kubectl` command sets the spec with `progressDeadlineSeconds` to make the controller report lack of progress for a Deployment after 10 minutes:
|
The following `kubectl` command sets the spec with `progressDeadlineSeconds` to make the controller report lack of progress for a Deployment after 10 minutes:
|
||||||
|
|
||||||
@@ -510,9 +507,8 @@ The following `kubectl` command sets the spec with `progressDeadlineSeconds` to
|
|||||||
$ kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
|
$ kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
|
||||||
"nginx-deployment" patched
|
"nginx-deployment" patched
|
||||||
```
|
```
|
||||||
|
|
||||||
Once the deadline has been exceeded, the Deployment controller adds a DeploymentCondition with the following attributes to
|
Once the deadline has been exceeded, the Deployment controller adds a DeploymentCondition with the following attributes to
|
||||||
the Deployment's status.conditions:
|
the Deployment's `status.conditions`:
|
||||||
|
|
||||||
* Type=Progressing
|
* Type=Progressing
|
||||||
* Status=False
|
* Status=False
|
||||||
@@ -523,6 +519,8 @@ See the [Kubernetes API conventions](https://github.com/kubernetes/kubernetes/bl
|
|||||||
Note that in version 1.5, Kubernetes will take no action on a stalled Deployment other than to report a status condition with
|
Note that in version 1.5, Kubernetes will take no action on a stalled Deployment other than to report a status condition with
|
||||||
`Reason=ProgressDeadlineExceeded`.
|
`Reason=ProgressDeadlineExceeded`.
|
||||||
|
|
||||||
|
**Note:** 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 a the condition for exceeding the deadline.
|
||||||
|
|
||||||
You may experience transient errors with your Deployments, either due to a low timeout that you have set or due to any other kind
|
You may experience transient errors with your Deployments, either due to a low timeout that you have set or due to any other kind
|
||||||
of error that can be treated as transient. For example, let's suppose you have insufficient quota. If you describe the Deployment
|
of error that can be treated as transient. For example, let's suppose you have insufficient quota. If you describe the Deployment
|
||||||
you will notice the following section:
|
you will notice the following section:
|
||||||
@@ -598,8 +596,7 @@ is either in the middle of a rollout and it is progressing or that it has succes
|
|||||||
required new replicas are available (see the Reason of the condition for the particulars - in our case
|
required new replicas are available (see the Reason of the condition for the particulars - in our case
|
||||||
`Reason=NewReplicaSetAvailable` means that the Deployment is complete).
|
`Reason=NewReplicaSetAvailable` means that the Deployment is complete).
|
||||||
|
|
||||||
You can check if a Deployment has failed progressing by using `kubectl rollout status`. Non-zero exit code will be returned
|
You can check if a Deployment has failed to progress by using `kubectl rollout status`. `kubectl rollout status` returns a non-zero exit code if the Deployment has exceeded the progression deadline.
|
||||||
in case it has exceeded its deadline.
|
|
||||||
|
|
||||||
```
|
```
|
||||||
$ kubectl rollout status deploy/nginx
|
$ kubectl rollout status deploy/nginx
|
||||||
@@ -612,10 +609,7 @@ $ echo $?
|
|||||||
### Operating on a failed deployment
|
### Operating on a failed deployment
|
||||||
|
|
||||||
All actions that apply to a complete Deployment also apply to a failed Deployment. You can scale it up/down, roll back
|
All actions that apply to a complete Deployment also apply to a failed Deployment. You can scale it up/down, roll back
|
||||||
to a previous revision, or even pause it if you need to apply multiple tweaks in the Deployment pod template. Note
|
to a previous revision, or even pause it if you need to apply multiple tweaks in the Deployment pod template.
|
||||||
that progress for a Deployment is not estimated while the Deployment is paused so you can safely pause a Deployment
|
|
||||||
in the middle of a rollout and resume it whenever you want without it failing accidentally because of an exceeded
|
|
||||||
deadline.
|
|
||||||
|
|
||||||
## Use Cases
|
## Use Cases
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user