We have an application running, but it's not publicly accessible. Let's expose it to the world!
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
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.
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.