Module 8: Kubernetes Networking & Ingress

---

Introduction

Networking is one of the most critical aspects of Kubernetes. Every Pod needs to communicate—either with other Pods, Services, or external clients. Kubernetes has its own unique networking model to ensure this works seamlessly. In this module, we’ll explore Kubernetes Networking basics and then dive into Ingress, which allows you to manage external access to your applications in a powerful and flexible way.

---

1. Kubernetes Networking Basics

Kubernetes networking follows a few core principles:

• Each Pod has its own unique IP address This eliminates the need for port mapping inside the Pod.

• All Pods can communicate with each other directly (without NAT). Kubernetes uses a CNI (Container Network Interface) plugin (e.g., Flannel, Calico, Cilium) to achieve this.

• Service discovery is built-in through Cluster DNS.

  • When you create a Service named my-service, it gets a DNS name like my-service.default.svc.cluster.local.

  • Pods can access services using these names instead of IPs.

Example: A frontend Pod can connect to a backend Pod via http://backend-service:8080.

---

2. Ingress Overview

So far, we’ve used ClusterIP, NodePort, and LoadBalancer services. But these have limitations:

• ClusterIP: Accessible only inside the cluster.

• NodePort: Exposes apps on every node, but not flexible.

• LoadBalancer: Works well but each Service gets its own external IP (expensive & less scalable).

This is where Ingress comes in.

What is Ingress?

• Ingress is an API object that manages external access to services in a cluster.

• It provides HTTP and HTTPS routing based on rules.

• Instead of exposing multiple LoadBalancers, you expose one Ingress Controller that routes traffic smartly.

Ingress Components

1. Ingress Controller → The actual implementation (NGINX, Traefik, HAProxy, AWS ALB, GCP Ingress, etc.).

2. Ingress Resource → Defines rules for routing (hostnames, paths, TLS).

---

3. Ingress in Action (Hands-On Example)

Step 1: Deploy a Sample Application

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
      - name: hello
        image: nginx
        ports:
        - containerPort: 80

Step 2: Create a Service

apiVersion: v1
kind: Service
metadata:
  name: hello-service
spec:
  selector:
    app: hello
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Step 3: Define an Ingress Resource

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: hello-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: hello-service
            port:
              number: 80

👉 Now, when you hit http://myapp.example.com, traffic goes through the Ingress Controller and is routed to your hello-service.

---

4. Real-World Use Cases

• Single Entry Point: One IP/DNS for multiple apps.

• Path-Based Routing:

  • /api → Backend service

  • / → Frontend service

• Domain-Based Routing:

  • shop.example.com → Shopping app

  • blog.example.com → Blog app

• TLS Termination: Secure apps with HTTPS using certificates at the Ingress level.

---

5. Diagram – Kubernetes Ingress Architecture

Imagine this flow:

🌐 User Request → Ingress Controller → Ingress Rules → Target Service → Pods

Conclusion

In this module, we explored how Kubernetes networking works and how Ingress simplifies external access to applications. Instead of exposing multiple Services via LoadBalancers, you can centralize and control all routing through Ingress Controllers.