Comment by dragonsh | Hacker News Reader

Comment by dragonsh | Hacker News Reader

Parent Full thread

Many things are easier in LXD, like building a highly available, fault tolerant cluster of container and vm-instances.

You can deploy on the cloud of your choice or directly on bare-metal.

You can use REST API, Python API, Golang API, PHP API, Puppet, Chef, Ansible, Dockerfile, Fabric, Capistrano or shell scripts whatever you are familiar with to build container or VM images and also manage running instances. You are not limited by Dockerfile format with mixture of shell scripts only to built images. It's a much easier way to handle containers then learning the complexity of Dockerfile, Kubernetes, Help Charts various YAML (designed for google kind of operations for billions of users).

Just check https://www.youtube.com/watch?v=RnBu7t2wD4U and see how easy it is to setup 3 node fault tolerant cluster. Now with 4.3 it's mature and very resilient.

It's more secure by default than an equivalent Docker or Kubernetes based system as it runs VM and Containers in user namespace for a very long time since LXC 1.0 release. Docker itself started it's life with LXC and moved away from it and became popular with marketing and venture capital money.

> Many things are easier in LXD, like building a highly available, fault tolerant cluster of container and vm-instances.

What features of LXD enable fault tolerance and high availability?

> It's more secure by default than an equivalent Docker or Kubernetes based system as it runs VM and Containers in user namespace

What is the basis for this claim? K8S and Docker also runs everything in user namespaces by default, so why is LXD more secure?

> What features of LXD enable fault tolerance and high availability?

Check more details on https://linuxcontainers.org/lxd/docs/master/clustering.html

> What’s the basis of claim

Kubernetes started with docker and docker image formats. Docker started its life by using LXC. Later on Docker moved to directly use underlying cgroups and namespaces to built it’s own library in the meantime LXC reacheD 1.0 version which support running a container as unprivileged user. For a very long time Docker container, runtime and kubernetes could not get this feature of running containers as unprivileged users. Later they added support when both docker and kubernetes including the managed services from amazon and google suffered from security vulnerability due it. This vulnerability did not impact LXD/LXC as they by default always run container as unprivileged user, it still affected the containers run as privileged by choice. Now a days LXD use new kernel feature called shiftfs (https://discuss.linuxcontainers.org/t/trying-out-shiftfs/515...) to map users between container and host.

Also Docker Containers did not support init process with pid 1 resulting in zombie processes (https://forums.docker.com/t/what-the-latest-with-the-zombie-...). LXD containers do not suffer from this problems from the very beginning.

As I mentioned in my earlier posts Docker became popular due to marketing and a lot of venture capital going into it, not because of superior architecture or better technology. LXD/LXC is still one of the best solution for system containers even though there are many docker related options with CRI, CRD, runc, containerd, moby, podman, kata etc.

Instead of taking my word for it try to setup a HA cluster using LXD and then setup kubernetes you will know what I mean. One of the good project out of LXD is called dqlite[1], chek it.

[1] https://dqlite.io/

User namespaces remapping is still not supported in Kubernetes, see https://github.com/kubernetes/enhancements/issues/127

Reply on news.ycombinator.com