Ingress resource definition in Kubernetes - Deep Dive

Overview - Ingress resource definition

What is it?

An Ingress resource in Kubernetes is a set of rules that allow external users to access services inside a cluster. It acts like a smart gatekeeper that routes incoming web traffic to the right service based on the request details. This resource defines how URLs or hostnames map to services, enabling easy management of external access. It simplifies exposing multiple services through a single IP address.

Why it matters

Without Ingress, each service would need its own external IP or load balancer, which is costly and hard to manage. Ingress solves this by centralizing access control and routing, saving resources and making it easier to maintain. It also enables features like SSL termination and path-based routing, improving security and flexibility. Without it, managing access to many services would be chaotic and inefficient.

Where it fits

Before learning Ingress, you should understand Kubernetes basics like Pods, Services, and how networking works inside a cluster. After mastering Ingress, you can explore advanced topics like Ingress controllers, TLS/SSL setup, and service mesh integration for more secure and scalable traffic management.

Mental Model

Core Idea

Ingress is a traffic director that controls how external requests enter a Kubernetes cluster and reach the right service.

Think of it like...

Imagine a hotel receptionist who listens to guests' requests and directs them to the correct room or service based on their needs. The receptionist knows all the rooms and services and routes guests efficiently without confusion.

┌───────────────┐
│ External User │
└──────┬────────┘
       │ HTTP/HTTPS Request
       ▼
┌───────────────┐
│   Ingress     │  <-- Rules decide where to send
│  Resource     │
└──────┬────────┘
       │ Routes request based on host/path
       ▼
┌───────────────┐    ┌───────────────┐
│ Service A     │    │ Service B     │
└───────────────┘    └───────────────┘

Build-Up - 7 Steps

1

Foundation

What is an Ingress resource

Concept: Introduce the basic idea of Ingress as a Kubernetes object that manages external access.

In Kubernetes, an Ingress resource defines rules to route external HTTP or HTTPS traffic to internal services. It acts as a bridge between outside users and your cluster's services. You create an Ingress by writing a YAML file that specifies hosts, paths, and the services to forward traffic to.

Result

You understand that Ingress is a Kubernetes object that controls how external traffic reaches services inside the cluster.

Understanding that Ingress is a resource, not a service itself, helps you see it as a rulebook for routing traffic rather than the traffic handler.

2

Foundation

Basic Ingress YAML structure

Concept: Learn the essential parts of an Ingress definition file.

A simple Ingress YAML includes apiVersion, kind, metadata, and spec. The spec contains rules with hosts and paths that map to backend services. For example: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress spec: rules: - host: example.com http: paths: - path: / pathType: Prefix backend: service: name: example-service port: number: 80

Result

You can write a basic Ingress YAML that routes traffic from a hostname to a service.

Knowing the YAML structure lets you customize routing rules and understand how Kubernetes reads your instructions.

3

Intermediate

Path-based routing rules

🤔Before reading on: do you think Ingress can route traffic differently based on URL paths or only by hostname? Commit to your answer.

Concept: Ingress can route traffic not just by hostname but also by URL path prefixes.

In the rules section, you can define multiple paths under a host. Each path can send traffic to a different service. For example, /app1 routes to service1 and /app2 routes to service2. This allows one Ingress to manage multiple services behind different URL paths.

Result

Traffic to example.com/app1 goes to service1, and traffic to example.com/app2 goes to service2.

Understanding path-based routing unlocks the power of Ingress to consolidate access to many services under one domain.

4

Intermediate

TLS configuration in Ingress

🤔Before reading on: do you think TLS setup is automatic with Ingress or requires explicit configuration? Commit to your answer.

Concept: Ingress supports TLS to secure traffic, but you must configure it explicitly with certificates.

You add a tls section to the Ingress YAML specifying hosts and the secret name holding TLS certificates. For example: tls: - hosts: - example.com secretName: example-tls-secret This enables HTTPS for the specified hosts, improving security by encrypting traffic.

Result

Ingress routes HTTPS traffic using the provided TLS certificates.

Knowing TLS is optional but essential for security helps you plan secure access to your services.

5

Intermediate

Role of Ingress controller

🤔Before reading on: do you think Ingress resource alone handles traffic or needs a controller? Commit to your answer.

Concept: Ingress resource defines rules, but an Ingress controller implements them and manages actual traffic routing.

Kubernetes does not route traffic by Ingress resource alone. You must run an Ingress controller like NGINX, Traefik, or cloud-specific controllers. The controller watches Ingress resources and configures the underlying proxy to route traffic accordingly.

Result

Ingress controller reads Ingress rules and routes external requests to services.

Understanding the split between resource definition and controller implementation clarifies why Ingress alone doesn't expose services.

6

Advanced

Annotations for advanced behavior

🤔Before reading on: do you think Ingress rules cover all routing features or annotations add extra control? Commit to your answer.

Concept: Annotations extend Ingress behavior with features like rewrite rules, timeouts, or authentication.

Annotations are key-value pairs added under metadata to customize controller behavior. For example, nginx.ingress.kubernetes.io/rewrite-target changes the URL path before forwarding. Other annotations can enable rate limiting or custom headers.

Result

Ingress behaves with customized routing and security features beyond basic rules.

Knowing annotations unlocks powerful controller-specific features that make Ingress flexible in production.

7

Expert

Limitations and pitfalls of Ingress resource

🤔Before reading on: do you think Ingress can handle all traffic types or only HTTP/HTTPS? Commit to your answer.

Concept: Ingress is designed for HTTP/HTTPS traffic and has limitations with other protocols or complex routing needs.

Ingress does not support TCP/UDP routing natively; for those, you need other resources like Services of type LoadBalancer or custom controllers. Also, complex routing logic or multi-cluster setups require additional tools like service meshes. Misconfigurations can cause traffic loops or security gaps.

Result

You recognize when Ingress is not the right tool and when to use alternatives.

Understanding Ingress limits prevents misuse and guides you to better solutions for non-HTTP traffic or advanced scenarios.

Under the Hood

The Ingress resource is a declarative configuration stored in Kubernetes API. The Ingress controller watches for changes to these resources and translates rules into proxy configurations (like NGINX or Envoy). When external traffic arrives, the controller's proxy inspects the request's host and path, then forwards it to the matching service's endpoints. TLS termination happens at the proxy, decrypting traffic before forwarding it internally.

Why designed this way?

Ingress separates the 'what' (rules) from the 'how' (controller implementation) to allow flexibility. Different environments can use different controllers optimized for their needs. This design avoids locking users into one proxy technology and supports extensibility. Early Kubernetes versions lacked this, causing complexity and duplication of load balancers.

┌─────────────────────────────┐
│ Kubernetes API Server        │
│  (Stores Ingress resource)  │
└──────────────┬──────────────┘
               │ Watches Ingress
               ▼
┌─────────────────────────────┐
│ Ingress Controller          │
│ (e.g., NGINX, Traefik)      │
│ Translates rules to proxy   │
└──────────────┬──────────────┘
               │ Configures proxy
               ▼
┌─────────────────────────────┐
│ Proxy Server (NGINX, Envoy) │
│ Handles incoming traffic     │
│ Routes to backend services  │
└──────────────┬──────────────┘
               │ Forwards traffic
               ▼
┌─────────────────────────────┐
│ Kubernetes Services & Pods  │
│ Receive traffic internally  │
└─────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does an Ingress resource automatically expose your services to the internet? Commit yes or no.

Common Belief: Creating an Ingress resource alone exposes services externally without extra setup.

Reality: An Ingress resource only defines rules; you must run an Ingress controller to actually route external traffic.

Why it matters: Without a controller, your services remain inaccessible from outside, causing confusion and failed deployments.

Quick: Can Ingress route TCP or UDP traffic natively? Commit yes or no.

Common Belief: Ingress can handle all types of network traffic including TCP and UDP.

Reality: Ingress only supports HTTP and HTTPS traffic; other protocols require different Kubernetes resources or controllers.

Why it matters: Trying to use Ingress for unsupported protocols leads to broken connectivity and wasted troubleshooting time.

Quick: Does Ingress automatically provide HTTPS encryption without configuration? Commit yes or no.

Common Belief: Ingress automatically secures traffic with HTTPS by default.

Reality: You must explicitly configure TLS certificates and secrets in the Ingress resource for HTTPS support.

Why it matters: Assuming automatic HTTPS can expose services to insecure HTTP traffic, risking data interception.

Quick: Is path matching in Ingress always exact? Commit yes or no.

Common Belief: Ingress path matching always requires exact URL matches.

Reality: Ingress supports different path types like Prefix and Exact, allowing flexible matching rules.

Why it matters: Misunderstanding path matching causes routing errors and unexpected service responses.

Expert Zone

1

Some Ingress controllers support custom resource definitions (CRDs) to extend routing capabilities beyond the standard Ingress spec.

2

Annotations are controller-specific and not standardized, so migrating between controllers may require rewriting them.

3

TLS secrets must be managed carefully; some controllers support automatic certificate renewal via ACME protocols, but others require manual updates.

When NOT to use

Do not use Ingress when you need to expose non-HTTP protocols like databases or messaging queues; instead, use Services of type LoadBalancer or NodePort. For complex multi-cluster or service mesh scenarios, consider Istio or Linkerd which provide richer traffic control.

Production Patterns

In production, teams often deploy multiple Ingress controllers for different purposes (e.g., one for public traffic, one for internal apps). They use annotations for fine-grained control and integrate Ingress with external DNS and certificate managers for automated HTTPS. Monitoring and logging are added to track traffic and troubleshoot routing issues.

Connections

Load Balancer

Ingress builds on the concept of load balancing by routing HTTP traffic to services inside Kubernetes.

Understanding traditional load balancers helps grasp how Ingress controllers distribute traffic efficiently within a cluster.

Reverse Proxy

Ingress controllers act as reverse proxies that accept client requests and forward them to backend services.

Knowing how reverse proxies work clarifies how Ingress manages routing, SSL termination, and request rewriting.

Traffic Control in Networking

Ingress is a form of traffic control that directs network requests based on rules, similar to routers or firewalls.

Recognizing Ingress as traffic control connects Kubernetes networking to broader network engineering principles.

Common Pitfalls

#1 Assuming Ingress exposes services without an Ingress controller installed.

Wrong approach:

kubectl apply -f ingress.yaml
# No Ingress controller installed or running

Correct approach:

# Install an Ingress controller first, e.g., NGINX
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.9.1/deploy/static/provider/cloud/deploy.yaml
kubectl apply -f ingress.yaml

Root cause:

Misunderstanding that Ingress resource is only a rule set and requires a controller to function.

#2 Configuring TLS section without creating the TLS secret.

Wrong approach:

tls:
- hosts:
- example.com
secretName: missing-secret

Correct approach:

kubectl create secret tls example-tls-secret --cert=cert.crt --key=key.key

# Then reference the secret in Ingress
tls:
- hosts:
- example.com
secretName: example-tls-secret

Root cause:

Assuming Kubernetes creates TLS secrets automatically from Ingress configuration.

#3 Using incorrect pathType causing routing failures.

Wrong approach:

paths:
- path: /app
pathType: Exact
backend:
service:
name: app-service
port:
number: 80
# But expecting prefix matching

Correct approach:

paths:
- path: /app
pathType: Prefix
backend:
service:
name: app-service
port:
number: 80

Root cause:

Confusing pathType values and their matching behavior.

Key Takeaways

Ingress resource defines rules for routing external HTTP/HTTPS traffic to Kubernetes services but does not handle traffic by itself.

An Ingress controller is required to implement these rules and manage actual network traffic flow.

Ingress supports hostname and path-based routing, enabling multiple services to share a single external IP.

TLS encryption must be explicitly configured in Ingress to secure traffic with HTTPS.

Understanding Ingress limitations helps choose the right tool for non-HTTP traffic or complex routing needs.