Kubernetes creates a second ReplicaSet, where it deploys the new pods and removes the old one from the original ReplicaSet
2 Types of Update Strategies in Kubernetes.
Recreate: Removes the previous version and loads the new, good for development(interrupting the service).
RollingUpdate (default): it updates to a new version gradually based on configured parameters.
The parameters are:
maxUnavailable: The number/percentage of pods that can be unavailable during the update.
maxSurge: The number/percentage of pods that can exceed the replicas requested.
minReadySeconds: The number(only) of seconds to wait before the next pod’s creation.
Kubernetes will create a new ReplicaSet and deploy one pod at a time, waiting five seconds for each pod.
During the update, only one pod can be unavailable, and the maximum number of pods is 11: 10 for the replica value and 1 for the maxSurge value.
You can not specify the minReadySecond parameter, but if your container in the
pod is not fast, you can make your application unavailable for a
while.
kubectl delete deployment myapp-deployment
kubectl apply -f 13.deployment.yaml
kubectl apply -f 15.deployment_strategy.yaml --record
The "--record" parameter will track all the changes to the deployment, which we will use to analyze the history and rollback to a previous version of the application. It takes some time to complete
To see the the progress by the deployment rollout status command
kubectl rollout status deployment myapp-deployment
To see the deployment rollout history
kubectl rollout history deployment myapp-deployment
Changes on the (replicas: 15 and zone:test), re execute the 15.deployment_strategy.yaml, now you can see the 2 rows in the history.
kubectl rollout undo deployment myapp-deployment --to-revision=1
No comments:
Post a Comment