WordPress on Kubernetes

In this guide so far we have been using a NodePort service to access our WordPress application from outside the cluster. In this section we’ll cover Ingress and Ingress Controllers in Kubernetes.

We’ll install and configure the Ingress NGINX Controller in our vanilla cluster, along with an Ingress component to route traffic to our WordPress application service. For high availability we’ll make sure we have at least to pods running Nginx on specific/predictable nodes.

Note: all code samples from this section are available on GitHub.

Why not a NodePort?

We briefly covered NodePorts in an earlier section. It’s a non-privileged port (30000-32767 by default) that’s allocated on every node in the Kubernetes cluster. While this works for testing and development purposes, it is less than ideal for any production workload.

We’d love to serve our application on privileged ports 80 and 443 for HTTP and HTTPS. We’d also love to have a predictable fixed set of IP addresses we can route our domains to. Finally, we should support more than one HTTP application in our cluster. This is where Ingress and Ingress Controllers come in.

Ingress

A Kubernetes Ingress is a way to define HTTP routing rules in a cluster. This includes host matching, path prefixes, routes to specific backend services and even TLS certificates.

However, an Ingress by itself doesn’t do anything, other than define these rules. We’ll need something that will read these rules and act accordingly, or in other words, an implementation. This is exactly what an Ingress Controller does.

Ingress Controller

An Ingress Controller is a collection of pods, services, deployments and other components in a Kubernetes cluster for a specific implementation, such as Nginx, which we will be using in this guide. These components will read Ingress objects, sometimes labels/annotations, and route traffic accordingly.