How to Configure Network on a Kubernetes Cluster- CKA Exam Preparation Series
Sep 14, 2020
How to Configure Network on a Kubernetes Cluster
This is one of the numerous posts by TechCommanders in a series for studying for the Certified Kubernetes Administrator (CKA) Exam.
Become a Certified Kubernetes Administrator (CKA)!
In this post, we will learn how to configure a network on a Kubernetes cluster. We will learn about Kubernetes networking and will also read about the brief overview of Kubernetes pods and Kubernetes service.
What are Kubernetes Pods?
The pod is the smallest building block in a cluster. It represents the system which is running. The inside of a pod may have one or greater containers. A single pod has a-
- A unique network IP
- Storage
- Network
- Any other specification which you might have configured.
In simple words, the pod can be described as a logical host that is specific to your application and holds one or more tightly contained containers. The pod can also act as a constructor which calls or initializes a second container and as soon as the second container is up and running the first one stops its job.
What is the Kubernetes Service?
Kubernetes starts with a pod as earlier we had read that pod is the smallest building block thus it contains all the storage resources which are required to run a container application, multiple containers or also as a singular network IP and operation options.
This gives more flexibility, but Pods don’t live forever. Even though every pod has a single IP, those can’t provide network stability over a long period of time.
We need to make sure that the application’s backend pods, as well as front-end pods, remains functional. This is where Kubernetes as a service also known as KAAS comes into play.
This is the method of how your team should organize, or service, pods and therefore the policy by which your team accesses them. Often called a microservice, this organization depends on the spread of unique variables.
From the dimensions of your team to the traffic your application services, KaaS processes are often flexibly designed to fit your team’s needs.
So, now we are aware of Kubernetes pods as well as of service. Let’s jump into the working of networking in Kubernetes and how we can configure this.
Before we deep dive into the details of networking, we should go through the points which are covered in this post and the problems we are trying to solve. Majorly, there are three issues that we need to solve in the Kubernetes cluster
- Container to Container communication
- pod to pod communication
- pod to service communication
Let’s start learning about them.
- Container to Container Communication: The connection between two containers can be done with the help of pods. If you are aware of Linux network namespace it contains its resources i.e. interfaces, routing tables etc. The same thing can be done in the case of pods.
When a pod is made it is assigned with a network namespace that all the containers within the pod will share the resources with which allows all the containers during a pod to communicate through the localhost. - Pod to Service Communication: At this point, we will check how we can connect a pod with service. A service is an abstraction that routes traffic to a set of pods. A service gets its own Cluster IP and the pods also get their own IP’s. When the 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 IPs since by default the service will automatically update its endpoint with the IP of the pod that it targets as that pod changes IP.
The way the service knows what pod to focus on 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 enabling the communication between two pods, Kubernetes must have the subsequent 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 many open-source tools which can provide transparently securing network connectivity between application containers, Flannel which may be a very simple overlay network that simply satisfies the Kubernetes requirements, Kube-router which may be a purpose-built networking solution for Kubernetes that aims to supply high performance and operational simplicity. I have mentioned three examples but there are plenty of open-source projects which can help you with Pod to Pod communication.
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 an equivalent node can talk through a bridge. Whereas a Linux Ethernet bridge is a virtual Layer 2 networking device which is used to unite two or more network segments, working transparently for connecting the two networks together. For Pods on separate nodes, assuming connectivity between the nodes, the request will go from the root namespace of one node to the root namespace of other nodes. The node should then route to route traffic to the right pod.
Join TechCommanders Today.
Over 60 Courses and Practice Questions!
Coaching and CloudINterviewACE
Stay connected with news and updates!
Join our mailing list to receive the latest news and updates from our team.
Don't worry, your information will not be shared.
We hate SPAM. We will never sell your information, for any reason.
