DevOps Blog

Introduction to Kubernetes Networking

Toye Idowu
by Toye Idowu
2 minute read

In this blog post, we will introduce Kubernetes networking. This is meant to be an introduction into Kubernetes networking and I assume you have a basic understanding of Kubernetes pods and Kubernetes service and their use cases. If you are not, you can refer to my other posts on these topics.

Before we can understand Kubernetes networking we must first understand what we are trying to solve. There are 3 issues we need to solve in a Kubernetes cluster:

  1. Container to Container communication
  2. pod to pod communication
  3. pod to service communication

Solving for Kubernetes Network Issues

Let us go over each one of the bullet points we mentioned above and how Kubernetes attempts to solves it.

Container to Container Communication

This is solved with the concept of Pods. In Linux, a network namespace contains its own network resources, i.e interfaces, routing tables, etc. This same concept applies to Pods. When a pod is created, it gets a network namespace that the containers in the pod will share resources therefore allowing all containers in a pod to communicate through localhost.

Pod to Service Communication

A service is an abstraction that routes traffic to a set of pods. A service gets its own Cluster IP, the pods also get their own IP’s and when requests need to reach the pods, it is sent to the service Cluster IP and then forwarded to the actual IP of the pods. This way pods(mortals) can come and go without worrying about updating IP’s since by default the service will automatically update its endpoint with the IP of the pod that it targets as those pod changes IP. The way the service knows what pod to target is through LabelSelector. This is an important concept to be aware of since LabelSelector is the only way the service knows what pod to target and keep track of their IP’s.

Pod to Pod Communication

For communication between pods, Kubernetes imposes the following fundamental requirements on any networking implementation:

  • all Pods can communicate with all other Pods without using network address translation (NAT)
  • all Nodes can communicate with all Pods without NAT.
  • the IP that a Pod sees itself as is the same IP that others see it as.

There are plenty of tools we can add to Kubernetes to help us meet these requirements like Cilium which is open source software for providing and transparently securing network connectivity between application containers, Flannel which is a very simple overlay network that simply satisfies the Kubernetes requirements, Kube-router which is a purpose-built networking solution for Kubernetes that aims to provide high performance and operational simplicity. There are plenty of other solids projects we can use outside of the 3 mentioned.

The idea is that when a pod is created, Linux Virtual Ethernet Device or veth pair can be used to connect Pod network namespaces to the root network namespace. Pods on the same node can talk through a bridge. A Linux Ethernet bridge is a virtual Layer 2 networking device used to unite two or more network segments, working transparently to connect the two networks together. For Pods on separate nodes, assuming connectivity between the nodes, request will go from root namespace of one node to the root namespace of other node. The node should then know how to route traffic to the correct pod.

E-Book: Avoid Sticker Shock—How to Determine the True Cost of Clouds

Cost reduction is one of the main reasons for moving to the cloud. Cost reduction is not a guarantee – but is achievable with the right plan. Get insight into the right steps to take for migrating workloads to the cloud and reducing costs as a result.
Read the E-Book ›

These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

About the author

Toye Idowu

Toye Idowu

Olatoye is a Certified Kubernetes Administrator and experienced DevOps/Platform engineering Consultant with a demonstrated history of working in the Information Technology and Services industry.