Concept Of Ingress In Kubernetes : Basics

🌀 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 <pending>.

📦 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 <pending> at first.