K8s Network Policies


In this blog post, let’s try understanding “K8s Network Policy”. We will be following the structure as below.

To start with, let’s lay out some fundamentals for K8s Networking for Pods for a given cluster by default.

  • Each Pod gets its own unique IP address.
  • All Pods can talk with any other Pod within the cluster(there is no NAT business, i.e., Network address translation)

Extending the idea above, a Pod in namespaceA can also talk with a Pod in namespaceB, so the communication between Pods is namespace independent too.

Let’s try to see this with an example. Let’s say we have three namespaces

Let’s create a pod in each namespace

Let’s now try to reach pod2 from pod1 (in different namespaces); we see the connectivity works. Here

Similarly, the pod in ns-2 can talk with the pod in ns-3

Any pod can talk with any other pod in a cluster by default. Something like below.

Communication between pods in each namespace

What if we would like something like below, where in pod in “ns-2” should able to talk with only pod in “ns-3” for incoming connections and nothing else

New requirements for communication between pods

This is where network policies help. Let’s understand how. But before that is there a use-case or requirement for this?

There surely might be a use-case for this; let’s understand with an example.

Let’s say we have a set of pods hosting an application in prod and another set of pods hosting an application in dev. What if we would like the pods in dev not to talk with pods in prod. This is one use-case where Network Policies help.

First, let’s label each namespace and each pod. Check here for more details on K8s labels. This will help us decide which NetworkPolicy to apply to which set of K8s objects(pods, namespaces, etc.)

Let use this example from K8s documentation and apply it for our use-case, i.e., the pods in ns-2 should not be allowed to talk to pods in ns-3, specifically for outgoing requests.

So what we would like is

  1. An ingress request from ns-3 pod3 should be allowed to ns-2 pod
  2. An ingress request from ns-1 pod1 should not be allowed to ns-2 pod

Let’s create a NetworkPolicy object; pay close attention to the podSelector; it helps select pods to apply the ingress policy to. Here it selects pod2 and allows ingress only from pod3.

Let’s see what happens after applying this policy

We can see pod2 allows ingress from pod3 and also pod1, what????????

This clearly isn’t working right? So NetworkPolicy doesnot work?

Well not really let’s see whats happening

This is not working because Network Policy requires networkpolicy agents to be installed.

These are not installed by default on K8s clusters. There are many agents(like calico, weave-net, antrea etc.) , here let’s take a look at a calico agent.

One can install calico from here. After successful installation, we see the below

Now, if we validate, we can see that the ingress policy is applied correctly 🎉. In this example, we saw how to apply the NetworkPolicy K8s object using podselector . One can also use namespace-selector or ipaddress to apply Ingress and Egress policies. One can also use a combination of these methods together.

💡Something else to note is, the Network policy can be applied to a specific port, i.e., the Ingress policy from only port 8080 is allowed on namespace1.

What might be the difference between K8s Network Policy and K8s ServiceMesh? As both seem to control traffic within a K8s cluster

NetworkPolicy works at OSI-Layer3 and OSI-Layer4. It controls traffic using ipaddress, ports or namespace related to the pods.

ServiceMesh works at OSI-Layer7, it uses application properties like header, path etc. to control traffic.

To conclude, NetworkPolicy is an essential K8s object in the modern world where controlling traffic flow and applying better controls is extremely important.

That's it for now related to NeworkPolicy in K8s; if you have any questions/comments/feedback, feel free to add. Until next time ciao!



whoami >> Slack, Prev — Springpath (Acquired by Cisco), VMware, Backend Engineer, Build & Release, Infra, Devops & Cybersecurity Enthusiast

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Sandeep Baldawa

whoami >> Slack, Prev — Springpath (Acquired by Cisco), VMware, Backend Engineer, Build & Release, Infra, Devops & Cybersecurity Enthusiast