🌀 What is Ingress in Kubernetes?

Hey! So today, let’s talk about Ingress in Kubernetes. If you’re working with Kubernetes and wondering how the outside world can access your apps inside the cluster, Ingress is your answer.

💡 In Simple Words...

Ingress is like the front door to your Kubernetes cluster for web traffic (HTTP and HTTPS). It knows where to send incoming requests based on rules you define. Think of it like a traffic controller at a mall entrance, telling visitors which shop to go to.

🛠️ A Real YAML Example of Ingress

Let’s break down a real Ingress configuration that uses the NGINX Ingress Controller:

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

🔍 What’s Happening Here?

  • Annotations: Rewrite any request to /testpath to / before sending to the backend.
  • ingressClassName: Tells Kubernetes which Ingress Controller to use (in this case, nginx-example).
  • rules: Says, "If someone hits /testpath, forward the request to the test service on port 80."

🧭 What is pathType and Why It Matters?

Each path in an Ingress rule must have a pathType. It tells Kubernetes how to match the request path.

🧩 Supported pathType values:

  1. Prefix – Matches if the request path starts with the given path.
  2. Exact – Matches only if the request path is exactly the same.
  3. ImplementationSpecific – Behavior depends on the Ingress Controller you're using.

➕ Multiple Matches – Who Wins?

If more than one rule matches a request, Kubernetes uses the following logic:

  1. Longest matching path wins.
  2. If paths are the same length, Exact wins over Prefix.

🔄 Types of Ingress

There are three common types of Ingress setups:

1. Path-Based Routing (Rule-Based Routing)

This is the most common type. You route requests based on the URL path.

➡️ Already covered in the minimal-ingress YAML.

2. Default Backend Ingress

This type doesn't define any specific rules. It acts as a catch-all. If no rule matches, it sends traffic to a default service.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
spec:
  defaultBackend:
    service:
      name: test
      port:
        number: 80

Think of it like: "If a request doesn’t match any rule, just send it to the test service."

3. Host-Based Routing (Name-Based Routing)

This lets you route traffic based on the domain name used in the request. For example:

  • foo.example.com → goes to one service
  • bar.example.com → goes to another service

Here’s an example:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: host-based-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: foo.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: foo-service
            port:
              number: 80
  - host: bar.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: bar-service
            port:
              number: 80

🧠 Use case: You have multiple websites or apps with different domain names hosted on the same Kubernetes cluster. This Ingress allows each one to route correctly.

🧪 Deploy and View the Ingress

Apply the Ingress YAML using:

kubectl apply -f your-ingress.yaml

To view the Ingress resource:

kubectl get ingress

Example output:

NAME                CLASS    HOSTS                   ADDRESS          PORTS   AGE
host-based-ingress  nginx    foo.example.com,...     a1b2.elb...com   80      2m

Note: It may take a minute or two for AWS to assign an IP address or DNS to your Ingress. Until then, the address may show as .

📦 Final Thoughts

  • Ingress is your smart HTTP/HTTPS gateway into the cluster.
  • You can configure routing:
    • Based on path (e.g., /test)
    • Based on host (e.g., foo.example.com)
    • Or fallback to a default backend
  • Always define a pathType.
  • Use kubectl get ingress to check its status.
  • Give it a moment to get an IP—it's normal to see at first.