Hi everybody,
as promised we’re happy to announce LXE, a Kubernetes integration of
LXC/LXD - or in other words a LXD shim.
Why?
Kubernetes has a lot of infrastructure for containers and more and more
integration is done within that. So it makes sense to try to use that
as good as possible.
But: the existing container runtimes are more or less build to be
restarted (on change, on failure, on bugs, on almost everything).
Example: Docker restart (in case of an docker update) means, that all
container dies. Updating a container means: stopping, deleting,
starting.
On the other hand, stateful applications needs to stay online - as much
as possible. Imagine a production MySQL cluster in a big webshop, where
you can’t use Galera (multi master): you want to avoid downtimes as
much as possible. So in the planning phase, you think about what could
go wrong and minimize the risk of unplanned downtimes. Even for
planned downtimes you bring it down to the minimum.
Container runtimes like Docker a crio-o are build for restart. If you
“update” a container, you have to delete it first (downtime) and then
you can start it again. As mentioned earlier: downtime is bad for
production services, which are stateful. In a production database
server, if you have to update a file, doesn’t mean you want to restart
the whole machine.
It’s a common use case to update files in long running instances to
maintain them (new config, new packages, new cron jobs, new …). So
the new thing is: long running services, which should stay online.
LXC/LXD is a perfect fit for that.
Bring LXC to Kubernetes
So in fact, we’ve done it. Kubernetes works together with LXC/LXD and
you can do “kubectl get pods”, “kubectl create” and so on and you have
exactly one API for all your platform services and applications.
Configmaps with LXC? Works.
LXE runs a seperate daemon end extends the API of LXD as a proxy:
Kubelet -> LXE -> LXD.
You have now exactly one API to manage all your platform
services, including your database servers. This is really fantastic.
But what’s about Kubernetes Stateful Sets?
Kubernetes doesn’t prevent container runtimes from deleting/stopping
your container. So Kubernetes can do nothing about that. Kubernetes
itself plays it’s own role in the restarting area and we will try to
work on that as well. But in short: a stateful set doesn’t mean 24/7
online. It just means: if you’re restarted, you will find the same data
again (in most cases). For a production database server, this is not
enough.
The foundation of the system has to guarantee, that it keeps your
container online. LXC/LXD is a rock solid 24/7 online solution and
really good foundation for your data.
Do you like it?
Feel free to use it, create issues, deliver code at
Thanks to all the guys, who worked so hard on LXD/LXC and Kubernetes. We try to give
it back.
Best Regards
Oli