Azure & Cross-Host Container Networking using Rancher

Introduction

Today we’ll try to understand a bit more about the Rancher cross-host networking capabilities.

Networking

Rancher supports cross-host container communication by implementing a simple and secure overlay network using IPsec tunneling. To leverage this capability, a container launched through Rancher must select “Managed” for its network mode or if launched through Docker, provide an extra label “–label io.rancher.container.network=true”. Most of Rancher’s network features, such as load balancer or DNS service, require the container to be in the managed network.

Under Rancher’s network, a container will be assigned both a Docker bridge IP (172.17.0.0/16) and a Rancher managed IP (10.42.0.0/16) on the default docker0 bridge. Containers within the same environment are then routable and reachable via the managed network.

Note:The Rancher managed IP address will be not present in Docker meta-data and as such will not appear in the result of a Docker “inspect.” This sometimes causes incompatibilities with certain tools that require a Docker bridge IP. We are already working with the Docker community to make sure a future version of Docker can handle overlay networks more cleanly.

Source : http://docs.rancher.com/rancher/concepts/#networking

So in short… You can create a virtual network spanned accross all hosts using Rancher. At the time of writing, this is still based upon an IPsec VPN implementation underneath, where RancherLabs is looking to implement the “new” overlay networking of the native Docker. Be aware that Weave is also pretty known, and used, within the community. Though at this point I want to keep it as simple as possible…

High Level Setup

Anyhow, let’s look at our labo for the day…

Drawing1

Continue reading “Azure & Cross-Host Container Networking using Rancher”

Advertisements

Network virtualization ; Do I go for NVGRE or VXLAN with vNext?

With Windows 2016 / vNext the network virtualization has made a fundamental change… In 2012 Microsoft only supported its own NVGRE protocol. With the upcoming release, Microsoft will support both NVGRE and VXLAN! It even goes so far that VXLAN will be the default protocol. So in terms of VHS vs Betamax, we can conclude that Microsoft has decided that the market is more in favor of VXLAN.
  
What does that mean for organizations that have already implementee NVGRE? Both protocols will be supported by the typical Mellanox of Chelsio adapters in terms of translations. The HNV (Hyper-V Network Virtualization) will also support both simultaneously. Though if you are looking to start a new implementation, it is best to go for VXLAN now!