Rolling Update and Rollback of a Kubernetes DaemonSet

Filed Under: Random
Rolling Update And Rollback Of A Kubernetes DaemonSet

Hello, readers! This article talks about Rolling Update and Rollback of a Kubernetes DaemonSet with examples.

So, let us begin!! 馃檪


1. Rolling Update a Kubernetes DaemonSet

Kubernetes DaemonSet can be considered as a workload that resides on every node of your cluster. In this scenario, we may come across situations wherein we would need to change or update the DaemonSet for a better or updated workload configuration.

For the same, Kubernetes offers us the below strategies to perform a rolling update on the daemonset-

  1. RollingUpdate: This strategy is termed as the default one for the rolling update section. When we assign rolling update as the strategy, the moment we update a DaemonSet, all the old pods of the same gets deleted. They are replaced with the new pods of DaemonSet deployment configurations. Post which, one pod of the DaemonSet will be live on every node with the new configuration/strategy.
  2. OnDelete Strategy: Unlike RollingUpdate, once we update the DaemoSet here, the new pods will only be up when we manually delete the old pods.

Perform a Rolling Update on a Kubernetes DaemonSet

In this section, let us now try to implement the above knowledge to perform Rolling Update on a Kubernetes DaemonSet.

For the same, we will need to set .spec.updateStrategy.type to RollingUpdate.

Have a look at the below example!

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch-demo
  namespace: kube-system
  labels:
    k8s-app: fluentd
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch-demo
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch-demo
    spec:
      tolerations:
      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch-container
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

As clearly seen above, we have set the update strategy to RollingUpdate with maximum unavailability to 1 from the total count.

If you wish to check the update strategy of an already created DaemonSet, we can make use of the below command-

kubectl get ds/fluentd-elasticsearch-demo -o go-template='{{.spec.updateStrategy.type}}{{"\n"}}' -n kube-system

Output:

RollingUpdate

2. Rollback of a Kubernetes DaemonSet

Rollout or Rollback as the name suggests enables us to move back to the older version of our scenario. That is, it helps us to move to an older version of the DaemonSet or deployment in the current namespace.

To achieve this goal, we would definitely want to visit the history of the revisions that have had happened on the deployment or DaemonSet.

Steps:

  1. Locate and Decide the revision to which we want to rollback
  2. Roll back to the mentioned revision version

So, at first, let us try to find the revisions made in the history for us to choose a rollback version.

kubectl rollout history daemonset <daemonset-name>

The above command lists the history of all the revisions along with the change-cause of every revision. We can choose a particular revision from the output.

Usually, the change-cause for the revisions gets recorded from the DaemonSet annotation kubernetes.io/change-cause upon creation.

If we wish to roll back to the last revision, we can exclude this step.

We can also view specific details around the revision of the DaemonSet using the below command–

kubectl rollout history daemonset <daemonset-name> --revision=2

Post selection of the rollback version now is the time to roll back to that version-

kubectl rollout undo daemonset <daemonset-name> --to-revision=<revision>

Using the above command, we can easily roll back to the specific version at ease!


Conclusion

By this, we have reached the end of this topic. Feel free to comment below, in case you come across any questions.

For more such posts related to Kubernetes, Stay tuned with us.

Till then, Happy Learning!! 馃檪

Leave a Reply

Your email address will not be published. Required fields are marked *

close
Generic selectors
Exact matches only
Search in title
Search in content