• kubernetes: Rollback a deployment update

  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...

• Keeping record of the change cause using the --record flag

  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...

• Rolling updates on Kubernetes deployments

  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...

• Relationship between Deployment and ReplicaSet in kubernetes

  3 min read

  
  

  Although ReplicaSet's main purpose is to maintain a stable set of replica Pods, it's not a kubernetes object that is commonly created, at least not explicitly. But the replicas attribute on the Deployment object is actually related to this object

  04/03/2021

  Read more...

• Restart pods without taking the service down

  2 min read

  
  

  As of kubernetes 1.15, you can do a rolling restart of all pods for a deployment without taking the service down. To achieve this we'll have to use kubectl rollout restart.

  Let's asume you have a deployment with two replicas:

  $ kubectl get pods
  NAME                                     READY   STATUS      RESTARTS   AGE
  pet2cattle-5454555dbb-6jtnz              1/1     Running     0          131m
  pet2cattle-5454555dbb-czw42              1/1     Running     0          19s
  

  01/03/2021

  Read more...

More recent...