DaemonSet is a controller designed for system daemons, as its name suggests. Consequently, a DaemonSet controller launches and maintains exactly one pod per node; the total number of pods launched by a DaemonSet controller adheres to the number of nodes in a cluster. Due to this limitation, updating DaemonSet isn't as straightforward as updating a deployment. For instance, deployment has a maxSurge parameter (.spec.strategy.rollingUpdate.maxSurge) that controls how many redundant pods over the desired number can be created during updates, but we can't employ the same strategy for pods managed by DaemonSet. Because daemon pods usually come with special concerns that might occupy a host's resources, such as ports, it could result in errors if we have two or more system pods simultaneously on a node. As such, the update is in the form that a new pod is created after the old pod is terminated on a host.

Kubernetes implements two update strategies for DaemonSet:

• OnDelete: Pods are only updated after they are deleted manually.
• RollingUpdate: This works like OnDelete, but the deletion of pods is performed by Kubernetes automatically. There is one optional parameter, .spec.updateStrategy.rollingUpdate.maxUnavailable, which is similar to the one in deployment. Its default value is 1, which means Kubernetes replaces one pod at a time, node by node.

You can find an example that demonstrates how to write a template of DaemonSet at https://github.com/PacktPublishing/DevOps-with-Kubernetes-Second-Edition/blob/master/chapter9/9-1_updates/ex-daemonset.yml. The update strategy is set at the .spec.updateStrategy.type path, and its default is RollingUpdate. The way to trigger the rolling update is identical to the way in which we trigger a deployment. We can also utilize kubectl rollout to manage rollouts of our DaemonSet controller, but pause and resume aren't supported.