CKA Study notes - Kubernetes Networking
Overview
This post is part of my Certified Kubernetes Administrator exam preparations. Time has come for the Networking concepts in Kubernetes.
Networking in Kubernetes is in a way simple, but at the same time complex when we pull in how to communicate in and out of the cluster, so I'll split the posts up in three, covering Cluster & Pod networking (this post), Services, and Ingress.
As for the CKA exam the Services & Networking objective weighs 20% of the exam so it is an important section.
Again, as mentioned in my other CKA Study notes posts, there's more to the concepts than I cover so be sure to check the documentation.
Note #1: I'm using documentation for version 1.19 in my references below as this is the version used in the current (jan 2021) CKA exam. Please check the version applicable to your usecase and/or environment
Note #2: This is a post covering my study notes preparing for the CKA exam and reflects my understanding of the topic, and what I have focused on during my preparations.
Kubernetes networking
Kubernetes Documentation reference
As this is the first of my posts on Kubernetes networking we'll touch upon a few concepts concerning the Kubernetes networking model and how Pods can communicate. Specifics on Services and Ingress will come in later posts.
At the heart of the networking model is that all Pods gets assigned an IP address. This means that a Pod can be viewed as a normal VM or Physical host when it comes to networking.
Kubernetes standardizes the container networking on CNI (Container Networking Interface). Using CNI lets a cluster administrator select the networking implementation which suits the requirements best and install that.
Network implementations
Different implementations have different capabilities, but all are required to follow a few requirements. The most important being
- Every Pod gets an IP address
- Pods on a node must be able to communicate with pods on all nodes without NAT
- Agents on a node (kubelet, system daemons etc) must be able to communicate with all pods on that node
- Pods in the host network of a node can communicate with all pods on all nodes without NAT
As mentioned, all Pods will get an IP address assigned, which is shared by the containers inside that Pod. The containers inside a Pod will communicate between themselves using the loopback (localhost
) interface. Note that this interface is the Pod's (virtual) network interface, not the Node's
When a container in a Pod needs to communicate with a container in another Pod on the same node the communication will go through the Pod's virtual interface card in it's own networking stack, to a virtual interface card for the Pod in the Node's networking stack, which forwards the traffic to the second Pod's virtual interface on the same node's networking stack, then to the Pod's virtual interface in it's own network stack, and finally it hits the destination Container.
When going out of a node and to another node, or even outside of the cluster things get a bit more complicated. We could have handled all of this by utilizing normal well-known networking concepts, like broadcast messages, static or dynamic routing etc. But because of the highly dynamic nature of a container environment, that doesn't scale. And that's where the different network implementations come in to play and how they are often using an Overlay
network or a special routing feature, or a combination, to handle this.
An Overlay implementation will encapsulate the network packets going from a Pod on one Node to a Pod on a different Node in a way that the physical network moves the packets from node to node, and the networking plugin on the receiving node will decapsulate the packet and ensure that it reaches the destination Pod.
The CNI plugins handles also the assignment of IPs to the Pods and keeps track of the assignments in a IP Address Management system (IPAM), often specific and internal to the CNI plugin.
Check out the Illustrated Guide to Kubernetes Networking for an illustrated view of this
A list of different implementations can be found here
Network Policies
Kubernetes Documentation reference
As stated previously all pods can reach eachother by default. In many cases this is not wanted, and we need to be able to restrict the traffic coming in, going out and between pods. For this we can implement Network Policies
A Network policy is implemented by the Network CNI plugin. Meaning that based on your plugin you will have different capabilities in your policies.
Where a Pod without a Network policy accepts all incoming and outgoing traffic, a Pod with a policy rejects everything that is not specified, e.g. implementing a zero-trust model.
Both Ingress and Egress can be specified, and if e.g. Egress is omitted, the policy doesn't affect outgoing traffic from the Pod.
Another thing to note is that policies are additive and if multiple policies are created against the same Pod, the union of these are the resultant set. The order of policy evaluation doesn't matter.
Let's take a look at a Network Policy example:
1apiVersion: networking.k8s.io/v1
2kind: NetworkPolicy
3metadata:
4 name: <network-policy-name>
5 namespace: <namespace>
6spec:
7 podSelector: {}
8 policyTypes:
9 - Ingress
10 - Egress
11 ingress:
12 - from:
13 - ipBlock:
14 cidr: 10.0.1.0/24
15 ports:
16 - protocol: tcp
17 port: 80
18 egress:
19 - to:
20 - ipBlock:
21 cidr: 10.0.2.0/24
22 ports:
23 - protocol: tcp
24 port: 443
For more info on Network Policies check out the documentation
Summary
Networking in Kubernetes is both easy and complex, and for sure the concept I'm struggling the most with. Check out my post on Services and Ingress for two other concepts in the world of Kubernetes networking.
As always, be sure to refer to the Kubernetes documentation for more on the concepts. This is especially important for the CKA exam. The documentation is available in the exam environment, so be sure to use it.
If you want to learn more, and enjoy video resources, I can recommend the free KubeAcademy PRO series from VMware, the Networking course has really helped me in understanding the concepts.
Thanks for reading, if you have any questions or comments feel free to reach out