Exposing Applications in Kubernetes - Ingress

11/3/2022

We have an application running, but it's not publicly accessible. Let's expose it to the world!

Ingress

We could expose an application using a service with the LoadBalancer type. But ingress resources provide richer features around HTTP-based communication such as host or path-based routing and SSL termination. In short, ingress resources provide layer 7 load balancing while services operate at layer 4.

Let's describe an ingress resource in a file called ingress.yml.


When we apply this object, GKE creates a Google Cloud HTTP(S) Load Balancer and configures with the rules described. The one and only rule here says to route all traffic with the / path prefix to the echo1 service on port 80.

Here's a diagram that shows how a request should flow through the cluster.

Kubernetes Clusteringress1Ingressecho1Serviceecho1PodGCPHTTP Load Balancer:80:5678echo1Pod:5678

Since there's only one ingress rule, all requests go to the echo1 service. It's possible to create multiple rules, each backed by a different service backed by different pods.

With that in mind, let's create the ingress object.


Note that it can take a few minutes for the ingress resource to become ready. When it's up, we can get the IP address assigned to the provisioned GCP load balancer.


Let's make some HTTP requests to that IP address.


Our application is exposed publicly and requests are being load balanced across the two deployed replicas.