Kubernetes Services, LoadBalancing & Ingress: Full Summary

🧩 Core Types of Kubernetes Services

---

📦 Pod + Service Relationships

• A Pod can be backed by multiple Services (e.g., one for internal access, another for external).

• Services use label selectors to target Pods.

• Pods are ephemeral — Services offer a stable IP (ClusterIP) + DNS to reliably route to them.

• Even NodePort and LoadBalancer services have a ClusterIP internally — used within the cluster.

---

🌐 NodePort Limitations (and when to use)

• Each NodePort must be unique across the cluster.

• You can’t expose two different services on the same NodePort (e.g., both on 30080).

• You can have many apps listening on container port 80/443 — the problem is only at the NodePort level.

• NodePort doesn't support:

  • TLS termination

  • Path/host-based routing

  • DNS (you manage that)

• NodePort is manual, basic, and not suitable for scale.

---

☁️ LoadBalancer Services: Simpler External Exposure (Cloud-Only)

• type: LoadBalancer creates a real cloud load balancer (e.g., AWS ELB/NLB).

• Kubernetes leverages the Cloud Controller Manager (CCM) to:

  • Create the external LB

  • Assign it a public IP/DNS

  • Hook it into NodePorts

• Uses NodePort under the hood → LoadBalancer routes traffic to all healthy nodes.

✨ Your Breakthrough:

“Even though LoadBalancer is a K8s resource, it reaches outside and provisions real infra like AWS ELB — via the CCM!”

---

📦 Cloud Controller Manager (CCM) vs Ingress Controller

---

🧠 Ingress: Smart, Scalable HTTP Gateway

🔥 Your Key Insight:

“So LoadBalancer exposes a single service, but Ingress can expose many services behind a single LB using DNS/path rules — that's powerful!”

🧱 Components:

• Ingress Resource: Defines rules (host/path) for routing traffic.

• Ingress Controller: The actual software (e.g., NGINX, Traefik) that applies those rules.

• Ingress exposes services via Layer 7 (HTTP/HTTPS) — with support for:

  • TLS termination

  • Custom domains (host-based routing)

  • Path-based routing

  • Middleware (rate limiting, auth, etc.)

---

💡 Why Ingress > LoadBalancer at Scale

Real-World Analogy:

Using LoadBalancer for every app is like giving each microservice its own road to the city. Using Ingress is like building a highway with smart exits.

---

🛠️ What About Self-Hosted Clusters (e.g., kubeadm)?

✅ Breakthrough:

“So type: LoadBalancer does nothing useful unless you have a cloud provider? Got it.”

💡 Your Options:

---

🔄 Flow Summary: How Traffic Reaches Pods

Using LoadBalancer:

plaintextCopyEditClient → Cloud LoadBalancer (AWS ELB) → NodePort on Nodes → ClusterIP → Pod

Using Ingress:

plaintextCopyEditClient → Cloud LoadBalancer → Ingress Controller (NGINX) → ClusterIP → Pod

Using NodePort (direct):

plaintextCopyEditClient → NodeIP:NodePort → ClusterIP → Pod

---

🔑 Final Takeaways — Your Breakthroughs

1. Ingress ≠ Ingress Controller — Ingress is just a config; the Controller does the real work.

2. LoadBalancer ≠ Smart Router — It’s a raw L4 passthrough. For TLS, DNS, routing, use Ingress.

3. Pods are ephemeral, Services are stable — Service discovery is all about ClusterIP and DNS stability.

4. NodePort is minimalistic, suitable for dev/test or when using external NGINX/HAProxy.

5. LoadBalancer is ideal in cloud, but Ingress is the smarter, scalable, multi-service entrypoint.

6. CCM provisions infra, while Ingress Controller routes app traffic.