The objective of this tutorial is to demonstrate how networking is implemented in Kubernetes. Networking in Kubernetes is a broad topic, which cannot be sufficiently covered in a single blog post. The material presented in this post will lay the foundation for presenting advanced material on Kubernetes networking.
At a production level, networking is a critical element for a system to function properly. The different parts of an application need a reliable way of networking with each other. The use of containers and clusters increases the complexity of networking. Networking complexity arises because the networking approach needs to handle the container IP space, networking in different hosts, and networking across different data centers.
The networking model in Kubernetes is based on each pod being assigned an IP address. Although, depending on the infrastructure used, the networking approach varies, there are some characteristics that are common in every networking approach. The first characteristic is that Network Address Translation (NAT) is not allowed for the flow of traffic between containers and between containers and nodes. The second characteristic is the IP address assigned internally to a container needs to match with the IP address the container will be using to communicate. These two networking characteristics, when implemented, are helpful in reducing network complexity and simplifying application design. Another advantage of observing the characteristics is the effort required in updating legacy applications is reduced. The third advantage of maintaining the network characteristics is that the scalability that can be achieved at the level of thousands of services.
The Kubernetes networking model can be implemented in several different ways. This section will discuss the different approaches without giving preference to any approach.
The first approach to networking is Contiv netplugin. Contiv simplifies microservices networking by providing discovery and routing services. Contiv is not just limited to being used with Kubernetes , it can also be used with Docker Swarm, Mesos or Nomad. Contiv does away with any need to use NAT and assigns IP addresses at the container level. The types of networks that can be used with Contiv are; pure layer 3, overlay and layer 2.
To use Contiv you need at least version 5.0.2 of VirtualBox, Vagrant 1.74 and Go 1.5. To install Vagrant, download the appropriate version from here https://www.vagrantup.com/downloads.html. Navigate to the directory where Vagrant was downloaded and install it.
cd /home/sammy/Downloads
sudo dpkg -i vagrant_1.9.1_x86_64.deb
To install Go, use the steps below.
Begin by upgrading packages to make sure you get the most recent.
sudo apt-get update sudo apt-get -y upgrade
After upgrading the packages, download Go using the command below.
sudo curl -O https://storage.googleapis.com/golang/go1.6.linux-amd64.tar.gz
Extract Go, and if you have a preferred installation directory you can move it there.
sudo tar -xvf go1.6.linux-amd64.tar.gz sudo mv go /usr/local
After extracting Go, we need to correctly set the paths. The commands used in the code below to set the path assumes the directory where Go was placed is /usr/local. If Go is in a different location, you need to modify the paths to point to where it is located.
To specify where Go will look for files, open the configuration file using this command sudo gedit ~/.profile. and add this line export PATH=$PATH:/usr/local/go/bin at the end save and close the file.
Reload the configuration file using this command source ~/.profile
To get started with Contiv, we need to clone the repo and start VMs using the commands below.
git clone https://github.com/contiv/netplugin cd netplugin; make demo vagrant ssh netplugin-node1
The second way networking can be implemented in Kubernetes is Flannel. Flannel runs as an agent and is responsible for assigning subnet to each host. Network configuration is stored on etcd. Backends are responsible for forwarding packets. One of the backends that is easy is udp. Using Docker is the least error prone way to use Flannel.
The third way networking is implemented in Kubernetes is Google Compute Engine (GCE). In this approach, assignment of subnet to VM happens through configuration files. Traffic routing to the VM is the responsibility of GCE fabric. When starting Docker, you need to pass a Linux bridge which is referred to as cbr0 to the –bridge flag.
The fourth way networking is implemented in Kubernetes is Open Virtual Networking (OVN). OVN is an open source solution that enables development of different network configurations by creating logical switches, ACLs and load balancers among other network components. OVN can either be used in overlay or underlay mode. The underlay mode allows creation of logical networks that can have containers within Vms without any running containers, and physical machines that are on one logical network. The overlay mode enables creation of logical networks that are made up of containers running on different hosts. For the two modes to function, you need to install and start Open vSwitch on every VM or host where containers will be running.
The fifth approach to networking is Project Calico. Calico provides a virtual network and security network solution for containers, virtual machines and services running on physical hardware. Calico is pre-integrated with Docker, Kubernetes and Mesos. Calico offers deployment options on the premise or in the cloud. The network policy implemented by Calico gives the developer the assurance the flow of packets is the one expected.
The sixth approach to networking is Nuage Networks Virtualized Cloud Services. Nuage provides the link between Kubernetes pods and environments which are not Kubernetes based such as Virtual machines and physical servers.
In this article, we introduced the networking approach used by Kubernetes. We discussed some of the ways in which networking can be implemented in Kubernetes. Although, we discussed Contiv in more details as compared to the other implementations, it does not mean it is superior to the others. In subsequent articles, we will discuss the details of each implementation.
