Brief
Deployment provides a statement defined in formula (Declarative) method Pod and ReplicaSet, used to replace the previous ReplicationController to facilitate the management application. Typical application scenarios include:
Pod to create and define Deployment ReplicaSet
Rolling upgrade and rollback application
Accommodating expansion and contraction
Pause and resume Deployment
For example, a simple nginx application can be defined as:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80Expansion:
kubectl scale deployment nginx-deployment --replicas 10If the cluster supports horizontal pod autoscaling, it may also be set to automatically expand Deployment:
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1Rollback:
kubectl rollout undo deployment/nginx-deploymentWhat is Deployment
Deployment for the Pod and Replica Set (Next Generation Replication Controller) provides a declarative update.
You only need to describe what you want in Deployment target state, Deployment controller will help you to Pod and the actual state of Replica Set changes to your target state. You can define a new Deployment, you can create a new one to replace the old Deployment.
A typical use is as follows:
- Use Deployment to create ReplicaSet. ReplicaSet create a pod in the background. Check the startup state to see if it succeeds or fails.
- Then, to declare a new state Pod by updating Deployment of PodTemplateSpec field. This will create a new ReplicaSet, Deployment will follow the rate control of the pod from the old to the new ReplicaSet ReplicaSet in.
- If the current state of instability, roll back to the previous Deployment revision. Every time rollback revision updates the Deployment of.
- Deployment expansion to meet the higher load.
- Pause Deployment to apply multiple repair PodTemplateSpec, and then back online.
- Deployment of the state of the line is determined whether or hang live.
- Remove old unnecessary ReplicaSet.
Creating Deployment
Here is an example of Deployment, it creates a Replica Set to launch three nginx pod.
carried outdeployment
$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record
deployment "nginx-deployment" createdNote,
kubectl create -ffollowed by a file name, the actual work to be with your actual file name and path prevail
The -record of kubectl the flag is set to true the current command to create or update the resource record in the annotation. This can be useful in the future, for example, to see what commands executed in each Deployment revision in.
Then immediately executed getí will get the following results:
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 0 0 0 1sThe results show that we want to output the number repalica 3 (according to .spec.replicas configuration deployment in) the current replica number (.status.replicas) is 0, the latest replica number (.status.updatedReplicas) is 0, the number of replica available (.status.availableReplicas) is 0.
A few seconds after the get command, you will get the following output:
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 18sWe can see Deployment three replica has been created, all of the replica are already up to date (containing the latest pod template), available (according to .spec.minReadySeconds statement Deployment in, at least in the ready state of the pod number). Execution kubectl get rs and kubectl get pods will show Replica Set (RS) and Pod has been created.
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-2035384211 3 3 0 18sYou may notice that the name always Replica Set
$ kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-deployment-2035384211-7ci7o 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211
nginx-deployment-2035384211-kzszj 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211
nginx-deployment-2035384211-qqcnn 1/1 Running 0 18s app=nginx,pod-template-hash=2035384211Replica Set just created will ensure that there are always three nginx existence of pod.
Note: You must specify in the Deployment of selector correct pod template label (in this example is app = nginx), not to be confused with the other controller (including Deployment, Replica Set, Replication Controller, etc.). Kubernetes itself will not prevent you from doing so, if you really do, may lead to incorrect behavior.
Update Deployment
Note: Deployment of rollout iff pod template Deployment (e.g. .spec.template) is triggered by a label update or change the image. Other updates, such as expansion Deployment does not trigger rollout.
If we now want to make nginx pod using nginx: 1.9.1 a mirror to replace the original nginx: 1.7.9 the mirror.
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
deployment "nginx-deployment" image updatedWe can use the edit command to edit Deployment, modify .spec.template.spec.containers [0] .image, the nginx: 1.7.9 rewritten as nginx: 1.9.1.
$ kubectl edit deployment/nginx-deployment
deployment "nginx-deployment" editedView rollout of the state, just run:
$ kubectl rollout status deployment/nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
deployment "nginx-deployment" successfully rolled outAfter Rollout success, get Deployment:
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 36sThe number of UP-TO-DATE replica has reached the required number of configurations.
The number of replica CURRENT indicates the number of replica Deployment management, the number is the number of replica replica AVAILABLE currently available.
We can run kubectl get rs to see that the Deployment updated the Pods by creating a new Replica Set and scaling it up to 3 replicas, as well as scaling down the old Replica Set to 0 replicas.
We can see through the implementation of kubectl get rs Deployment updated Pod, by creating a new Replica Set and expansion of three replica, while the original Replica Set volume reduction to 0 replica.
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-1564180365 3 3 0 6s
nginx-deployment-2035384211 0 0 0 36sExecution get pods will only see the current new pod:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-khku8 1/1 Running 0 14s
nginx-deployment-1564180365-nacti 1/1 Running 0 14s
nginx-deployment-1564180365-z9gth 1/1 Running 0 14sThe next update of the pod, you can just update the template can Deployment of the pod.
Deployment can guarantee that when you upgrade only a certain number of Pod is down. By default, it will ensure that the number Pod have at least one less than the desired Pod is up state (up to a unavailable).
Deployment also can ensure that only the desired number of more than create a certain number of Pod. By default, it will ensure that at most one more than the number expected Pod Pod is up (up to a surge).
Kuberentes in future versions, from 1-1 to become 25% -25%) Note I use the 1.13 version, it is already like this.
For example, if you look at the above Deployment, you will find, start creating a new Pod, and then delete some old Pod and then create a new one. Before you create a new Pod will not kill out the old Pod. This ensures that the number of available Pod at least two, up to four of the total number of Pod.
$ kubectl describe deployments
Name: nginx-deployment
Namespace: default
CreationTimestamp: Tue, 15 Mar 2016 12:01:06 -0700
Labels: app=nginx
Selector: app=nginx
Replicas: 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas created)
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
36s 36s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3
23s 23s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1
23s 23s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2
23s 23s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2
21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0
21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3We can see that when we first started to create the Deployment of time, create a Replica Set (nginx-deployment-2035384211), and directly to the expansion of the three replica.
When we update this Deployment of time, it will create a new Replica Set (nginx-deployment-1564180365), the expansion of it into a replica, then the original Replica Set volume reduction to two replica, this time to meet at least two Pod is available, up to four at a time in a state Pod created.
Then continue with the same strategy of rolling update and expansion of new Replica Set volume reduction old Replica Set. Eventually, there will be three available in new replica Replica Set, the number of replica old Replica Set becomes zero.
RollOver (a plurality of parallel rollout)
Deployment controller observed whenever there is a new deployment is created, if there is no existing Replica Set Pod to create a number of expectations, it would create a new Replica Set to do it. Existing Replica Set control label match .spec.selector but Pod template that does not match with .spec.template volume reduction. Eventually, the new expansion will Replica Set a specified number of .spec.replicas Pod, old Replica Set volume will shrink to zero.
If you update a Deployment and ongoing already exists in each update Deployment will create a new Replica Set and its expansion, while expansion of Replica Set-- rollback before adding it to the old Replica Set list start volume reduction.
For example, if you create a five niginx: 1.7.9 replica of Deployment, but when there are only three nginx: When you create a replica out of the 1.7.9 update you begin to contain 5 nginx: 1.9.1 replica of Deployment. In this case, Deployment will be immediately killed have created three nginx: 1.7.9 the Pod, and start creating nginx: 1.9.1 the Pod. It will not wait until all five nginx: 1.7.9 after the completion of Pod creates began to change course.
Fallback Deployment
Sometimes you may want to roll back a Deployment, for example, when the Deployment of instability, such as has been crash looping.
By default, kubernetes saved rollout history Deployment of the first two in the system, so that you can retire at any time (you can change the revision history limit to the number of revision changes saved)
Note: As long as the rollout Deployment is triggered it will create a revision. That is, when and only when the Pod Deployment template (eg .spec.template) is changed, for example, to update the template image label and the container, it will create a new revision
Other updates, such as the expansion does not create Deployment revision-- so we can easily manual or automatic expansion. This means that when you fall back to historical revision is only in the Pod template section Deployment will be rolled back.
Suppose we make the time to update the Deployment of a spelling error, the name of the mirror written nginx: 1.91, and the correct name should be nginx: 1.9.1:
$ kubectl set image deployment/nginx-deployment nginx=nginx:1.91
deployment "nginx-deployment" image updatedRollout will be stuck.
$ kubectl rollout status deployments nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...Hold down the Ctrl-C to stop the above rollout status monitoring.
You will see the old replicas (nginx-deployment-1564180365 and nginx-deployment-2035384211) and the new replicas (nginx-deployment-3066724191) the number is two.
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-1564180365 2 2 0 25s
nginx-deployment-2035384211 0 0 0 36s
nginx-deployment-3066724191 2 2 2 6sCreate a look Pod, you will see two new Pod Replica Set created in ImagePullBackOff state, pull loop mirror.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-deployment-1564180365-70iae 1/1 Running 0 25s
nginx-deployment-1564180365-jbqqo 1/1 Running 0 25s
nginx-deployment-3066724191-08mng 0/1 ImagePullBackOff 0 6s
nginx-deployment-3066724191-eocby 0/1 ImagePullBackOff 0 6sNote, Deployment controller will automatically stop the bad rollout, and stop the expansion of the new Replica Set
$ kubectl describe deployment
Name: nginx-deployment
Namespace: default
CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700
Labels: app=nginx
Selector: app=nginx
Replicas: 2 updated | 3 total | 2 available | 2 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
OldReplicaSets: nginx-deployment-1564180365 (2/2 replicas created)
NewReplicaSet: nginx-deployment-3066724191 (2/2 replicas created)
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2
22s 22s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2
21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0
21s 21s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-1564180365 to 2
13s 13s 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 2To fix this problem, we need to roll back to a stable Deployment revision.
History checks Deployment Upgrade
First, check the revision under Deployment:
$ kubectl rollout history deployment/nginx-deployment
deployments "nginx-deployment":
REVISION CHANGE-CAUSE
1 kubectl create -f docs/user-guide/nginx-deployment.yaml --record
2 kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
3 kubectl set image deployment/nginx-deployment nginx=nginx:1.91Because we create Deployment time can be recorded using the parameters -recored command, we can easily see each revison changes.
View details of the individual revision:
$ kubectl rollout history deployment/nginx-deployment --revision=2
deployments "nginx-deployment" revision 2
Labels: app=nginx
pod-template-hash=1159050644
Annotations: kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
Containers:
nginx:
Image: nginx:1.9.1
Port: 80/TCP
QoS Tier:
cpu: BestEffort
memory: BestEffort
Environment Variables: <none>
No volumes.Fall back to version history
Now, we may decide to roll back the current rollout to the previous version:
$ kubectl rollout undo deployment/nginx-deployment
deployment "nginx-deployment" rolled backYou can also use --revision parameter to specify a version of history:
$ kubectl rollout undo deployment/nginx-deployment --to-revision=2
deployment "nginx-deployment" rolled backCommand associated with the rollout of detailed documentation see kubectl rollout.
The Deployment now fall back to a previous stable version. As you can see, Deployment controller generates a fallback revison DeploymentRollback 2 of the event.
$ kubectl get deployment
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 3 3 3 3 30m
$ kubectl describe deployment
Name: nginx-deployment
Namespace: default
CreationTimestamp: Tue, 15 Mar 2016 14:48:04 -0700
Labels: app=nginx
Selector: app=nginx
Replicas: 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
OldReplicaSets: <none>
NewReplicaSet: nginx-deployment-1564180365 (3/3 replicas created)
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
30m 30m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-2035384211 to 3
29m 29m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 1
29m 29m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 2
29m 29m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 2
29m 29m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-2035384211 to 0
29m 29m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 2
29m 29m 1 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-3066724191 to 1
29m 29m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-1564180365 to 2
2m 2m 1 {deployment-controller } Normal ScalingReplicaSet Scaled down replica set nginx-deployment-3066724191 to 0
2m 2m 1 {deployment-controller } Normal DeploymentRollback Rolled back deployment "nginx-deployment" to revision 2
29m 2m 2 {deployment-controller } Normal ScalingReplicaSet Scaled up replica set nginx-deployment-1564180365 to 3Cleanup Policy
You can use the following command expansion Deployment:
$ kubectl scale deployment nginx-deployment --replicas 10
deployment "nginx-deployment" scaledSuppose your cluster enabled horizontal pod autoscaling, you can set up a autoscaler to Deployment, select the minimum and maximum number of Pod Pod is based on current CPU utilization.
$ kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
deployment "nginx-deployment" autoscaledExpansion ratio
RollingUpdate Deployment to support multiple versions of an application running simultaneously. When you use autoscaler expansion RollingUpdate Deployment, it is halfway rollout (already in progress or paused), in order to reduce risk, activity Deployment controller will balance existing in ReplicaSets (there ReplicaSets Pod) and the newly added replicas . This is known as the ratio of expansion.
For example, the running Deployment containing 10 replica, maxSurge = 3, maxUnavailable = 2.
$ kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 10 10 10 10 50sYou updated a mirror, and can not be resolved within a cluster
$ kubectl set image deploy/nginx-deployment nginx=nginx:sometag
deployment "nginx-deployment" image updatedMirror update launched a new rollout contains ReplicaSet nginx-deployment-1989198191, but it was blocked because maxUnavailable we mentioned above.
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-1989198191 5 5 0 9s
nginx-deployment-618515232 8 8 8 1mThen launched a new Deployment expansion request. repllica Deployment autoscaler the number increased to 15. Deployment controller needs to determine where to increase these five new replica. If we do not have anyone with the proportion of expansion, all five will be added to the replica in a new ReplicaSet. If you use a proportion of expansion, the newly added replica are propagated to all the ReplicaSet in. Was added up to a large number of replica ReplicaSet portion, a small portion was added to a small number of replica in ReplciaSet. 0 replica of ReplicaSet not expansion.
In our example above, the three replica will be added to the old ReplicaSet, the two replica will be added to the new ReplicaSet in. rollout process will eventually move all of the replica to a new ReplicaSet, assuming a new replica to be healthy state.
$ kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx-deployment 15 18 7 8 7m
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-deployment-1989198191 7 7 0 7m
nginx-deployment-618515232 11 11 11 7mPause and resume Deployment
You can pause a Deployment before the update trigger once or several times, and then restore it. So you can pause and resume Deployment, some repair work during this time, but will not start unnecessary rollout.
For example, using just created Deployment:
$ kubectl get deploy
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
nginx 3 3 3 3 1m
[mkargaki@dhcp129-211 kubernetes]$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-2142116321 3 3 3 1mUse the following command to pause Deployment:
$ kubectl rollout pause deployment/nginx-deployment
deployment "nginx-deployment" pausedThen update Deplyment in the mirror:
$ kubectl set image deploy/nginx nginx=nginx:1.9.1
deployment "nginx-deployment" image updatedNote that the new rollout started:
$ kubectl rollout history deploy/nginx
deployments "nginx"
REVISION CHANGE-CAUSE
1 <none>
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
nginx-2142116321 3 3 3 2mYou can update any number of times, such as updating the use of resources:
$ kubectl set resources deployment nginx -c=nginx --limits=cpu=200m,memory=512Mi
deployment "nginx" resource requirements updatedThe initial state before Deployment will continue to suspend its functionality without updating Deployment will have any effect, as long as Deployment is suspended.
Finally, restore the Deployment, observed complete the update has been created out of ReplicaSet:
$ kubectl rollout resume deploy nginx
deployment "nginx" resumed
$ KUBECTL get rs -w
NAME DESIRED CURRENT READY AGE
nginx-2142116321 2 2 2 2m
nginx-3926361531 2 2 0 6s
nginx-3926361531 2 2 1 18s
nginx-2142116321 1 2 2 2m
nginx-2142116321 1 2 2 2m
nginx-3926361531 3 2 1 18s
nginx-3926361531 3 2 1 18s
nginx-2142116321 1 1 1 2m
nginx-3926361531 3 3 1 18s
nginx-3926361531 3 3 2 19s
nginx-2142116321 0 1 1 2m
nginx-2142116321 0 1 1 2m
nginx-2142116321 0 0 0 2m
nginx-3926361531 3 3 3 20s
^C
$ KUBECTL get rs
NAME DESIRED CURRENT READY AGE
nginx-2142116321 0 0 0 2m
nginx-3926361531 3 3 3 28sNote: Before you restore Deployment can not roll back a paused a Deployment.
Deployment state
Deployment There are many states in the life cycle. Create a new ReplicaSet when it may be progressing state, complete state, or fail to progress status.
Progressing Deployment
Kubernetes will be performed through one of the following tasks Deployment marked as progressing state:
Deployment is the process of creating a new ReplicaSet.
Deployment is expansion of an existing ReplicaSet.
Deployment is a volume reduction of existing ReplicaSet.
There are new options available pod appears.
You can use kubectl roullout status command to monitor the progress of Deployment.
Complete Deployment
Deployment Kubernetes marker including the complete state of the following characteristics:
Deployment minimum available. The minimum number of available replica available means Deployment is equal to or more than the number expected Deployment strategy.
All associated with the Deployment replica is updated to the version you specify, also said that the update is complete.
This is not the old Pod Deployment exist.
You can check with kubectl rollout status command if Deployment completed. If the rollout successfully completed, kubectl rollout status will return a 0 Exit Code value.
$ kubectl rollout status deploy/nginx
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx" successfully rolled out
$ echo $?
0Failed Deployment
Your Deployment may get stuck when you try to deploy a new ReplicaSet, which may be caused due to several factors:
Invalid references
Unreadable probe failure
Mirroring pull error
Enough authority
Range limit
Runtime configuration errors
One way to detect this situation is that you specified in the Deployment spec in spec.progressDeadlineSeconds. spec.progressDeadlineSeconds represents Deployment controller to determine how many seconds to wait (through Deployment status) Deployment process is stuck.
The following command set progressDeadlineSeconds kubectl controller so stuck progress report after 10 minutes Deployment:
$ kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
"nginx-deployment" patchedWhen the time exceeds the deadline, an increase Controller Deployment DeploymentCondition the Deployment of status.conditions, which comprises the following attributes:
- Type=Progressing
- Status=False
- Reason=ProgressDeadlineExceeded
Note: kubernetes Reason = outer ProgressDeadlineExceeded addition to reporting the status information does not do anything to the jammed Deployment. A higher level of coordination can take advantage of it and take appropriate action, for example, roll back to previous versions of Deployment.
You may experience some transient errors when using Deployment, which may be due to a timeout you set too short, there may be short-lived because of various other error error. For example, suppose you use an invalid reference. Describe Deployment of when you may notice the following information:
$ kubectl describe deployment nginx-deployment
<...>
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True ReplicaSetUpdated
ReplicaFailure True FailedCreate
<...>Execution kubectl get deployment nginx-deployment -o yaml, Deployement state might look like this:
status:
availableReplicas: 2
conditions:
- lastTransitionTime: 2016-10-04T12:25:39Z
lastUpdateTime: 2016-10-04T12:25:39Z
message: Replica set "nginx-deployment-4262182780" is progressing.
reason: ReplicaSetUpdated
status: "True"
type: Progressing
- lastTransitionTime: 2016-10-04T12:25:42Z
lastUpdateTime: 2016-10-04T12:25:42Z
message: Deployment has minimum availability.
reason: MinimumReplicasAvailable
status: "True"
type: Available
- lastTransitionTime: 2016-10-04T12:25:39Z
lastUpdateTime: 2016-10-04T12:25:39Z
message: 'Error creating: pods "nginx-deployment-4262182780-" is forbidden: exceeded quota:
object-counts, requested: pods=1, used: pods=3, limited: pods=2'
reason: FailedCreate
status: "True"
type: ReplicaFailure
observedGeneration: 3
replicas: 2
unavailableReplicas: 2Eventually, once more than Deployment process deadline, kuberentes updates the status and cause Progressing state reasons:
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing False ProgressDeadlineExceeded
ReplicaFailure True FailedCreateYou can solve the problem of insufficient quota volume reduction Deployment of the way, or increase the quota of your namespace. If you meet the quota conditions, Deployment controller will complete your Deployment rollout, you will see the status update is successful Deployment of state (Status = True and Reason = NewReplicaSetAvailable).
Conditions:
Type Status Reason
---- ------ ------
Available True MinimumReplicasAvailable
Progressing True NewReplicaSetAvailableType = Available, Status = True means that you have a minimum availability of Deployment. Minimum availability is specified in the Deployment policy parameters. Type = Progressing, Status = True means that your Deployment or during deployment or already deployed successfully reached the minimum number of available replica (see particular status Reason-- in our case means that the desired Reason = NewReplicaSetAvailable Deployment has been completed).
You can use kubectl rollout status command to view the Deployment process has failed. When Deployment process exceeds deadline, kubectl rollout status returns a nonzero exit code.
$ kubectl rollout status deploy/nginx
Waiting for rollout to finish: 2 out of 3 new replicas have been updated...
error: deployment "nginx" exceeded its progress deadline
$ echo $?
1Operation failed Deployment
Deployment of all operations performed are applicable to the failure of Deployment. You can expand it / volume reduction, fall back to historical version, you can even pause it multiple times to apply Deployment pod template.
Cleanup Policy
You can set .spec.revisionHistoryLimit item Deployment to specify how many of the old ReplicaSet reserved. The remaining will be garbage collected in the background. By default, all of it will be retained revision history. In future versions, it will change to 2.
Note: Set the value to 0 will cause all of the Deployment history will be cleared, the Deploynent will not be able to return back.
Written Deployment Spec Guide
In all Kubernetes configurations, Deployment need apiVersion, kind and metadata of these configuration items. General description of the profile view using application deployment, container configuration, management and use of resources kubeclt document.
Deployment also need .spec section.
Pod Template
.spec.template .Spec is the only required field.
.spec.template a pod template. It has exactly the same schema with Pod, except that it need not be nested and apiVersion and kind field.
In addition to the scoping Pod, Deployment of the pod template must specify the appropriate label (Do not Repeat with the other controller) and restart the appropriate strategy.
.spec.template.spec.restartPolicy Can be set to Always, if this is not specified, the default configuration.
Replicas
.spec.replicas Is selected field, specify the desired number of pod, the default is 1.
Selector
.spec.selector is an optional field used to specify the label selector, delineate the scope of Deployment Management pod.
If specified, .spec.selector must match .spec.template.metadata.labels, or it will be rejected API. If .spec.selector not specified, .spec.selector.matchLabels default is .spec.template.metadata.labels.
Pod of template with different .spec.template or the number exceeds the number of prescribed under .spec.replicas, Deployment will kill label with a different selector Pod.
Note: You should not creating another label with this selector matches the pod, or by other Deployment, or by other Controller, such as ReplicaSet and ReplicationController. The Deployment otherwise would be to them as are their own created. Kubernetes will not stop you from doing so.
If you have multiple controller using a duplicate selector, controller they will conflict with each other and lead to incorrect behavior.
Tactics
.spec.strategy specify the new replacing the old Pod Pod strategy. .spec.strategy.type can be "Recreate" or "RollingUpdate". "RollingUpdate" is the default.
- Recreate Deployment
When .spec.strategy.type == Recreate, before creating a new Pod will first kill all existing Pod.
- Rolling Update Deployment
.spec.strategy.type==RollingUpdateTime, Deployment of using a rolling update update the Pod. You can specify maxUnavailable and maxSurge to control the rolling update process.
- Max Unavailable
.spec.strategy.rollingUpdate.maxUnavailableAre optional item, to specify the maximum number is not available during the upgrade by the Pod. This value can be an absolute value (e.g. 5), may be desired percentage Pod number (e.g., 10%). Rounding down by calculating the absolute value of the percentage. If .spec.strategy.rollingUpdate.maxSurge is 0, this value can not be zero. The default value is 1.
For example, the value is set to 30%, after starting rolling update old ReplicatSet will immediately to a desired volume reduction of 70% of the number of Pod. After the new Pod ready, along with the expansion of new ReplicaSet, the old ReplicaSet further volume reduction, to ensure that the number of Pod can be used at all times to upgrade at least 70% of the number of expected Pod.
- Max Surge
.spec.strategy.rollingUpdate.maxSurgeItem is optional to specify a desired number of Pod may exceed the maximum number. This value can be an absolute value (e.g. 5) or a desired number of Pod percentage (e.g. 10%). When the value is 0 MaxUnavailable is not 0. By calculating the absolute value of the percentage rounded up. The default value is 1.
For example, the value is set to 30%, after starting a new rolling update will immediately ReplicatSet expansion, the total number of new and old Pod does not exceed 130% of the desired number of Pod. Pod killed after the old, the new expansion will continue ReplicaSet old ReplicaSet further volume reduction, to ensure that at all times the number of upgrades of all Pod Pod and without exceeding the desired quantity of 130%.
- Progress Deadline Seconds
.spec.progressDeadlineSecondsIt is optional item, to specify the failed progressing reporting Deployment system - in the performance state resource type = Progressing, Status = False, Reason = seconds before ProgressDeadlineExceeded can wait for the Deployment. Deployment controller will continue to retry the Deployment. Future, in the realization of the automatic rollback, deployment controller automatically rolled back when observed in this state.
If this parameter is set, the value must be greater than .spec.minReadySeconds.
- Min Ready Seconds
.spec.minReadySeconds is an optional configuration item, to specify the crash Pod without any container and the minimum number of seconds that the available state. Default is 0 (Pod in the ready state will be considered available). Learn more about what the Pod would be considered a ready state, refer Container Probes.
- Rollback To
.spec.rollbackTo is a configuration item can choose to configure Deployment fallback configuration. Setting this parameter will trigger a rollback after each rollback is completed, the value will be cleared.
- Revision
.spec.rollbackTo.revision is an optional configuration item to specify fallback to the revision. The default is 0, which means fall back to the history of the oldest revision.
- Revision History Limit
Deployment revision history stored in ReplicaSets its control.
.spec.revisionHistoryLimit is an optional configuration item to specify the number of old ReplicaSet can be reserved. The ideal value depends on the frequency and stability of the heart Deployment. If the value is not set, the default all the old Replicaset will be retained, the resources are stored in etcd, the view is kubectl get rs output. Each Deployment of this configuration are stored in ReplicaSet in. However, once you remove the old RepelicaSet, you can not fall back to the Deployment of the revison.
If you set this value to 0, all with zero replica of ReplicaSet will be deleted. In this case, the new Deployment rollout can not be undone, because the revision history have been cleared out.
- Paused
.spec.paused is optional configuration item, boolean value. It is used to specify pause and resume Deployment. The only difference between Paused and Deployment is not paused, all changes to the paused deployment of PodTemplateSpec will not trigger a new rollout. Deployment default non paused after being created.