2 min read
When performing rolling updates we can see it's history using kubectl rollout history:
$ kubectl rollout history deploy pet2cattle
deployment.apps/pet2cattle
REVISION CHANGE-CAUSE
100 <none>
101 <none>
102 <none>
103 <none>
104 <none>
105 <none>
106 <none>
107 <none>
109 kubectl scale deployment/pet2cattle --replicas=2 --record=true
110 kubectl scale deployment/pet2cattle --replicas=5 --record=true
111 kubectl scale deployment/pet2cattle --replicas=1 --record=true
If have any problem with the update we can undo and update using kubectl rollout undo
25/05/2021
Read more...3 min read
On Kubernetes, when we update objects such as a deployment or a daemonset we can check it's rollout history using kubectl rollout history:
$ kubectl rollout history deploy pet2cattle
deployment.apps/pet2cattle
REVISION CHANGE-CAUSE
21 <none>
22 <none>
23 <none>
24 <none>
26 <none>
28 <none>
29 <none>
30 <none>
32 <none>
33 <none>
34 <none>
By default we won't be able to see a change cause, but we can fill this gap by setting the command that triggered the update adding the --record flag as follows:
$ kubectl scale deployment/pet2cattle --replicas 2 --record
deployment.apps/pet2cattle scaled
18/05/2021
Read more...2 min read
There are several strategies available for updating a deployment on Kubernetes, by default it will trigger a rolling update: It will deploy the new version before tearing down the old one so there's no downtime associated to it.
Let's see how we can see this process by applying an update to a deployment:
$ kubectl apply -f deployment.yaml
17/05/2021
Read more...