Why we need Ingress in Kubernetes?

When you want to expose your service/pod outside your cluster, you can use NodePort and LoadBalancer services. They work for a "Hello World," but has some drawbacks.

The Problem with the "Standard" way

Using a NodePort means your users have to type NodeIP:31054. It’s ugly, insecure, and if that specific Node goes down, your app is "dead" to the world.

Using a LoadBalancer service is better, but it has three big headaches:

1. Cost: One Cloud LB per service = a massive bill.
2. L4 vs L7: Standard L4 LoadBalancers don’t understand URL paths like /api and don’t provide advanced routing or centralized SSL handling.
3. Scaling: Managing 50 different entry points for 50 microservices is a management nightmare.

---

The Solution: Ingress

Ingress is a single entry point that handles all the "traffic flow" work.

While the Ingress Resource is just a set of rules (YAML), the Ingress Controller (like Nginx or Traefik) is the actual engine that moves the data.

How do we access Ingress from the Outside?

The Ingress Controller itself is just another Pod in your cluster. To get traffic to the Controller from the internet, we usually do one of two things:

• Option A: Create one single Type: LoadBalancer service that points only to the Ingress Controller. Now, one IP handles all your domains.
• Option B: Use a NodePort on the Ingress Controller and point your external DNS (like GoDaddy/Cloudflare) to your Node IPs.

---

Practical Example: Routing & SSL

Here is how you configure an Ingress to handle different services and SSL termination in one place:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: main-gateway
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  tls:
  - hosts:
    - myapp.com
    secretName: myapp-tls-secret
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /billing
        pathType: Prefix
        backend:
          service:
            name: billing-service
            port:
              number: 80
      - path: /
        pathType: Prefix
        backend:
          service:
            name: main-web-service
            port:
              number: 80

---

Pros

• Path-Based Routing: You can send /billing to the Billing Pod and / to the Web Pod using the same IP.
• Centralized SSL: You handle HTTPS certificates at the Ingress level instead of inside every individual app.
• Cost Efficiency: You only pay for one LoadBalancer, no matter how many services you have.

---

• The Entry: You point one external LoadBalancer to your Ingress Controller to get traffic into the cluster.
• The Logic: The Ingress Rules then decide which internal Service should actually handle the request.

In short: LoadBalancers get traffic TO the cluster; Ingress tells traffic WHERE to go inside.