9.1. Use implement a rolling upgrade RC
#kubectl rolling-update kubia-v1 kubia-v2 --image=luksa/kubia:v2
Use kubia-v2 version of the application to replace the running kubia-v1 of RC, copy the new controller is named kubia-v2, and use luksa / kubia: v2 most images.
After upgrading the kubectl describe rc kubia-v2 check the status of the upgrade.
Why not use the rolling-update?
1. Direct update pod and RC label is not a solution;
2.kubectl just execute client upgrade, but if the process is to perform kubectl network connection, the upgrade will be interrupted, pod and RC will be in an intermediate state, so only the introduction Deployment resources.
9.2. Using Deployment declarative upgrade applications
Rc Rs alternative to duplicate a management pod.
Before Deployment create sure to remove all the RC and pod, but the escrow Service,
kubectl delete rc --all
Creating Deployment
#kubectl create -f kubectl.depl-v1.yaml --record // - record can record the version history information # View Deployment of #kubectl GET Deployment #kubectl DESCRIBE Deployment # View deployment status: #kubectl rollOut Status Deployment kubia
9.3. Trigger deployment upgrade
#kubectl edit deployment kubia // After modification resource object will be updated
#kubectl patch deployment kubia -p '{... }' // only contains the fields you want to update
#kubectl apply -f kubia-deploy-v2 . yml // If the resource yml defined does not exist, it will automatically be created
#kubectl replace -f kubia-deploy-v2.yml // If the resources yml defined does not exist, an error
Modify configmap does not trigger the upgrade, if you want to trigger, you can create a new configmap and modify templates to reference the new pod configmap.
9.4. Rollback deployment
In the following command can be used during the upgrade deployment to observe the process of upgrading
#kubectl rollout status deployment kubia
If there is an error, how to stop? You can use the following command to roll back to a previous version deployment
#kubectl rollout undo deployment kubia
How to display historical versions of deployment?
#kubectl rollout history deployment kubia
How to roll back to a specific version?
#kubectl rollout undo deployment kubia --to-revision=1
9.5. Control rolling upgrade rate
During a rolling upgrade deployment, there are two properties once the decision to replace the number of pod: maxSurge, maxUnavailable, can be configured through properties rollingUpdate under the strategy field,
maxSurge: determine the number of copies desired, the default value of 25%, if the number of copies is set to 4, then rolling upgrade process does not run over five pod.
maxUnavaliable: decided to allow the number of pod in an unusable state, the default value of 25%, if the copy number 4, then only one pod in an unusable state,
By default, if not upgraded within 10 minutes to complete, will be considered a failure, if you want to modify this parameter can be used kubectl describe deploy kubia view to a ProgressDeadline-Exceeded the record, you can modify the parameters modification judge this time.