DaemonSets keep monitoring every Kubernetes node, so when one of the Pods crashes, DaemonSets recreates it on the same Kubernetes node.

To simulate this, go back to the DaemonSets example and use kubectl delete pods to delete an existing Pod from node1 manually, as follows:

$ kubectl delete pod ram-check-6ldng
pod "ram-check-6ldng" deleted

$ kubectl get pods -o wide
NAME              READY     STATUS        RESTARTS   AGE       IP               NODE
ram-check-6ldng   1/1       Terminating   0          29m       10.233.102.132   node1
ram-check-ddpdb   1/1       Running       0          29m       10.233.75.5      node2
ram-check-dpdmt   1/1       Running       0          13m       10.233.71.0      node3

$ kubectl get pods -o wide
NAME              READY     STATUS    RESTARTS   AGE       IP               NODE
ram-check-ddpdb   1/1       Running   0          30m       10.233.75.5      node2
ram-check-dh5hq   1/1       Running   0          24s       10.233.102.135   node1
ram-check-dpdmt   1/1       Running   0          14m       10.233.71.0      node3

As you can see, a new Pod has been created automatically to recover the Pod in node1. Note that the Pod name has been changed from ram-check-6ldng to ram-check-dh5hq—it has been assigned a random suffix name. In this use case, Pod name doesn't matter, because we don't use hostname or DNS to manage this application.