I don't get that move. fleet was extremly well suited to schedule a kubernetes high available master.
as soon as you have 3 etcd nodes and 3 fleet nodes you could use fleet to bootstrap kubernetes in a way more stable fashion than all of the other available options.
if people remove the low level tools to manage a cluster it will be harder and harder to bootstrap higher level stuff.
but well, what to expect in the container space, stuff changes there just way too often.
You can do that kind of bootstrap without fleet. Just use ignition or cloud-config with the right systemd units and a bunch of fixed IP addresses. I think the CoreOS folks worked on a number of ways to simplify and automate bootstrapping of the Kubernetes control plane, so they saw fleet as redundant now. Besides, it took a long time for it to get something resembling a mechanism that updates units in the cluster.
That said, being a lower level tool as you point out, it can be useful during e.g. troubleshooting. Imagine the case where `fleetctl list-machines` returns more nodes than `kubectl get nodes`.
with fleet you could have a single kubernetes master that would've been started on another node, as soon as one node would go down. that won't work with just systemd units.
if people remove the low level tools to manage a cluster it will be harder and harder to bootstrap higher level stuff.
but well, what to expect in the container space, stuff changes there just way too often.