LXD is not a replacement for docker or for k8s as it offers a different feature set from both of those.
Last I wanted what one of the features it offered, which is a persistent whole OS container, I tried to install LXD on fedora, and after trying to get lxc running, failing to do so and seeing it's horror show of a systemd setup while debugging [1], I looked elsewhere and instead settled for rootless podman with --rootfs.
Well LXD, Docker and k8s have a lot of overlap in functionality and features, so it’s just disingenuous to say otherwise.
For over 90% of startups Docker with k8s is just not necessary and tie them to managed version of specific vendor or cloud provider with higher costs and a lot of overheads. It’s pretty hard for a startup to manage self hosted k8s, given large number of moving parts and management of k8s infrastructure is as big as a task of managing the startup product itself.
LXD is decent enough to build a good high available horizontally scalable cluster on cloud of your choice or bare metal and can be managed by startup teams. Obviously once the startup begins to reach millions of customers and users and have enough revenue than k8s might be viable.
In majority of the projects LXD provides much better infrastructure.
> Well LXD, Docker and k8s have a lot of overlap in functionality and features, so it’s just disingenuous to say otherwise.
Tractors and cars have a lot of overlap also. They are still different things and people who want one normally do not consider the other as an alternative.
> For over 90% of startups Docker with k8s is just not necessary and tie them to managed version of specific vendor or cloud provider with higher costs and a lot of overheads.
This has not been my experience but at least there are managed k8s offerings from multiple vendors with some intersection of functionality. Sure different vendors have different extensions but there is only one LXD vendor and the support for LXD is kind of flaky in my experience whereas I have ran 3 different k8s distros on my fedora laptop without really breaking a sweat.
> In majority of the projects LXD provides much better infrastructure.
If you are happy with what LXD provides, and if you can actually use it, then great use it. I have yet to be in a situation where I could use it or where I really wanted what it offers. I tried installing it via snap, I tried installing it from copr, I tried manually installing it, then I concluded that I don't actually want anything from it that I cannot get elsewhere.
This is kind of like saying a tractor is safer than a car. LXD does not have the same feature set as docker or k8s.
If all you want is a more secure docker then podman got you covered.
If you want more secure k8s then you will have to wait a bit I guess for https://github.com/rootless-containers/usernetes but the cri-o runtime for k8s does have a rootless mode.
LXD is not a replacement for docker or for k8s as it offers a different feature set from both of those.
Last I wanted what one of the features it offered, which is a persistent whole OS container, I tried to install LXD on fedora, and after trying to get lxc running, failing to do so and seeing it's horror show of a systemd setup while debugging [1], I looked elsewhere and instead settled for rootless podman with --rootfs.
[1] https://github.com/lxc/lxc/blob/master/config/init/systemd/l... does something which ubuntu is very fond off and is the main reason why I stopped using it. They call sysv-style init scripts like https://github.com/lxc/lxc/blob/master/config/init/sysvinit/... from systemd and in my experience this obsecures errors as somethign ends up failing but via systemd it still looks like it is running.