github/kubernetes
1
0
Fork 0
mirror of https://github.com/k3s-io/kubernetes.git synced 2025-08-03 01:06:27 +00:00
Code Issues Projects Releases Wiki Activity

Merge pull request #18053 from amygdala/docs

Browse Source 
Polishing the Deployment doc
This commit is contained in:
Marek Grabowski 2015-12-03 09:25:21 +01:00
commit 80415f29f7
1 changed files with 75 additions and 64 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

137
docs/user-guide/deployments.md
View File

@ -38,7 +38,7 @@ Documentation for other releases can be found at
- [Deployments](#deployments) - [Deployments](#deployments)
- [What is a _Deployment_?](#what-is-a-deployment) - [What is a _Deployment_?](#what-is-a-deployment)
- [Enabling Deployments on kubernetes cluster](#enabling-deployments-on-kubernetes-cluster) - [Enabling Deployments on a Kubernetes cluster](#enabling-deployments-on-a-kubernetes-cluster)
- [Creating a Deployment](#creating-a-deployment) - [Creating a Deployment](#creating-a-deployment)
- [Updating a Deployment](#updating-a-deployment) - [Updating a Deployment](#updating-a-deployment)
- [Multiple Updates](#multiple-updates) - [Multiple Updates](#multiple-updates)
@ -60,22 +60,23 @@ Documentation for other releases can be found at
## What is a _Deployment_? ## What is a _Deployment_?
A _Deployment_ provides declarative update for Pods and ReplicationControllers. A _Deployment_ provides declarative updates for Pods and ReplicationControllers.
Users describe the desired state in deployment object and deployment Users describe the desired state in a Deployment object, and the deployment
controller changes the actual state to that at a controlled rate. controller changes the actual state to the desired state at a controlled rate.
Users can define deployments to create new resources, or replace existing ones Users can define Deployments to create new resources, or replace existing ones
by new ones. by new ones.
A typical use case is: A typical use case is:
* Create a deployment to bring up a replication controller and pods. * Create a Deployment to bring up a replication controller and pods.
* Later, update that deployment to recreate the pods (for ex: to use a new image). * Later, update that Deployment to recreate the pods (for example, to use a new image).
## Enabling Deployments on kubernetes cluster ## Enabling Deployments on a Kubernetes cluster
Deployments is part of the [`extensions` API Group](../api.md#api-groups) and is not enabled by default. Deployment objects are part of the [`extensions` API Group](../api.md#api-groups) and this feature
Set `--runtime-config=extensions/v1beta1/deployments=true` on API server to is not enabled by default.
Set `--runtime-config=extensions/v1beta1/deployments=true` on the API server to
enable it. enable it.
This can be achieved by exporting `ENABLE_DEPLOYMENTS=true` before running This can be achieved by exporting `KUBE_ENABLE_DEPLOYMENTS=true` before running the
`kube-up.sh` script on GCE. `kube-up.sh` script on GCE.
Note that Deployment objects effectively have [API version Note that Deployment objects effectively have [API version
@ -120,7 +121,13 @@ $ kubectl create -f docs/user-guide/nginx-deployment.yaml
deployment "nginx-deployment" created deployment "nginx-deployment" created
``` ```
Running a get immediately will give: Running
```console
$ kubectl get deployments
```
immediately will give:
```console ```console
$ kubectl get deployments $ kubectl get deployments
@ -128,10 +135,9 @@ NAME UPDATEDREPLICAS AGE
nginx-deployment 0/3 8s nginx-deployment 0/3 8s
``` ```
This indicates that deployment is trying to update 3 replicas. It has not This indicates that the Deployment is trying to update 3 replicas, and has not updated any of them yet.
updated any one of those yet.
Running a get again after a minute, will give: Running the `get` again after a minute, should give:
```console ```console
$ kubectl get deployments $ kubectl get deployments
@ -139,7 +145,7 @@ NAME UPDATEDREPLICAS AGE
nginx-deployment 3/3 1m nginx-deployment 3/3 1m
``` ```
This indicates that deployent has created all the 3 replicas. This indicates that the Deployment has created all three replicas.
Running ```kubectl get rc``` and ```kubectl get pods``` will show the replication controller (RC) and pods created. Running ```kubectl get rc``` and ```kubectl get pods``` will show the replication controller (RC) and pods created.
```console ```console
@ -157,13 +163,13 @@ deploymentrc-1975012602-j975u 1/1 Running 0 1m
deploymentrc-1975012602-uashb 1/1 Running 0 1m deploymentrc-1975012602-uashb 1/1 Running 0 1m
``` ```
The created RC will ensure that there are 3 nginx pods at all time. The created RC will ensure that there are three nginx pods at all times.
## Updating a Deployment ## Updating a Deployment
Lets say, now we want to update the nginx pods to start using nginx:1.9.1 image Suppose that we now want to update the nginx pods to start using the `nginx:1.9.1` image
instead of nginx:1.7.9. instead of the `nginx:1.7.9` image.
For this, we update our deployment to be as follows: For this, we update our deployment file as follows:
<!-- BEGIN MUNGE: EXAMPLE new-nginx-deployment.yaml --> <!-- BEGIN MUNGE: EXAMPLE new-nginx-deployment.yaml -->
@ -189,13 +195,14 @@ spec:
[Download example](new-nginx-deployment.yaml?raw=true) [Download example](new-nginx-deployment.yaml?raw=true)
<!-- END MUNGE: EXAMPLE new-nginx-deployment.yaml --> <!-- END MUNGE: EXAMPLE new-nginx-deployment.yaml -->
We can then `apply` the Deployment:
```console ```console
$ kubectl apply -f docs/user-guide/new-nginx-deployment.yaml $ kubectl apply -f docs/user-guide/new-nginx-deployment.yaml
deployment "nginx-deployment" configured deployment "nginx-deployment" configured
``` ```
Running a get immediately will still give: Running a `get` immediately will still give:
```console ```console
$ kubectl get deployments $ kubectl get deployments
@ -205,7 +212,7 @@ nginx-deployment 3/3 8s
This indicates that deployment status has not been updated yet (it is still This indicates that deployment status has not been updated yet (it is still
showing old status). showing old status).
Running a get again after a minute, will give: Running a `get` again after a minute, should show:
```console ```console
$ kubectl get deployments $ kubectl get deployments
@ -213,9 +220,9 @@ NAME UPDATEDREPLICAS AGE
nginx-deployment 1/3 1m nginx-deployment 1/3 1m
``` ```
This indicates that deployment has updated one of the three pods that it needs This indicates that the Deployment has updated one of the three pods that it needs
to update. to update.
Eventually, it will get around to updating all the pods. Eventually, it will update all the pods.
```console ```console
$ kubectl get deployments $ kubectl get deployments
@ -223,8 +230,8 @@ NAME UPDATEDREPLICAS AGE
nginx-deployment 3/3 3m nginx-deployment 3/3 3m
``` ```
We can run ```kubectl get rc``` to see that deployment updated the pods by creating a new RC We can run ```kubectl get rc``` to see that the Deployment updated the pods by creating a new RC,
which it scaled up to 3 and scaled down the old RC to 0. which it scaled up to 3 replicas, and has scaled down the old RC to 0 replicas.
```console ```console
kubectl get rc kubectl get rc
@ -233,7 +240,7 @@ deploymentrc-1562004724 nginx nginx:1.9.1 deployment.kubernetes.io/
deploymentrc-1975012602 nginx nginx:1.7.9 deployment.kubernetes.io/podTemplateHash=1975012602,app=nginx 0 7m deploymentrc-1975012602 nginx nginx:1.7.9 deployment.kubernetes.io/podTemplateHash=1975012602,app=nginx 0 7m
``` ```
Running get pods, will only show the new pods. Running `get pods` should now show only the new pods:
```console ```console
kubectl get pods kubectl get pods
@ -243,7 +250,7 @@ deploymentrc-1562004724-1rkfl 1/1 Running 0 8m
deploymentrc-1562004724-6v702 1/1 Running 0 8m deploymentrc-1562004724-6v702 1/1 Running 0 8m
``` ```
Next time we want to update pods, we can just update the deployment again. Next time we want to update these pods, we can just update and re-apply the Deployment again.
Deployment ensures that not all pods are down while they are being updated. By Deployment ensures that not all pods are down while they are being updated. By
default, it ensures that minimum of 1 less than the desired number of pods are default, it ensures that minimum of 1 less than the desired number of pods are
@ -273,27 +280,29 @@ Events:
1m 1m 1 {deployment-controller } ScalingRC Scaled down rc deploymentrc-1975012602 to 0 1m 1m 1 {deployment-controller } ScalingRC Scaled down rc deploymentrc-1975012602 to 0
``` ```
Here we see that when we first created the deployment, it created an RC and scaled it up to 3 replicas directly. Here we see that when we first created the Deployment, it created an RC and scaled it up to 3 replicas directly.
When we updated the deployment, it created a new RC and scaled it up to 1 and then scaled down the old RC by 1, so that at least 2 pods were available at all times. When we updated the Deployment, it created a new RC and scaled it up to 1 and then scaled down the old RC by 1, so that at least 2 pods were available at all times.
It then scaled up the new RC to 3 and when those pods were ready, it scaled down the old RC to 0. It then scaled up the new RC to 3 and when those pods were ready, it scaled down the old RC to 0.
### Multiple Updates ### Multiple Updates
Each time a new deployment object is observed, a replication controller is Each time a new deployment object is observed, a replication controller is
created to bring up the desired pods if there is no existing RC doing so. created to bring up the desired pods if there is no existing RC doing so.
Existing RCs controlling pods whose labels match `.spec.selector` but the Existing RCs controlling pods whose labels match `.spec.selector` but whose
template does not match `.spec.template` are scaled down. template does not match `.spec.template` are scaled down.
Eventually, the new RC will be scaled to `.spec.replicas` and all old RCs will Eventually, the new RC will be scaled to `.spec.replicas` and all old RCs will
be scaled to 0. be scaled to 0.
If the user updates the deployment while an existing deployment was in progress,
deployment will create a new RC as per the update and start scaling that up and If the user updates a Deployment while an existing deployment is in progress,
will roll the RC that it was scaling up before in its list of old RCs and will the Deployment will create a new RC as per the update and start scaling that up, and
will roll the RC that it was scaling up previously-- it will add it to its list of old RCs and will
start scaling it down. start scaling it down.
For example: If user creates a deployment to create 5 replicas of nginx:1.7.9.
But then updates the deployment to create 5 replicas of nging:1.9.1, when only 3 For example, suppose the user creates a deployment to create 5 replicas of `nginx:1.7.9`,
replicas of nginx:1.7.9 had been created, then deployment will immediately start but then updates the deployment to create 5 replicas of `nginx:1.9.1`, when only 3
killing the 3 nginx:1.7.9 pods that it had created and will start creating replicas of `nginx:1.7.9` had been created. In that case, deployment will immediately start
nginx:1.9.1 pods. It will not wait for 5 replicas of nginx:1.7.9 to be created killing the 3 `nginx:1.7.9` pods that it had created, and will start creating
`nginx:1.9.1` pods. It will not wait for 5 replicas of `nginx:1.7.9` to be created
before changing course. before changing course.
## Writing a Deployment Spec ## Writing a Deployment Spec
@ -309,12 +318,12 @@ A Deployment also needs a [`.spec` section](../devel/api-conventions.md#spec-and
The `.spec.template` is the only required field of the `.spec`. The `.spec.template` is the only required field of the `.spec`.
The `.spec.template` is a [pod template](replication-controller.md#pod-template). It has exactly The `.spec.template` is a [pod template](replication-controller.md#pod-template). It has exactly
the same schema as a [pod](pods.md), except it is nested and does not have an the same schema as a [pod](pods.md), except that it is nested and does not have an
`apiVersion` or `kind`. `apiVersion` or `kind`.
### Replicas ### Replicas
`.spec.replicas` is an optional field that specifies the number of desired pods. Defaults `.spec.replicas` is an optional field that specifies the number of desired pods. It defaults
to 1. to 1.
### Selector ### Selector
@ -331,14 +340,14 @@ number of pods are less than the desired number.
is added to existing RCs (and label key that is added to its pods) to prevent is added to existing RCs (and label key that is added to its pods) to prevent
the existing RCs to select new pods (and old pods being selected by new RC). the existing RCs to select new pods (and old pods being selected by new RC).
Users can set this to an empty string to indicate that the system should Users can set this to an empty string to indicate that the system should
not add any selector and label. If unspecified, system uses not add any selector and label. If unspecified, the system uses
"deployment.kubernetes.io/podTemplateHash". `deployment.kubernetes.io/podTemplateHash`.
Value of this key is hash of `.spec.template`. The value of this key is the hash of `.spec.template`.
No label is added if this is set to empty string. No label is added if this is set to the empty string.
### Strategy ### Strategy
`.spec.strategy` specifies the strategy to replace old pods by new ones. `.spec.strategy` specifies the strategy used to replace old pods by new ones.
`.spec.strategy.type` can be "Recreate" or "RollingUpdate". "RollingUpdate" is `.spec.strategy.type` can be "Recreate" or "RollingUpdate". "RollingUpdate" is
the default value. the default value.
@ -346,11 +355,11 @@ the default value.
All existing pods are killed before new ones are created when All existing pods are killed before new ones are created when
`.spec.strategy.type==Recreate`. `.spec.strategy.type==Recreate`.
Note: This is not implemented yet. __Note: This is not implemented yet__.
#### Rolling Update Deployment #### Rolling Update Deployment
Deployment updates pods in a [rolling update](update-demo/) fashion The Deployment updates pods in a [rolling update](update-demo/) fashion
when `.spec.strategy.type==RollingUpdate`. when `.spec.strategy.type==RollingUpdate`.
Users can specify `maxUnavailable`, `maxSurge` and `minReadySeconds` to control Users can specify `maxUnavailable`, `maxSurge` and `minReadySeconds` to control
the rolling update process. the rolling update process.
@ -359,46 +368,48 @@ the rolling update process.
`.spec.strategy.rollingUpdate.maxUnavailable` is an optional field that specifies the `.spec.strategy.rollingUpdate.maxUnavailable` is an optional field that specifies the
maximum number of pods that can be unavailable during the update process. maximum number of pods that can be unavailable during the update process.
Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: The value can be an absolute number (e.g. 5) or a percentage of desired pods
10%). (e.g. 10%).
Absolute number is calculated from percentage by rounding up. The absolute number is calculated from percentage by rounding up.
This can not be 0 if `.spec.strategy.rollingUpdate.maxSurge` is 0. This can not be 0 if `.spec.strategy.rollingUpdate.maxSurge` is 0.
By default, a fixed value of 1 is used. By default, a fixed value of 1 is used.
Example: when this is set to 30%, the old RC can be scaled down to
For example, when this value is set to 30%, the old RC can be scaled down to
70% of desired pods immediately when the rolling update starts. Once new pods are 70% of desired pods immediately when the rolling update starts. Once new pods are
ready, old RC can be scaled down further, followed by scaling up the new RC, ready, old RC can be scaled down further, followed by scaling up the new RC,
ensuring that the total number of pods available at all times during the ensuring that the total number of pods available at all times during the
update is at least 70% of desired pods. update is at least 70% of the desired pods.
##### Max Surge ##### Max Surge
`.spec.strategy.rollingUpdate.maxSurge` is an optional field that specifies the `.spec.strategy.rollingUpdate.maxSurge` is an optional field that specifies the
maximum number of pods that can be created above the desired number of pods. maximum number of pods that can be created above the desired number of pods.
Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: Value can be an absolute number (e.g. 5) or a percentage of desired pods
10%). (e.g. 10%).
This can not be 0 if MaxUnavailable is 0. This can not be 0 if `MaxUnavailable` is 0.
Absolute number is calculated from percentage by rounding up. The absolute number is calculated from percentage by rounding up.
By default, a value of 1 is used. By default, a value of 1 is used.
Example: when this is set to 30%, the new RC can be scaled up immediately when
For example, when this value is set to 30%, the new RC can be scaled up immediately when
the rolling update starts, such that the total number of old and new pods do not exceed the rolling update starts, such that the total number of old and new pods do not exceed
130% of desired pods. Once old pods have been killed, 130% of desired pods. Once old pods have been killed,
new RC can be scaled up further, ensuring that total number of pods running the new RC can be scaled up further, ensuring that the total number of pods running
at any time during the update is at most 130% of desired pods. at any time during the update is at most 130% of desired pods.
##### Min Ready Seconds ##### Min Ready Seconds
`.spec.strategy.rollingUpdate.minReadySeconds` is an optional field that specifies the `.spec.strategy.rollingUpdate.minReadySeconds` is an optional field that specifies the
minimum number of seconds for which a newly created pod should be ready minimum number of seconds for which a newly created pod should be ready
without any of its container crashing, for it to be considered available. without any of its containers crashing, for it to be considered available.
Defaults to 0 (pod will be considered available as soon as it is ready). This defaults to 0 (the pod will be considered available as soon as it is ready).
Note: This is not implemented yet. __Note: This is not implemented yet__.
## Alternative to Deployments ## Alternative to Deployments
### kubectl rolling update ### kubectl rolling update
[Kubectl rolling update](kubectl/kubectl_rolling-update.md) also updates pods and replication controllers in a similar fashion. [Kubectl rolling update](kubectl/kubectl_rolling-update.md) also updates pods and replication controllers in a similar fashion.
But deployments is declarative and is server side. But Deployments is declarative and is server side.
<!-- BEGIN MUNGE: GENERATED_ANALYTICS --> <!-- BEGIN MUNGE: GENERATED_ANALYTICS -->