4 ms·
Possibly an unpopular opinion, but I believe one could easily build a better platform than Kubernetes as it sits now on top of LXD. The amount of features baked
by hardwaresofton 8y ago
Possibly an unpopular opinion, but I believe one could easily build a better platform than Kubernetes as it sits now on top of LXD. The amount of features baked into LXC and exposed by LXD is bonkers.
LXC doesn't have the flexibility (for example you can't just add another runtime underneath it), but the amount of features it has packed in it could have given earlier k8s versions a run for their money. Also, a lot of the implementation flexibility that Kubernetes is seeing now (ex. runtimeClass) is the result of years of inflexibility and people finding ways to work around it (frakti, etc) and build at a slower pace (which is also a good thing, slow measured progress and all that) -- my point is that LXC might have have been the better base, all things equal.
Moving VM workloads right into LXD without needing to port them to be "cloud native" might have saved people a bunch of time, never having to deal with complexities of overlay networks (as long as you could set up LXD properly) would also likely have saved people some time.
- gtirloni 8y agoI think it's debatable if adopting LXC/LXD early in the project would have helped. In any case, all you have to do these days is to satisfy the Container Runtime Interface (CRI). https://github.com/ktsakalozos/lxdlet https://github.com/ktsakalozos/lxdlet https://github.com/enzian/kube-lxd https://github.com/enzian/kube-lxd
- hardwaresofton 8y agoI did not know these existed, thank you so much. I was going to try and write an runtimeClass-compliant operator or a containerd v2 runtime for LXD system containers one of these weekends. kube-lxd and lxdlet seem pretty old though containerd has moved at breakneck speed in the last year... Looking through the code it might need some TLC