Restart services with handlers

[amimof]

This PR adds Handlers to those roles that have servers that needs to be restarted at the end of each play. Namely:

• containerd
• kubelet
• kube-apiserver
• kube-scheduler
• kube-controller-manager

[anton-johansson]

This looks really interesting! I would love to test this. However, I can't seem to figure out how this helps running only the restart in serial mode? I guess we still want to perform all the work on all nodes in parallell, but only restart in serial (or 50% serial, or similar).

How would you configure this?

[amimof]

@anton-johansson It doesn't add serial. We need another PR for that. But adding would be very simple. Add serial to the plays in install.ymlsomething like:

- hosts: localhost
  connection: local
  roles:
  - certificates

- hosts: etcd
  serial: "{{ serial_etcd | default(-1) }}"
  roles:
  - etcd

- hosts: masters
  serial: "{{ serial_masters | default(-1) }}"
  roles:
  - kube-apiserver
  - kube-controller-manager
  - kube-scheduler

- hosts: nodes
  serial: "{{ serial_nodes | default(-1) }}"
  roles:
  - cni
  - containerd
  - runc
  - kube-proxy
  - kubelet

Also, commit 8e290b9 adds a handler for containerd however wait_for only checks if the socket is created and might not be the best way of checking if containerd is up and ready. #47 would solve this i guess.

[amimof]

@anton-johansson I think you can go ahead and re-open #48 again and rebase once this PR is merged

[anton-johansson]

Aha, okay, that makes sense. So the plan is to run everything in serial, and not just restarts? That's okay with me, just curious.

I'll reopen #48 and I'll see if I can make the appropriate changes.

[amimof]

Aha, okay, that makes sense. So the plan is to run everything in serial, and not just restarts? That's okay with me, just curious.

I'll reopen #48!

Well yeah I can't figure out another way since it would mean that restarts are performed in a separate play which would require a lot of checks to determine if stuff has changed in order to perform restarts. Because we only want to perform restarts if something has changed. No point in restarting stuff if the system hasn't been altered. That is what handlers are good at.

[anton-johansson]

Okay, that's fair enough for me! Thinking about it, if I want pure high availability, it feels good to actually not touch nodes at all that are waiting for "their turn".