Why Kubernetes isn't using Docker's libnetwork
blog.kubernetes.io
blog.kubernetes.io
> Docker has demonstrated that it is on a path to include many facilities beyond basic container management, turning it into a complex platform.
More than a year ago on their blog, https://coreos.com/blog/rocket/
Continued insistence on that attitude virtually guarantees that they will lose out through refusal to solve problems that people actually have.
I think it’s a step backwards to have a monolithic application like Docker controlling your container runtime when you’ve gone through the effort of developing independent (micro)services.
Containerising software is the way forward and I think Kubernetes and CoreOS have demonstrated to have and support a long term vision.
I'm a Mesos user and absolutely can't wait until the Unified Containerizer bits are finished. The plan is to be able to pull down a docker image and run it as though it was being ran via the docker daemon, but not using docker and instead using the mesos native namespacing and control group bits. I would have already been a Kubernetes user had it not have depended on docker so heavily.
In our mesos environment, the only part we have issues with on a regular basis is docker. First it was the userland proxy and the performance and latency issues it introduced. Then it was the unresolved bug of docker just simply hanging under any sort of load[1] with upstream not really caring at all. Then there are random and difficult to reproduce issues where containers with bridged networking simply stop passing traffic from external interfaces into the containers when nothing has changed etc. So we use docker containers for some things, but try to limit them due to docker simply not being amazing for running production services for some of our use cases.
You can use Kubernetes with rkt instead of Docker: https://github.com/kubernetes/kubernetes/tree/master/docs/ge...
> I react badly to hypocrisy, a known weakness. You should be a maintainer for a week and decide for yourself :)
I'd say that's pattern matches as a humblebrag, except it's more of a... faux-humble pointed insult? "Apologizing" for tone and managing to call someone a hypocrite within so few words is... I struggle for words. Impressive? It leaves an impression.
Good for you for standing up.
'There will be some unfortunate side-effects of this. Most of them are relatively minor (for example, docker inspect will not show an IP address), but some are significant. In particular, containers started by docker run might not be able to communicate with containers started by Kubernetes, and network integrators will have to provide CNI drivers if they want to fully integrate with Kubernetes.'
At some point they were being made fun of for being slow, old fashioned, stuck in the early 2000s. They have to be obviously for stabiliy, but you know word spreads. So around RHEL 7 time they went all crazy trying to show the tech world they are still hip and cool, looked around, saw what the cool kids were talking about -- Docker. So they got themselves some Docker. So now it is Docker, Docker, Docker all day every day.
Naturally now it is uncomfortable to say "yeah well LXC is there, can use that as well or instead of Docker", but that would kind of backpedaling on their Docker bet by having something that competes with it. So they are stripping it out.
Its not like the two things are even targeted at the same use case. Libvirt LXC is designed to make containers appearvlike VMs and is pretty heavyweight to set up. I always preferred using raw kvm or LXC to wrapping it in libvirt which just gets in the way.
Docker is largely for running single applications with lightweight easy to use setup so you can run it constantly.
Isn't libvirt just a controlling wrapper? It is basically an abstraction over various VM-like technologies: KVM, Xen etc.
"Future development on the Linux containers framework is now based on the docker command-line interface. libvirt-lxc tooling may be removed in a future release of Red Hat Enterprise Linux (including Red Hat Enterprise Linux 7) and should not be relied upon for developing custom container management applications."