Chapter 12: Using Ingress to route traffic to services

Introduction

Introduces Ingress as a way to expose multiple services through one public IP address while offering HTTP features beyond those of Services.

• Ingress versus LoadBalancer exposure: Explain why an Ingress is useful when exposing many services externally: unlike separate LoadBalancer services, it needs only one public IP address and can provide additional HTTP features.
  Why it matters: This explains why you might choose an Ingress instead of exposing every service with its own load balancer.

Key terms: Ingress object, LoadBalancer service type, public IP address

12.1 Introducing Ingresses

Introduces Ingress as a way for external clients to reach services in a Kubernetes cluster and distinguishes the components and proxy terminology involved.

• Ingress components and roles: Explain how an Ingress lets external clients access application services, and distinguish the Ingress API object, the traffic-routing proxy, and the ingress controller by their roles.
  Why it matters: Separating the configuration, controller, and proxy makes it easier to understand what each part of Ingress does.
• Reverse proxy traffic direction: Distinguish the incoming traffic handled by a reverse proxy from the outgoing traffic handled by a forward proxy, including where each is typically located.
  Why it matters: The direction of traffic explains why the Ingress proxy sits on the path into backend services.
• L7 proxy terminology: Explain why this section calls the Ingress L7 load balancer a proxy rather than confusing it with the L4 load balancer for LoadBalancer-type services, and state when an Ingress route does not perform load balancing.
  Why it matters: This distinction prevents two different traffic-handling components from being mistaken for one another.

Key terms: Ingress, Ingress API object, ingress controller, L7 load balancer, reverse proxy, backend services, forward proxy, backend servers, L4, L7

12.1.1 Introducing the Ingress object kind

This section introduces Ingress as a shared external entrypoint for services and explains how HTTP requests are routed to them.

• Shared Ingress entrypoint: Explain how an Ingress object exposes one or more Services to external clients through a common entrypoint. Describe how a cluster can also have multiple Ingress objects.
  Why it matters: It explains how several services can be exposed without giving each one a separate external entrypoint.
• HTTP request routing rules: Describe how an Ingress uses information in an HTTP request to choose a destination Service, using the Kiada host and path examples.
  Why it matters: The request itself determines which service receives traffic at the shared entrypoint.
• Ingress backend Service type: Explain why a Service exposed through an Ingress can usually remain ClusterIP and when its type might need to differ.
  Why it matters: It prevents assuming that every Service behind an Ingress needs its own externally exposed Service type.

Key terms: Ingress object, Service objects, L7 load balancer, HTTP reverse proxy, common entrypoint, rules, HTTP request, host, path, public DNS entries

12.1.2 Introducing the Ingress controller and the reverse proxy

Explains how an Ingress controller configures a reverse proxy from Kubernetes objects and how that proxy routes external HTTP requests to pod endpoints.

• Ingress components and availability: Distinguish the Ingress controller from the reverse proxy, and explain why an Ingress object alone may not make ingress traffic work.
  Why it matters: An Ingress object needs an implementation behind it to handle traffic.
• Controller configuration of the proxy: Trace how the controller turns Ingress, Service, and endpoint information into a reachable reverse proxy and responds to changes.
  Why it matters: This explains how Kubernetes object changes become working external routing.
• Proxy routing to pod endpoints: Trace a client's HTTP request through DNS and the reverse proxy to a pod, distinguishing the pod endpoint from the Service IP.
  Why it matters: It clarifies what receives an external request and where the proxy actually sends it.

Key terms: Ingress controller, Ingress object, reverse proxy, cluster add-on, Kubernetes API server, Ingress, Service, Endpoints, EndpointSlice, L7 load balancer

12.1.3 Installing an ingress controller

Explains how to ensure an ingress controller is available before creating Ingresses, with setup considerations for managed, kind, and Minikube clusters.

• Ingress controller availability and choice: Explain why an ingress controller must be available before creating Ingresses and how the choice depends on the cluster. Describe the section’s recommendation to use the Kubernetes-maintained Nginx ingress controller when a suitable controller is not already provided.
  Why it matters: Checking for a controller first prevents you from creating Ingresses without the component needed to serve them.
• Local cluster ingress preparation: Describe the local-cluster preparations mentioned for installing and accessing the Nginx ingress controller with kind or Minikube.
  Why it matters: These environment-specific steps help make the controller schedulable and Ingresses accessible during the chapter’s examples.

Key terms: ingress controller, managed cluster, Nginx ingress controller, kind, Chapter12/create-kind-cluster.sh, ingress-ready=true, Minikube, minikube tunnel

12.2 Creating and using Ingress objects

Introduces the upcoming Kiada Ingress exercises and notes that the suite’s pods and services must be deployed first.

12.2.1 Exposing a service through an Ingress

Shows how to expose the kiada Service through an Ingress, find its public address, and send requests with the hostname needed for routing.

• Ingress rule and service backend: Explain how the example Ingress exposes the kiada Service: requests for kiada.example.com, on any path, are forwarded to port 80 of the Service. Explain why the Service can remain a ClusterIP Service.
  Why it matters: It separates the externally accessible Ingress from the cluster-internal Service it routes to.
• Ingress address inspection: Describe how to find the Ingress address after creating the object and what that address represents. State what to check if no address appears after several minutes.
  Why it matters: Clients need the proxy’s address, and a missing address helps identify an unprocessed Ingress.
• Hostname resolution and request routing: Explain why clients must both resolve kiada.example.com to the Ingress IP and send that hostname in the HTTP Host header. Describe the production DNS mapping and the local curl or hosts-file alternatives.
  Why it matters: Reaching the proxy is not enough: the request also has to identify the host whose rule should handle it.

Key terms: Ingress object, Ingress rule, ClusterIP, Service, host, path, kubectl get ingresses, kubectl describe, Ingress IP address, ingress controller

12.2.2 Path-based ingress traffic routing

This section shows how one Ingress routes requests for the same host to different services by path and explains how each path type matches requests.

• Host and path routing: Explain how an Ingress rule uses a request’s host and path to select a backend service, using the api.example.com example.
  Why it matters: Host and path rules let related services share an external address.
• Exact matches and priority: Describe what Exact requires of a request path and what happens when a request matches multiple path entries.
  Why it matters: These rules help predict which backend receives a request when routes overlap.
• Prefix path element matching: Explain how Prefix matching compares paths and distinguish it from a simple string-prefix check.
  Why it matters: Element-based matching prevents a route for one path element from catching similarly spelled paths.
• Implementation-specific path matching: Distinguish ImplementationSpecific from the defined Exact and Prefix matching behavior.
  Why it matters: A route using this path type may behave differently with a different ingress controller.
• Unchanged backend request paths: State what path the backend receives by default when an Ingress proxy forwards a request.
  Why it matters: The backend must be prepared to handle the path the client requested unless rewriting is configured.

Key terms: Ingress, rule, paths, Service, backend, pathType, Exact, Prefix, path element, ImplementationSpecific

12.2.3 Using multiple rules in an Ingress object

This section shows how one Ingress can route requests to multiple Kiada services through multiple rules, and explains how wildcard hosts match.

• Multiple rules in one Ingress: Explain how combining rules from separate Ingress objects lets one Ingress serve the Kiada suite using a single public IP address. Describe why clients may need an updated address after replacing the old objects.
  Why it matters: Combining rules can reduce the number of public IP addresses needed without losing access to the services.
• Host and path routing: Trace how the combined Ingress routes Kiada suite requests using the request’s Host header and, for api.example.com, its path.
  Why it matters: Host and path routing explain how one public entry point can reach different services.
• Wildcard host matching: Explain which hosts a wildcard such as *.example.com matches, how exact-host rules take precedence, and what omitting the host field means.
  Why it matters: These matching rules help predict which Ingress rule handles a requested hostname.

Key terms: Ingress object, rules, public IP address, virtual hosts, Host header, backend services, requested path, host field, wildcards, exactly matches

12.2.4 Setting the default backend

This section shows how to configure an Ingress default backend to handle requests that match no rule, and why an Ingress can be useful even without rules.

• Default backend catch-all routing: Explain what happens when a request matches no Ingress rule and how to configure a default backend service for those requests.
  Why it matters: It lets you choose where unmatched requests go instead of relying on the usual 404 response.
• Default-only Ingress purpose: Explain why an Ingress with only a default backend can be useful instead of exposing the service directly with a LoadBalancer.
  Why it matters: A single-service Ingress can still be worthwhile when you need Ingress HTTP features.

Key terms: default backend, spec.defaultBackend, backend service, LoadBalancer, Transport Layer Security (TLS)

12.3 Configuring TLS for an Ingress

This section explains why the existing HTTP-only Ingress needs HTTPS support and identifies two places where TLS can be terminated.

• Ingress HTTPS termination choices: Explain why HTTPS is being added to the Ingress and distinguish the two options: pass HTTPS through the ingress proxy for the backend pod to terminate TLS, or terminate TLS at the proxy and connect to the backend over HTTP.
  Why it matters: The choice determines where the HTTPS connection ends and whether the proxy connects to the backend using HTTP.

Key terms: Ingress, HTTPS, ingress proxy, TLS connection, backend pod

12.3.1 Configuring the Ingress for TLS passthrough

This subsection explains that TLS passthrough is configured in a controller-specific way rather than through a standard Ingress setting.

• Controller-specific TLS passthrough configuration: Explain that Kubernetes provides no standard way to configure TLS passthrough in an Ingress, and that a supporting ingress controller can usually be configured through an Ingress annotation. State that the Nginx ingress controller also requires the --enable-ssl-passthrough startup flag.
  Why it matters: You need to check your ingress controller’s documentation rather than assume one portable passthrough setting will work.

Key terms: TLS passthrough, Ingress object, annotations, Nginx ingress controller, --enable-ssl-passthrough

12.3.2 Terminating TLS at the Ingress

This section explains how an Ingress proxy terminates client TLS connections and how to configure the certificate and key it uses.

• TLS termination at the proxy: Explain where TLS ends when an Ingress terminates it, and how the request reaches the backend pod.
  Why it matters: It distinguishes an HTTPS connection to the Ingress from an encrypted connection all the way to a pod.
• Ingress TLS Secret configuration: Describe how an Ingress is given a TLS certificate and private key, including how the configured hosts relate to the certificate.
  Why it matters: The Ingress needs the right certificate and key for the hostnames clients use over HTTPS.

Key terms: TLS termination, ingress proxy, backend pod, Secret, tls, secretName, tls.hosts, tls.crt, tls.key

12.4 Additional Ingress configuration options

The section explains why the Ingress spec has few built-in configuration options and how ingress controllers provide additional, implementation-specific options.

• Ingress configuration limits: Explain why the Ingress spec does not include the full range of HTTP proxy settings and where additional options are configured.
  Why it matters: It explains why an HTTP proxy setting may not appear as a field in an Ingress manifest.
• Ingress spec field inspection: Describe what kubectl explain reveals about the Ingress spec fields and state the basic purpose of ingressClassName.
  Why it matters: Inspecting the spec makes the limited set of built-in Ingress fields concrete.

Key terms: Ingress object’s schema, annotations, custom Kubernetes API objects, ingress controller, kubectl explain, spec, defaultBackend, rules, tls, ingressClassName

12.4.1 Configuring the Ingress using annotations

This section explains why the Nginx ingress controller can provide cookie-based session affinity, how to enable it with annotations, and how to observe it in requests.

• Cookie affinity configuration: Explain how the example uses Nginx-ingress-specific annotations to enable cookie-based session affinity and set the session cookie name.
  Why it matters: These annotations let you configure a routing behavior that is specific to the Nginx ingress controller.
• Layer-based affinity distinction: Explain why Kubernetes services support client IP-based affinity but not cookie-based affinity, and why the Nginx ingress controller can support cookies.
  Why it matters: The network layer explains why this cookie-based option is configured at the Ingress rather than on a Service.
• Cookie affinity verification: Describe how the section tests cookie-based session affinity and what repeated requests demonstrate.
  Why it matters: Repeating requests with the cookie gives you an observable check that affinity is working.

Key terms: nginx.ingress.kubernetes.io/affinity, nginx.ingress.kubernetes.io/session-cookie-name, cookie-based session affinity, Nginx ingress controller, client IP-based session affinity, layer 4, layer 7, Ingress, Cookie header, session affinity

12.4.2 Configuring the Ingress using additional API objects

Shows how GKE uses a BackendConfig object to add Ingress configuration, using cookie-based session affinity as an example.

• GKE BackendConfig session affinity: Explain how the GKE example configures cookie-based session affinity for traffic arriving through an Ingress, and how this differs from configuring the Nginx ingress controller.
  Why it matters: The ingress controller determines how you supply extra configuration, so an annotation-based approach for one controller may not apply to another.

Key terms: BackendConfig, cloud.google.com/backend-config, GENERATED_COOKIE, cookie-based session affinity, Service, Ingress

12.5 Using multiple ingress controllers

Explains why a cluster may use multiple ingress controllers and how an IngressClass connects each Ingress to the controller that processes it.

• Multiple controller motivation: Explain why a cluster might have multiple ingress controllers and why each Ingress then needs to identify which controller should process it.
  Why it matters: The reason for choosing a controller makes the role of an ingress class clearer.
• IngressClass controller selection: Trace how an Ingress selects its controller through an IngressClass, and distinguish this from the deprecated annotation method.
  Why it matters: It explains how different Ingresses in one cluster can be directed to different controllers.

Key terms: ingress implementations, ingress controllers, Ingress object, IngressClass, spec, controller, optional parameters, kubernetes.io/ingress.class annotation

12.5.1 Introducing the IngressClass object kind

This section shows how to find IngressClass objects and read which ingress controller an existing class identifies.

• IngressClass discovery and meaning: Describe how to list the IngressClasses available in a cluster and interpret the nginx class shown in the example.
  Why it matters: Recognizing what a class identifies helps you interpret the IngressClasses present in your cluster.

Key terms: IngressClass, nginx, k8s.io/ingress-nginx, controller parameters

12.5.2 Specifying the IngressClass in the Ingress object

This subsection explains how an Ingress selects an IngressClass explicitly or uses the cluster’s default class.

• Explicit IngressClass selection: Explain how an Ingress names its class and how that class determines which ingress controller processes it.
  Why it matters: Naming a class lets you identify which installed controller will handle an Ingress.
• Default IngressClass fallback: Describe what happens when an Ingress omits its class and how the default IngressClass is marked.
  Why it matters: An Ingress can still be assigned a class when it does not name one explicitly.

Key terms: ingressClassName, IngressClass, controller, default IngressClass, ingressclass.kubernetes.io/is-default-class

12.5.3 Adding parameters to an IngressClass

This section explains how an IngressClass can reference controller-specific parameters to provide different ingress configurations, even with a single controller.

• Controller-specific IngressClass parameters: Explain why IngressClass parameters live in a separate custom object and how the ingress controller uses that object when processing an Ingress.
  Why it matters: This explains how one ingress controller can offer different configurations without requiring IngressClass to define every controller’s options.

Key terms: IngressClass, IngressClassParams, ingressClassName, ingress controller

12.6 Using custom resources instead of services as backends

This section explains that some ingress controllers accept resources other than Services as Ingress backends, most commonly to configure advanced routing through a custom resource.

• Alternative Ingress resource backends: Explain that although the chapter’s Ingress examples use Services as backends, some ingress controllers support other resources; the typical use is a custom resource for advanced routing rules.
  Why it matters: It explains why an Ingress backend might refer to something other than the familiar Service object.

Key terms: Ingress, Service objects, resource backends, custom resource, ingress controller

12.6.1 Using a custom object to configure Ingress routing

Shows how an Ingress can delegate HTTP routing to a custom resource instead of naming a Service as its backend.

• Custom resource Ingress backend: Explain how the Citrix ingress controller uses an HTTPRoute custom object as an Ingress backend, and identify how the Ingress refers to it.
  Why it matters: It shows that an Ingress backend can point to controller-specific routing configuration rather than directly to a Service.

Key terms: Citrix ingress controller, HTTPRoute, resource backend, kind, apiGroup, name

12.7 Summary

Summarizes how Ingress exposes multiple services through a controller-managed Layer 7 proxy, routes HTTP requests, and supports TLS and controller-specific configuration.