Kubernetes is great and makes it easier to create and manage highly distributed applications. A challenge then is how do you share your great Kubernetes hosted applications with the rest of the world. Many lean towards Kubernetes Ingress objects and this article will show you how to use the open source Solo.io Gloo to fill this need.

Solo.io Gloo as Kubernetes Ingress

Gloo is a function gateway that gives users a number of benefits including sophisticated function level routing, and deep service discovery with the introspection of OpenAPI (Swagger) definitions, gRPC reflection, Lambda discovery and more. Gloo can act as an Ingress Controller, that is, by routing Kubernetes external traffic to Kubernetes cluster hosted services based on the path routing rules defined in an Ingress Object. I’m a big believer in showing technology through examples, so let’s quickly run through an example to show you what’s possible.

Prerequisites

This example assumes you’re running on a local minikube instance, and that you also have kubectl also running. You can run this same example on your favorite cloud provider managed Kubernetes cluster, you’d just need to make a few tweaks. You’ll also need Gloo installed. Let’s use Homebrew to set all of this up for us.

It will take a few minutes to download and install everything to your local machine, and get everything started. Assuming it all went well, the command ( kubectl ) should have returned minikube meaning that your local minikube cluster is running and your Kubernetes cluster config is correctly set up for minikube.

One more thing before we dive into Ingress objects, let’s set up an example service deployed on Kubernetes that we can reference.

Setting up an Ingress to our example Petstore

Let’s set up a basic Ingress object that routes all HTTP traffic to our petstore service. To make this a little more interesting and challenging, and who doesn’t like a good tech challenge, let’s also configure a host domain, which will require a little extra curl magic to call correctly on our local Kubernetes cluster. The following Ingress definition will route all requests to http://gloo.example.com to our petstore services listening on port 8080 within our cluster. The petstore service provides some REST functions listening on the query path /api/pets that will return JSON for the inventory of pets in our (small) store.

If you are trying this example in a public cloud Kubernetes instance, you’ll most likely need to configure a Cloud Load Balancer. Make sure you configure that Load Balancer for the service/ingress-proxy running in the gloo-system namespace.

The important details are:

Annotation kubernetes.io/ingress.class: gloo which is the standard way to mark an Ingress as handled by a specific Ingress controller, i.e., Gloo. This requirement will go away soon as we add the ability for Gloo to be the cluster default Ingress controller

which is the standard way to mark an Ingress as handled by a specific Ingress controller, i.e., Gloo. This requirement will go away soon as we add the ability for Gloo to be the cluster default Ingress controller Path wildcard /.* to indicate to route all traffic to our petstore service

We can validate that Kubernetes created our Ingress correctly by the following command.

To test we’ll use curl to call our local cluster. Like I said earlier, by defining a host: gloo.example.com in our Ingress, we need to do a little more to call this without doing things with DNS or our local /etc/hosts file. I’m going to use the recent curl --connect-to options, and you can read more about that at the curl man pages.

The glooctl command-line tool helps us get the local host IP and port for the proxy with the glooctl proxy url --name <ingress name> command. It returns a full URL with protocol prefix that we’ll need to strip off to use with curl. The following two commands will do a little bit of command line magic to make this example work on your local machine.

Which should return the following JSON

TLS Configuration

These days, most want to use TLS to secure your communications. Gloo Ingress can act as a TLS terminator, and we’ll quickly run through what that set up would look like.

Any Kubernetes Ingress doing TLS will need a Kubernetes TLS secret created, so let’s create a self-signed certificate we can use for our example gloo.example.com domain. The following two commands will create a certificate, and create a TLS secret named my-tls-secret in minikube.

Now let’s update our Ingress object with the needed TLS configuration. Important that the TLS host and the rules host match, and the secretName matches the name of the Kubernetes secret deployed previously.

If all went well we should have changed our petstore to now be listening to https://gloo.example.com . Let’s try it, again using our curl magic, which we need to both resolve the host and port as well as to validate our certificate. Notice that we’re asking glooctl for --port https this time, and we’re curling https://gloo.example.com on port 443.

Next Steps

This was a quick tour of how Gloo can act as your Kubernetes Ingress controller making very minimal changes to your existing Kubernetes manifests. Please try it out and let us know what you think at our community Slack channel.