The comparable tool to docker in the LXD ecosystem is lxc. LXD is built a level above lxc.
And for people who don't know what they are talking about general reactivity "isn't right" ... not sure why anybody cares about the opinion of those without the requisite understanding.
In actual functionality, and applications, LXD does not offer the same functionality as K8S, nor does it claim or attempt to do so. The "similarity" you are pointing out is between K8S container runtimes[1] and LXD - and even they are quite different, and there are already many container runtimes.
[1]: https://kubernetes.io/docs/setup/production-environment/cont...
reactivity = relativity?
And as people we must* care about the opinion of people without requisite understanding, because for most pieces of knowledge that is indeed the majority of people. If we ever hope to grow knowledge you normally must get other people involved, so good explanations and keeping in mind the layman when he might wander into the conversation (AKA this thread) is a good idea.
> In actual functionality, and applications, LXD does not offer the same functionality as K8S, nor does it claim or attempt to do so.
k8s manages the orchestration of compute, network, and storage for applications running on a group of machines, LXD fits this same exact description.
> The "similarity" you are pointing out is between K8S container runtimes[1] and LXD - and even they are quite different, and there are already many container runtimes.
LXD is not a container runtime -- lxc is the container runtime. LXD manipulates lxc the same way docker swarm manipulates docker, or kubernetes mainpulates docker/containerd to get things done.
I assume this is hyperbole, but for anyone who is unfamiliar with either system this statement isn't right -- Kubernetes does a lot of things, but first and foremost it is a container orchestration solution. LXD is also that. Literally from the kubernetes website:
> Kubernetes (K8s) is an open-source system for automating deployment, scaling, and management of containerized applications
And from LXD:
> LXD is a next generation system container manager. It offers a user experience similar to virtual machines but using Linux containers instead.
> The core of LXD is a privileged daemon which exposes a REST API over a local unix socket as well as over the network (if enabled).
> Clients, such as the command line tool provided with LXD itself then do everything through that REST API. It means that whether you're talking to your local host or a remote server, everything works the same way.
If you strip kubernetes down to it's essentials, it is a group of one or more machines running kubelet, with one or more running kube-apiserver. The workloads you run on kubernetes are containerized 99% of the time, with RuntimeClass[0] (and previous to that untrusted runtime support) existing as an option to facilitate VMs and other runtimes that can run a container-ish process.
> While is does some things impressively, there is little need for it at this point with KubeVirt and other virtualization on Kubernetes solutions.
This is also not true -- KubeVirt is just one way to do virtualization on Kubernetes, and there are situations where it may not be optimal. Competition is also a good thing -- If you waited for Kubernetes to get easy/proper support for runtimes with user namespacing, you would have been waiting a long time, whereas the LXD ecosystem has had this for a long time.
The Pokemon Go team actually ran kubernetes on LXD for this reason[1], and gained value from it.
[0]: https://kubernetes.io/blog/2018/10/10/kubernetes-v1.12-intro...
[1]: https://www.youtube.com/watch?v=kQslklE5dKs&t=56s