4 ms·
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 cou
by merb 10y ago
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.
- puzzle 10y agoYou 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`.
- merb 10y agowith 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.
- puzzle 10y agoI'm sure there are good use cases for Fleet, but running Kubernetes (or anything else) with just one master is asking for trouble.