Ingress Basics: Routing HTTP/S Traffic

1. Anatomy of an Ingress Resource

An Ingress resource is a standard Kubernetes object defined in a YAML manifest. Its purpose is to declare a set of rules for routing HTTP and HTTPS traffic from outside the cluster to services inside the cluster.

Let's break down the essential components of an Ingress manifest.

As the video explained, the key sections are:

• apiVersion: networking.k8s.io/v1 for current, stable Ingress resources.
• kind: Ingress
• metadata: Contains the name and namespace of the Ingress resource.
• spec: This is where the configuration lives. It specifies the routing rules.
  • ingressClassName: (Optional but recommended) Specifies which Ingress Controller should handle this Ingress. For example, nginx, gce, or alb. This allows you to have multiple types of controllers in one cluster.
  • rules: A list of rules that map incoming requests to backend services. Each rule typically contains a host and an http block with paths.

When you kubectl apply this manifest, the Ingress Controller detects it, parses the rules, and automatically reconfigures its underlying proxy (e.g., NGINX) to implement them.

2. Common Routing Patterns

Ingress resources primarily support two powerful routing patterns: path-based routing (fanout) and host-based routing (virtual hosting). Often, you will combine them.

Path-Based Routing (Simple Fanout)

This pattern routes traffic for a single hostname to different services based on the URL path. This is extremely useful for exposing different components of a single application (e.g., API, web UI, assets) through one domain.

For example, you could route:

• http://cafe.example.com/coffee -> coffee-service
• http://cafe.example.com/tea -> tea-service

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: simple-fanout-example
spec:
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /coffee
        pathType: Prefix
        backend:
          service:
            name: coffee-svc
            port:
              number: 80
      - path: /tea
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80

A critical field here is pathType. It defines how the path matching is performed.

The three main pathType values are:

• Prefix: Matches based on a URL path prefix split by /. For example, a path of /foo will match /foo, /foo/, and /foo/bar.
• Exact: Matches the URL path exactly and is case-sensitive. A path of /foo will only match /foo; it will not match /foo/.
• ImplementationSpecific: The matching behavior depends on the IngressClass. For most controllers, like NGINX, this defaults to behaving like Prefix. It's best practice to be explicit and use Prefix or Exact.

Host-Based Routing (Name-Based Virtual Hosting)

This pattern routes traffic to different services based on the Host header of the request. This allows you to run completely separate applications on the same IP address. Given your experience managing multiple platform services, this is a pattern you'll see frequently.

For example:

• http://api.example.com -> api-service
• http://shop.example.com -> shop-service

Here's a YAML example for host-based routing:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: name-virtual-host-ingress
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 8080
  - host: shop.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: shop-service
            port:
              number: 80

spec:
  rules:
  - host: metrics.myapplication.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: prometheus-service
            port:
              number: 9090
  - host: myapplication.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: backend-api-service
            port:
              number: 3000
      - path: /
        pathType: Prefix
        backend:
          service:
            name: frontend-web-service
            port:
              number: 80

3. Securing Ingress with TLS/HTTPS

Exposing services over unencrypted HTTP is rarely acceptable in production. Ingress provides a straightforward way to terminate TLS, enabling HTTPS for your applications.

The process involves two steps:

1. Create a Kubernetes Secret of type kubernetes.io/tls that contains your TLS certificate and private key.
2. Reference that Secret in your Ingress resource.

The Ingress Controller will then handle the TLS handshake with the client and forward unencrypted traffic to your backend Pods. This offloads the burden of managing certificates from your applications.

First, you'd create the secret. It must contain two keys: tls.crt and tls.key.

apiVersion: v1
kind: Secret
metadata:
  name: cafe-secret
  namespace: default
data:
  tls.crt: <base64-encoded-cert>
  tls.key: <base64-encoded-private-key>
type: kubernetes.io/tls

Then, you reference this secret in your Ingress manifest:

The Ingress manifest would look like this:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - cafe.example.com
    secretName: cafe-secret # <-- Reference to the secret
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: Prefix
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

In a real-world platform environment, you would likely automate the creation and renewal of these TLS certificates using a tool like cert-manager, which integrates with Let's Encrypt. While that's beyond the scope of this lesson, it's an essential tool in the MLOps/Platform Engineering space.

Conclusion

Congratulations on completing the module on Kubernetes networking! You now have a solid understanding of how to expose applications, from simple internal services to complex, externally-facing applications routed through a secure Ingress.

Key Takeaways:

• The Ingress resource is a collection of rules for routing external HTTP/S traffic to internal services.
• The two main routing strategies are path-based (fanout) and host-based (virtual hosting), which can be combined.
• The pathType field (Prefix, Exact) is critical for defining precise matching behavior.
• You can secure an Ingress with HTTPS by adding a tls section that references a Kubernetes Secret of type kubernetes.io/tls.

Next Up:
We've focused entirely on stateless applications so far. But what about applications that need to persist data, like databases or message queues? In our next module, Persistent Storage Fundamentals, we will start exploring how Kubernetes handles stateful workloads by looking at the basic volume types emptyDir and hostPath.