04 - Rolling Updates and Rollbacks
Q: Inspect the deployment and identify the number of PODs deployed by it
Ans: 4
$ kubectl get deploy
$ kubectl describe deployment | grep -i Desired
Q: Inspect the deployment and identify the current strategy
$ kubectl describe deployment frontend | grep -i StrategyType
Ans: StrategyType: RollingUpdate
Q: If you were to upgrade the application now what would happen?
Ans: PODs are upgraded few at a time
Q: Let us try that. Upgrade the application by setting the image on the deployment to `kodekloud/webapp-color:v2`.
Do not delete and re-create the deployment. Only set the new image name for the existing deployment.
- Deployment Name: frontend
- Deployment Image: kodekloud/webapp-color:v2
Run the command `kubectl edit deployment frontend` and modify the image to `kodekloud/webapp-color:v2`.
Next, save and exit. The pods should be recreated with the new image.
方法一:
$ kubectl edit deployment frontend
方法二:
過程如下:
Q: Up to how many PODs can be down for upgrade at a time
Look at the Max Unavailable value under RollingUpdateStrategy in deployment details
Ans: maxUnavailable: 25% x 4 pods = 1
Q: Change the deployment strategy to `Recreate`
Delete and re-create the deployment if necessary. Only update the strategy type for the existing deployment.
- Deployment Name: frontend
- Deployment Image: kodekloud/webapp-color:v2
- Strategy: Recreate
$ kubectl edit deployment frontend
結論
- Recreate:把原本的 pods 全部刪除,接著全部重新建立,有 downtime(502 Bad Gateway)
- RollingUpdate:把原本的 pods 一個一個地慢慢替換,實現 Zero Downtime





留言
張貼留言