Cloud Computing

5 Mins Read

3 Types of Cluster Networking in Kubernetes

Orchestration of Containers is one of the most discussed topics in the industry today. Undoubtedly, Docker changed the data center outlook and made way for microservices in the IT industry.

Kubernetes emerged as an amazing tool that has revolutionized the way we do things at work. Kubernetes provided a great deal of flexibility for orchestrating how containers behave and how they communicate with each other. It’s networking implementation is done differently when compared to Docker. Docker networking had limitation like, inter-host container communication was complicated.

So, before understanding Kubernetes networking across pods and hosts or how to reach a pod from an external network, we will have to first understand how is networking implemented in Docker.

Docker networking is limited within the host itself. By default, it creates a virtual bridge named as docker0 and for each container it allocates a virtual ethernet (veth) which gets attached to the bridge docker0. veth to eth0 mapping is done using Linux namespace. So, in Docker two containers can communicate with each other if they reside on the same host.

But, if we need pod communication across host, the containers must be allocated a host port and the packets are forwarded from host port to the containers. This too has its own limitations, two containers on same host cannot share the same host port.

 

 

Kubernetes tried to address these problems and categorized the basic container networking into 3 types:

  1. Intra pod communication of containers using docker0
  2. Cross node pod-to-pod communications with Service ClusterIP
  3. Cross node pod-to-pod communication with Service NodePort

The concept of pod was introduced with Kubernetes. Kubernetes defined a pod as a set of containers that share resources deployed on a single host and would be named as a pod. In case a container doesn’t have any sharing resources then pod is equivalent to that single container.

To understand it better I have done the pictorial representation of Host, Pod and Containers. Host has two pods deployed on it. Pod A has two containers running in it and Pod B has only one container.

 

1. Intra pod communication of containers:

All the containers in a pod will be assigned the same IP address. So, all containers can directly communicate with each other’s port on localhost within the pod as they share the same IP address and network namespace.So, this implies that containers within a pod will have to coordinate usage of port like VMs do. This is also called “IP-per-pod” model.

 

But, the drawback here is when a pod goes for reset, the IP address assigned to the pod would be released. Again, when the pod is deployed it can get scheduled on the same host or any other host. So, it would be difficult for other pods to communicate with each other as IP address of a pod is not persistent across reboots.

Hence, for Pod to Pod communication IP address of pods should be known and it’s difficult to maintain the IP address across reboots. To overcome this issue a new type of resource is introduced in Kubernetes named as Service.

A Service is a type of Kubernetes resource that acts as a proxy which forwards requests to a set of pods that provide same functionality. Based on the label and selector, the pod set is defined which will receive the forwarded traffic from the Service.

 

  • Cloud Migration
  • Devops
  • AIML & IoT
Know More

2. Service with ClusterIP:

This type of Service will provide discovery and load balancing across pods only inside the Kubernetes cluster, through a cluster-wide common ClusterIPaddress. ClusterIP is assigned out of a dedicated address range and will remain for the life of the Service. Through a set of iptables rule the ClusterIP maps to all the pod’s IPs belonging to the set.clusterIP- service.yml

ClusterIP exposes the service on a cluster-internal IP. This IP address makes the service only reachable from within the cluster. This is the default ServiceType.

$kubectl get svc nginx -o wide

The above snippet shows that a service of type Cluster-IP is created which would accept traffic on port 8080 from other pods and forward the traffic on port 80 of the pods with nginx label. Pods expose endpoints which is maintained by the Service. If the pod resets, it’s endpoint is automatically removed. You can display the endpoints by describing the Service.

The disadvantage with this type of service is that, its only accessible within the cluster and if we want to reach the pods from outside the cluster we will have to use NodePort type of service.

3. Service with NodePort:

NodePort exposes the Service with a public IP of Node and a static defined port, so that the pod can be reached from the external network. A Service proxy is created both in case of ClusterIP and NodePort service types and that Service proxy load balances the traffic to the Service endpoints.nodePort-service.yml

$kubectl get svc nginx -o wide

 

In the above snippet, port 8080 is the Service’s internal port which would be used for the communication within the cluster. Port 31000 is the NodePort, which is a system selected port from the predefined range. The Kubernetes master allocates a port from a pre-configured range (port range: 30000-32767) and each Node will proxy the same port to the created nginx service. With NodePort type of service configured we can access our Service through public IP address of any node hosting nginx pod and the allocated NodePort.

 

Hope this article gives a clear understanding about Docker networking and how in Kubernetes communication across pods and hosts is attained and also how to reach a pod from an external network in a Kubernetes cluster setup. So, with this we understand that Kubernetes provides a great deal of flexibility for orchestrating how containers behave, and how they communicate with each other.

You can learn more about Docker Containers and Container Orchestration with Kubernetes by enrolling for our below stated courses:

Please post your queries if any in the comments section below. Also, if you like the article please share it with others.

 

Get your new hires billable within 1-60 days. Experience our Capability Development Framework today.

  • Cloud Training
  • Customized Training
  • Experiential Learning
Read More

WRITTEN BY CloudThat

Share

Comments

  1. Ruchika Baweja

    Dec 13, 2018

    Reply

    Excellent, extremely clear and to the point.

  2. Mamta Jha

    Sep 5, 2018

    Reply

    Thank you all for your compliments.

  3. Shilpa

    Aug 31, 2018

    Reply

    Hello Mamta,
    Could you please provide a reference to understand on how the pods in 2 different AKS clusters(cluster A and Cluster B of same resource group) would communicate with eachother ?

  4. NRI Legal Services

    Aug 24, 2018

    Reply

    Hurrah! Finally I got a website from where I know how to really take valuable data regarding
    my study and knowledge.

  5. Click Here

    Aug 23, 2018

    Reply

    I like this web blog it’s a master piece! Glad I detected this on google.

    • Mamta Jha

      Aug 23, 2018

      Reply

      Thanks alot.

  6. Mahesh

    Aug 13, 2018

    Reply

    Can you explain about Headless service as well?

  7. srikanth

    Jun 12, 2018

    Reply

    Good One.. It helps in understanding the networks inside the K8s.. do you have any indepth coverage on SDN’s or CNI’s or which type of network CNI to use like flannel,weaver canal…

  8. yogesh

    Apr 30, 2018

    Reply

    Very nice explanation!

  9. teju k

    Mar 9, 2018

    Reply

    Well written article. Thank you for sharing with us. Please keep Sharing.

  10. IT certification courses in Chennai

    Feb 27, 2018

    Reply

    Thanks for sharing the 3 types of cluster networking. It is very useful for me.

  11. Click to Comment

Get The Most Out Of Us

Our support doesn't end here. We have monthly newsletters, study guides, practice questions, and more to assist you in upgrading your cloud career. Subscribe to get them all!