Live data from Hacker News

One way to make containers network: BGP

jvns.ca

1–10 of 71 posts

Re: One way to make containers network: BGP

#4
post #3
post #2

Oh boy. And containers were supposed to make things easier .

You could just have every container get a magic IPV6 address that just works. https://www.zerotier.com/community/topic/67/zerotier-6plane-... Full disclosure: this is ours.

Or you could just give every container a real IPv6 address, no need for any magic...

Re: One way to make containers network: BGP

#5
post #4
post #3

Earlier quoted context omitted.

You could just have every container get a magic IPV6 address that just works. https://www.zerotier.com/community/topic/67/zerotier-6plane-... Full disclosure: this is ours.

Or you could just give every container a real IPv6 address, no need for any magic...

Nothing against that either but some people can't do it due to hybrid deployments, providers that don't give you a /64, or providers that don't offer V6 at all.

Currently Amazon, Google, and Azure have no native IPv6 support.

Also many are allergic to the security implications. You have to be rigorous with ip6tables and making sure everything speaks SSL or another encrypted protocol using authentication in both directions. Many things do not support SSL or don't support bidirectional auth.

Personally I doubt overlay networks are going away. Most backplane software like databases, distributed caches and event servers, etc. offers literally no security because it's all built with the assumption that it will run on a secure backplane. I have personally railed against this for years but I've found that it's a total waste of breath.

Re: One way to make containers network: BGP

#6
It's really not that difficult to network containers. We're using flannel [1] on CoreOS. We're using flannel's VXLAN backend to encapsulate container traffic. We're Kubernetes users so every kube pod [2] gets it's own subnet and flannel handles the routing between those subnets, across all CoreOS servers in the cluster.

I was skeptical when we first deployed it but we've found it to be dependable and fast. We're running it in production on six CoreOS servers and 400-500 containers.

We did evaluate Project Calico initially but discovered some performance tests that tipped the scales in favor of flannel. [3] I don't know if Calico has improved since then, however. This was about a year ago.

[1] https://github.com/coreos/flannel

[2] A Kubernetes pod is one or more related containers running on a single server

[3] http://www.slideshare.net/ArjanSchaaf/docker-network-perform...

Re: One way to make containers network: BGP

#7

It's really not that difficult to network containers. We're using flannel [1] on CoreOS. We're using flannel's VXLAN backend to encapsulate container traffic. We're Kubernetes users so every kube pod [2] gets it's own subnet and flannel handles the routing between those subnets, across all CoreOS servers in the cluster. I was skeptical when we first deployed it but we've found it to be dependable and fast. We're runn…

Even better, Flannel and Calico have merged. See:

https://www.projectcalico.org/canal-tigera/

https://coreos.com/blog/coreos-intel-calico-packet-extend-gi...

https://github.com/tigera/canal

Re: One way to make containers network: BGP

#8

It's really not that difficult to network containers. We're using flannel [1] on CoreOS. We're using flannel's VXLAN backend to encapsulate container traffic. We're Kubernetes users so every kube pod [2] gets it's own subnet and flannel handles the routing between those subnets, across all CoreOS servers in the cluster. I was skeptical when we first deployed it but we've found it to be dependable and fast. We're runn…

Is flannel used in Kubernetes for networking by default? Or is it something that needs to enabled and configured separately?

Re: One way to make containers network: BGP

#10
post #5
post #4

Earlier quoted context omitted.

Or you could just give every container a real IPv6 address, no need for any magic...

Nothing against that either but some people can't do it due to hybrid deployments, providers that don't give you a /64, or providers that don't offer V6 at all. Currently Amazon, Google, and Azure have no native IPv6 support. Also many are allergic to the security implications. You have to be rigorous with ip6tables and making sure everything speaks SSL or another encrypted protocol using authentication in both direc…

Which provider won't give you a /64 (that supports IPv6 at all)?

Even my residential cable provider gives me a /60. Anything less seems absurd.

Post reply on HN