In this short blog post, we will have a closer look to Kubernetes DaemonSets. Daemonsets are similar to Kubernetes Deployments, but they will deploy one and only one single POD per (non-master) Kubernetes node. We will have a closer look at the two possible update strategies of DaemonSets: RollingUpdate (default) and OnDelete.

References

• Kubernetes DaemonSet documentation on kubernetes.io
• DeamonSet Update Strategy on kubernetes.io
• Main Post of this series

Step 0: Access the Kubernetes Playground

As always, we start by accessing the Katacode Kubernetes Playground. We press the launch.sh command and type the following command, so we can use auto-completion together with the predefined alias k for kubectl:

alias k=kubectl
source <(kubectl completion bash | sed 's/kubectl/k/g')

As an example, k g<tab> will be completed to k get. Also nice: k get pod <tab> will reveal the name of the POD(s).

Step 1: Create a DaemonSet

Let us try to create a Deployment converting the ReplicaSet YAML of the penultimate blog post to a DaemonSet:

cat <<EOF | kubectl apply -f -
# ds.yaml
apiVersion: apps/v1
kind: DaemonSet                    #<------------- ReplicaSet -> DaemonSet
metadata:
  name: frontend-ds                #<------------- changed rs -> ds
spec:
  # replicas: 3                    #<------------- remove (not supported on DeamonSets)
  selector:
    matchLabels:
      tier: my-matching-label
  template:
    metadata:
      labels:
        tier: my-matching-label
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3
EOF

# output: daemonset.apps/frontend-ds created

Step 2: Change the Update Strategy to OnDelete

Let us review the update strategy of the DaemonSet as follows

k get ds frontend-ds -o yaml | grep -i -A 2 Strategy

# output:
  updateStrategy:
    rollingUpdate:
      maxUnavailable: 1
    type: RollingUpdate

You can see, that the default update strategy of a DeamonSet is a RollingUpdate. Let us change that to OnDelete for now:

k edit ds frontend-ds
...
  updateStrategy:
    rollingUpdate:
      maxUnavailable: 1
    type: OnDelete          #<-------------- RollingUpdate -> OnDelete

Note: We can choose to keep the rollingUpdate specification, but it is not relevant anymore if the updateStrategy.type is set to OnDelete

Step 3: Change POD Template Image Version

We now edit the file again and change the POD template image version from v3 to v2:

k edit ds frontend-ds
...
    spec:
      containers:
      - image: gcr.io/google_samples/gb-frontend:v2   #<---- v3 -> v2

Then, we check the POD Image version(s):

k describe pod | grep Image:
    Image:          gcr.io/google_samples/gb-frontend:v2

You can see, that the image version has not changed. To trigger a replacement, we need to delete the pod:

k delete pod <tab>

Now, we expect a new POD to be created with the new Docker image:

k describe pod frontend-ds-rt9ns | grep Image:
    Image:          gcr.io/google_samples/gb-frontend:v2

Step 4: Rollout and Rollback

Step 4.1: Rollback History

We can see that there is a rollout history available similar to Deployments:

k rollout history ds frontend-ds

daemonset.extensions/frontend-ds
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

Step 4.2: Rollback

We can rollback to Image version 3 by undoing the previous rollout:

k rollout undo ds frontend-ds
daemonset.extensions/frontend-ds rolled back

This will roll back the image version of the POD template to v3:

k get ds frontend-ds -o yaml | grep -A 1 containers:
      containers:
      - image: gcr.io/google_samples/gb-frontend:v3

However, the PODs will not be updated automatically, and we need to delete the POD to force the update:

k describe pod | grep Image:
    Image:          gcr.io/google_samples/gb-frontend:v2 #<--- old

k delete pod <tab>
pod "frontend-ds-rt9ns" deleted

k describe pod | grep Image:
    Image:          gcr.io/google_samples/gb-frontend:v3  #<--- updated

Step 5: Rolling Update

Now let us change the Update Strategy to RollingUpdate:

k edit ds <tab>
...
  updateStrategy:
    rollingUpdate:
      maxUnavailable: 1
    type: RollingUpdate   #<--- change back OnDelete -> RollingUpdate

Now let us change the version again. This time, we choose v1:

k edit ds <tab> 
...
    spec:
      containers:
      - image: gcr.io/google_samples/gb-frontend:v1   #<---- v1 this time

Since the update strategy is RollingUpdate now, the POD(s) are replaced immediately:

k describe pod | grep Image:
    Image:          gcr.io/google_samples/gb-frontend:v1

Summary

We have created a minimal Kubernetes DaemonSet. First, we have observed that and POD template changes are not propagated to existing PODs if we choose the OnDelete update strategy. In that case, PODs need to be deleted, to trigger the update of the PODs. However, if we choose the RollingUpdate strategy, POD renewal is triggered with any update of the DaemonSet’s POD template.

Previous:

Deployments

Next:

Service (Link to be provided; see the main document)