Photo by Lukasz Szmigiel on Unsplash

Kubernetes Networking 101: The Land of Pods, Services, and Fantastical IPs

Welcome, dear traveler, to the whimsical yet occasionally terrifying world of Kubernetes networking. In this guide, we’ll venture through the mysterious lands of Pods, Services, and Network Policies. Along the way, you’ll encounter a lot of magical IP addresses and, if you’re lucky, maybe even get lost in the deep, dark woods of DNS resolution. Buckle up!

Pods: The Basic Unit of Your K8s Adventure

What is a Pod?

A Pod is like the cosy, little cabin in the woods where your application containers live. It’s got everything they need: a shared network namespace, storage volumes, and a localhost where they can chat with each other using 127.0.0.1 (the nerdy IP that says, “I’m talking to myself, but in a professional way”).

Example: Let’s say you’ve got a pod running two containers:

1. web-server (an over-caffeinated Nginx)
2. db-server (a MySQL that’s seen some stuff)

They can talk to each other using localhost, which is like whispering secrets to your roommate in the middle of the night. But when it comes to chatting with other pods, they’ll need to venture out of their cabin.

Pods and Their IPs: The Short-Lived Dream

Every Pod gets its own unique IP address. It’s like a backstage pass to the Kubernetes cluster party, but with a big catch: the pass expires when the Pod is deleted. The IP vanishes faster than free snacks at a tech conference.

The Service: Your Friendly Neighbourhood Router

Services: An Introduction

If Pods are like cabins in the woods, then a Service is the friendly local ranger station. It knows where everyone lives and can redirect traffic accordingly. It’s your go-to for making sure requests reach the right cabin without getting lost in the woods.

Example: You’ve got a bunch of Pods running your web app, but they keep changing their IPs like they’re in witness protection. A Service steps in, gives them a stable IP (the ClusterIP), and says, “You guys want to be called my-web-service now. Just leave the IP stuff to me.”

Service Types: More Options Than Your Local Coffee Shop

1. ClusterIP: The default one. Accessible only within the cluster. It’s like the private clubhouse no outsiders are allowed in.
2. NodePort: Adds a unique port on every Node in your cluster. Great if you want to sneak in from outside but don’t want the neighbors to know.
3. LoadBalancer: The “VIP” service. It goes outside and gets a real-world IP (or several) from your cloud provider. If NodePort is sneaky, LoadBalancer is rolling up in a limo.
4. ExternalName: It’s just a fancy alias, pointing to some DNS outside the cluster. Think of it as saying, “Oh, that’s not our problem. Talk to Bob over there.”

Ingress: The Gatekeeper

Ingress: The Bouncer You Didn’t Know You Needed

So, you’ve got all these Services, but how do people from outside the cluster find them? Enter Ingress, the bouncer at your Kubernetes club. It checks the guest list and directs traffic to the right Service based on rules you define. With Ingress, you can manage HTTP(S) traffic like a pro, setting up host-based or path-based routing.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: my-app.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-web-service
            port:
              number: 80

This fancy piece of YAML tells the Ingress to forward any traffic coming to my-app.example.com to my-web-service. Simple and elegant, like ordering a flat white at your favorite café.

Network Policies: The Bouncers Inside the Club

Network Policies: Pod Security on Steroids

Now you’re running a tight ship, but your Pods are too chatty. How do you stop them from gossiping with each other unnecessarily? With Network Policies, you can lay down the law and control which Pods are allowed to talk to which other Pods.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress: []
  egress: []

This is the ultimate silent treatment. No one’s allowed to talk to anyone. You can build on this to create more specific rules, like allowing only the web server to talk to the database.

DNS in Kubernetes: Because Nobody Likes IP Addresses

CoreDNS: The Magical Phonebook

In Kubernetes, DNS is like the all-knowing phonebook. CoreDNS handles all your DNS needs within the cluster, so your Pods can find each other by name instead of playing the “who’s got what IP today” game.

Example: You’ve got a Service called my-web-service. Any Pod in the same namespace can find it by using the name my-web-service. If it’s in a different namespace, just append the namespace like my-web-service.my-namespace.

It’s like ordering at a fast-food restaurant: “I’ll have a my-web-service with a side of port 80, please.”

Advanced Topics: CNI, Calico, and the Kitchen Sink

CNI (Container Network Interface): The Unsung Hero

Kubernetes doesn’t handle the actual networking itself. Instead, it relies on a CNI plugin to do the dirty work. Think of it as the invisible intern doing all the heavy lifting. Plugins like Calico, Flannel, and Weave provide different networking capabilities, from network policies to IP address management.

Example:

Calico is like the Swiss Army knife of CNIs, with everything from simple networking to complex policies. Meanwhile, Flannel is more like the friendly neighbourhood plumber: basic and reliable.

Debugging: Because It’s Not Always Fun and Games

Common Issues and How to Fix Them

1. Pods Can’t Talk to Each Other: Check your Network Policies. Maybe they’re on a Pod-wide silent treatment.
2. Service Not Accessible: Double-check your Service type and ports. Are you using NodePort and hitting the right port? Is your Ingress configured correctly?
3. DNS Issues: Try nslookup or dig from within a Pod to see if DNS is resolving as expected. If not, check CoreDNS logs.

Conclusion: You’ve Made It!

You’ve navigated the enchanted forest of Kubernetes networking! Now you can confidently deploy your applications, set up Services, configure Ingress rules, and lay down the law with Network Policies. Just remember: with great power comes great responsibility — and occasionally, the need to debug why your Pods won’t talk to each other.

So, go forth, and may your Services always find their Pods, your DNS always resolve, and your network policies keep the gossip to a minimum. Cheers!