Monitor Ready status from node

[0SkillAllLuck]

Monitor the ready status from the node itself instead of using the leader controller.
This prepares for worker-only installs where there is no controller in the k0sctl config file, but instead only a join token is used.

Fixes #327

[0SkillAllLuck]

It might make sense to also make DrainNode, UncordonNode and DeleteNode run on the node itself? Those are operations that might need to work on a worker-only install as well and are currently running on the leader which wouldn't be available during worker-only installations

[0SkillAllLuck]

GetClusterID is probably fine as it should be used in a worker-only installation

[kke]

I wonder if it could check if the node is actually part of the cluster it's supposed to 🤔

DrainNode, UncordonNode and DeleteNode from the worker is only possible if the worker is working, maybe that is something that needs to be done separately for the k0sctl worker add or whatever the mechanism to do worker-only runs will be.

I recall the original intention of that was to make it usable from cloud-init or such, a single command that can install the current host as a worker to an existing cluster with just a join token. I don't know if it needs to know how to remove one.

[0SkillAllLuck]

I wonder if it could check if the node is actually part of the cluster it's supposed to 🤔

GetClusterID between a controller and workers should probably be the same then. So that could be checked.

DrainNode, UncordonNode and DeleteNode from the worker is only possible if the worker is working, maybe that is something that needs to be done separately for the k0sctl worker add or whatever the mechanism to do worker-only runs will be.

I guess that makes sense.

I recall the original intention of that was to make it usable from cloud-init or such, a single command that can install the current host as a worker to an existing cluster with just a join token. I don't know if it needs to know how to remove one.

Isn't this kinda handled already with k0s install. I mean the cloud-init case. I thought it meant having the option to join nodes to an existing k0s cluster with just setting a token field in the k0sctl config file and no defined controller, which would require all node operations to be handled by the node itself.

[kke]

GetClusterID between a controller and workers should probably be the same then. So that could be checked.

What a node can access with the permissions it gets from the kubelet.conf is quite limited.

Isn't this kinda handled already with k0s install. I mean the cloud-init case. I thought it meant having the option to join nodes to an existing k0s cluster with just setting a token field in the k0sctl config file and no defined controller, which would require all node operations to be handled by the node itself.

I think both are valid uses, @jnummelin may remember the intended use-case.

[0SkillAllLuck]

What a node can access with the permissions it gets from the kubelet.conf is quite limited.

Was just an idea to check if the clusterId is the same for the node and controllers. That would guarantee the node is in the correct cluster. Just checked and kubelet.conf gives access to the required configmaps.

[kke]

Seems like a valid way to validate then.