5 minute primer for networking in k8

There are three commandments from the networking gods on high when it comes to Kubernetes networking.

Commandment 1:  Thou shalt allow all Pods to connect with all other Pods and never even think of the letters NAT (network address translation)

Commandment 2: Thou shalt allow all nodes to communicate with all Pods and all the PodS with any node without ever pondering the letters N.A.T.

Commandment 3: Thou shalt treat all IP addresses as equal, even the one assigned to the POD itself. 

So basically every Pod has its own IP address.  

In this primer we will keep things very simple but this should hopefully give you a good starting point as you scale your networking knowledge for more complexity.

Also, you may want to warm up the abstraction parts of your brain for this one because we heard you liked abstractions so we put some abstractions inside your abstractions...Ok back to Kubernetes networking.

So you’ve got your Pods.  Each Pod has its own IP, BUT most of the time no one cares about what the specific IP address is.. Sorry Pod no hard feelings you’re just one face in the crowd.  What we actually care about is what the Pod does.

Here is where we create services (keyword alert) to logically group instances of the same Pod together.  When someone wants to access that particular type of Pod they will look for the corresponding service NOT the individual Pod IP.  

By the way the service is more of an API object than anything tangible but if we start questioning the tangible reality of most of this containerized world then this whole dream falls apart real quick...so moving on.

Services come in three flavors: Cluster IP, Node Port, and Load Balancer.  The Cluster IP is the IP that represents all of the Pods sitting behind the service, Node Port helps you load balance between the actual nodes in your network and the Load Balancer is similar but is more so used for scaling up and down in a hosted cloud environment.

“But wait!” you exclaim, “how can I make this work in a cloud provider?”  I’m glad you asked and fear not the way forward lies in more abstraction, hang in there with me we are almost done.

Ingress Controllers are how you are going to make all this work in an actual cloud environment. 

To do that you will need two special nodes called ingress nodes (two because we like redundancy and one is none, two is one).  Each of those nodes have traffic load balanced between them from the edge of the cluster. 

When the traffic arrives at these special snowflake nodes they will hit a load balancer service.  This is the same as the service before remember? Except this one is load balancing to a load balance...loadception.

Those services will then move the traffic the Pods behind them (again just like before) which are in fact Ingress controller Pods.

Finally these Pods will hop the traffic to the service (node port flavor) that then load balances one more time among the different nodes that have the Pod type we are looking for and just kidding those get load balanced again when they arrive at the actual node.

This is a simple breakdown but it should help you orient yourself when all the jargon and concepts get thrown at you in your next networking call on k8 based environments.  

Until next time keep thinking abstract and balancing.