
Why Kubernetes isn't using Docker's libnetwork - brendandburns
http://blog.kubernetes.io/2016/01/why-Kubernetes-doesnt-use-libnetwork.html
======
fidget
Nice to finally see it in writing: "Throughout this investigation Docker has
made it clear that they’re not very open to ideas that deviate from their
current course or that delegate control"

~~~
namsral
The team at CoreOS came to a similar conclusion:

> 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/](https://coreos.com/blog/rocket/)

~~~
magicmu
I'm increasingly impressed with CoreOS, especially etcd, and more generally,
using systemd for init. Not that difficult to get up and running either.

~~~
manojlds
I am running Kubernetes on CoreOS in production. Have been very happy with the
setup. Kubernetes docs and community are excellent.

------
namsral
Docker is the monolith of container runtimes.

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.

~~~
matt_wulfeck
This doesn't make sense. As long as docker works well most people don't care
about what's under the hood. For example The Linux kernel is a monolith, but
you wouldn't make the same argument about running your containers on Minix.

~~~
tszming
You are right that both projects are monolithic (and of coz open-sourced), but
it is unfair to compare a VC backed company with non-profit organization.

------
SEJeff
Stuff like this (from Docker Inc, not Kubernetes) is why I'm really glad that
Kubernetes is doing this.

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.

[1]
[https://github.com/docker/docker/issues/13885](https://github.com/docker/docker/issues/13885)

~~~
crb
> I would have already been a Kubernetes user had it not have depended on
> docker so heavily.

You can use Kubernetes with rkt instead of Docker:
[https://github.com/kubernetes/kubernetes/tree/master/docs/ge...](https://github.com/kubernetes/kubernetes/tree/master/docs/getting-
started-guides/rkt)

------
foreign-inc
FWIW, it is coming from the very top.
[https://twitter.com/solomonstre/status/687773282104287232](https://twitter.com/solomonstre/status/687773282104287232)

~~~
23david
Solomon Hykes @solomonstre @kelseyhightower TLDR "no actual downside for
Docker users, but it makes it hard to for us to embrace-extend-extinguish"
Today at 3:08 PM

~~~
foreign-inc
yeah. This was the tweet.

------
zwischenzug
I thought it might be worth highlighting the final section, where some
consequences of this decision have been highlighted:

    
    
       '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.'
    

It will be interesting to see what would happen if a number of significant and
interested enterprise parties unite to embrace runC or similar in earnest,
relegating Docker's solution set to just another implementation. RedHat +
Google + (say) Microsoft and it's game over.

~~~
justincormack
Runc is part of the open containers spec set up by Docker and CoreOS. So it is
Docker's solution as well as the community's. They recently open sourced
containerd which is based on runc so they are clearly embracing it.

------
binaryanomaly
Interesting move. It's obviously still completely open how much the docker
ecosystem can establish itself as a standard besides runC respectively docker
api(cli)/daemon.

------
meshko
I just spent 20 minutes reading various sites, trying to understand what
libnetwork is and failed. Everything either tells me that libnetwork is
awesome or starts showing go source code.

~~~
ibotty
It's docker's networking library. If you want to integrate your networking
into docker and not provide the necessary flags on docker daemon startup, you
will have to integrate mess with it.

~~~
meshko
Not clear. Who am "I" and what is my networking and what i am integrating it
with? Am i a Docker user? Am I setting up a network of a bunch of containers?
Or building some software package that extends docker?

------
jjn2009
Although this is reasonable its upsetting, I hope in time lxc software get
less fragmented.. Docker really should have just gone with CNI.

~~~
jkyle
LXC is deprecated from RHEL 7.x onward.[1] Doesn't that relegate it to "an
Ubuntu thing" status?

1\.
[https://access.redhat.com/articles/1365153](https://access.redhat.com/articles/1365153)

~~~
rdtsc
Or just means Redhat went Docker crazy.

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.

~~~
justincormack
Maybe its what their customers were asking for.

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.

~~~
rdtsc
> Libvirt LXC is designed to make containers appearvlike VMs and is pretty
> heavyweight to set up.

Isn't libvirt just a controlling wrapper? It is basically an abstraction over
various VM-like technologies: KVM, Xen etc.

~~~
justincormack
Yes, but it makes containers pretty heavyweight. XML config files and so on.

------
louwrentius
I feel so silly but I can't help myself. The name 'Kubernetes' is so ugly and
off-putting I hope I never have to use this software.

~~~
kornish
Well, maybe it would help to have some background on the name: Kubernetes is
Greek for 'helsman' or 'pilot' [1].

[1]:
[https://en.wikipedia.org/wiki/Kubernetes](https://en.wikipedia.org/wiki/Kubernetes)

~~~
binaryanomaly
Actually cybernetics originates from kubernetes.

[http://www.etymonline.com/index.php?term=cybernetics](http://www.etymonline.com/index.php?term=cybernetics)

