Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Kubernetes isn't using Docker's libnetwork

blog.kubernetes.io

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Why Kubernetes isn't using Docker's libnetwork

#31

Post by 23david »

jkyle wrote: post #15
jjn2009 wrote: post #12

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

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

Wow didn't realize they'd deprecated lxc. Thx for pointing that out.. that seems to leave all the projects relying on libvirt for container support in an odd spot? I thought that Openstack for example used libvirt-lxc for their container (non-docker) support?

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

Re: Why Kubernetes isn't using Docker's libnetwork

#32

Post by strcat »

23david wrote: post #31
jkyle wrote: post #15

Earlier quoted context omitted.

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

Wow didn't realize they'd deprecated lxc. Thx for pointing that out.. that seems to leave all the projects relying on libvirt for container support in an odd spot? I thought that Openstack for example used libvirt-lxc for their container (non-docker) support? "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…

They have systemd-nspawn as a lightweight interface to the container features (namespaces, control groups).

Re: Why Kubernetes isn't using Docker's libnetwork

#33

Post by foreign-inc »

23david wrote: post #30
foreign-inc wrote: post #22

FWIW, it is coming from the very top. https://twitter.com/solomonstre/status/687773282104287232

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

yeah. This was the tweet.

Re: Why Kubernetes isn't using Docker's libnetwork

#34

Post by steilpass »

strcat wrote: post #32
23david wrote: post #31

Earlier quoted context omitted.

Wow didn't realize they'd deprecated lxc. Thx for pointing that out.. that seems to leave all the projects relying on libvirt for container support in an odd spot? I thought that Openstack for example used libvirt-lxc for their container (non-docker) support? "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…

They have systemd-nspawn as a lightweight interface to the container features (namespaces, control groups).

which e.g. is used by the container engine rkt https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.htm...

Re: Why Kubernetes isn't using Docker's libnetwork

#35

Post by 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.

Re: Why Kubernetes isn't using Docker's libnetwork

#36

Post by justincormack »

zwischenzug wrote: post #35

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…

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.

Re: Why Kubernetes isn't using Docker's libnetwork

#37

Post by akanet »

BinaryIdiot wrote: post #28
foreign-inc wrote: post #22

FWIW, it is coming from the very top. https://twitter.com/solomonstre/status/687773282104287232

That status is gone, whatever it was.

I made a few pointed comments about his tone, which may have led (I hope) to the retraction: https://twitter.com/fulligin/status/687865366744150016

Re: Why Kubernetes isn't using Docker's libnetwork

#38

Post by justincormack »

rdtsc wrote: post #21
jkyle wrote: post #15

Earlier quoted context omitted.

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

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…

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.

Re: Why Kubernetes isn't using Docker's libnetwork

#39

Post by ibotty »

meshko wrote: post #24

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.

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.

Re: Why Kubernetes isn't using Docker's libnetwork

#40

Post by meshko »

ibotty wrote: post #39
meshko wrote: post #24

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.

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.

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?
Post reply on HN