Providing public ingress to a HashiCorp Consul service mesh running in Kubernetes is a process that usually requires the configuration of multiple Ingress controllers, each handling various functions such as load balancing or authentication. ngrok reduces that complexity by providing all the necessary aspects of ingress in a single controller.
This blog post will show how easy it is to get your service mesh online. We’ll cover the highlights here. For step-by-step instructions check out the Ingress to services in a Consul Service Mesh on Kubernetes integration guide. To illustrate the powerful combination of using Consul, Kubernetes, and ngrok together let’s dive into a possible real-world scenario.
Let’s suppose you have recently opened a coffee shop that has become quite popular thanks to its unique flavor and style. To better serve your customers you develop an application to allow for online ordering. The app uses a service-oriented architecture and implements Consul to better manage the communication and discovery of these services.
Throughout development, you use the ngrok agent to get your application online for testing and getting feedback from customers.
Afterall, you are no network engineer and don’t have the time to figure out how to quickly deploy your application for others to see.
You run ngrok http and then point it at whatever port our Kubernetes cluster is exposing, and your application is online.
While the ngrok agent is easy, it is very temporary. Whenever you close the ngrok agent your application goes offline. This is fine during development, but not in production. Going live on production will require a much more permanent solution.
As you prepare for moving your application to production you successfully provision a Kubernetes cluster running Consul service mesh thanks to HashiCorp’s Consul and Kubernetes deployment guide. However, the additional work to create ingress and get the production application online is a task that proves to be daunting.
You know you have to configure network interfaces, load balancing, and authentication. And, you need to figure out how all those settings place nice with one another. While you search for solutions to accomplish all this network configuration you discover you can utilize ngrok in production with the ngrok Kubernetes Operator. The operator provides secure and consistent connectivity to your cluster while also taking care of load balancing and authentication. The operator follows the expected patterns of other Kubernetes controllers, like being managed through Helm as a Helm chart. In fact, it’s through Helm that you connect ngrok with Consul.
To proxy traffic to your service, you simply add the ngrok Kubernetes Operator pods to the Consul service mesh by using pod annotations when you install the Helm chart. You’ll use the following two notations to enable the Consul Connect sidecar and allow outbound traffic to use the Consul mesh.
# This annotation is required to enable the Consul Connect sidecar injector
consul.hashicorp.com/connect-inject: "true"
# This is the CIDR of your Kubernetes API: `kubectl get svc kubernetes --output jsonpath='{.spec.clusterIP}'
consul.hashicorp.com/transparent-proxy-exclude-outbound-cidrs: "10.96.0.1/32"You add these notations as --set arguments when you install the ngrok-ingress-controller Helm chart.
The connect-inject value uses a set-string, while the transparent-proxy-exclude-outbound-cidrs uses the --set argument.
Everything put together, the install statement would look something like this.
helm install ngrok-operator ngrok/ngrok-operator \
--namespace consul \
--set fullnameOverride=ngrok-operator \
--set credentials.apiKey=$NGROK_API_KEY \
--set credentials.authtoken=$NGROK_AUTHTOKEN \
--set-string podAnnotations.consul\\.hashicorp\\.com/connect-inject=true \
--set podAnnotations."consul\.hashicorp\.com/transparent-proxy-exclude-outbound-cidrs"="10.96.0.1/32"With the Helm charts installed, you configure ngrok through a standard Ingress definition like the one below.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress-consul
namespace: consul
spec:
ingressClassName: ngrok
rules:
- host: codercoffee.ngrok.io
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: frontend
port:
number: 3000
- path: /api
pathType: Prefix
backend:
service:
name: public-api
port:
number: 8080You specify ngrok as the ingressClassName and then apply some rules to provide ingress to your services.
The value for host is any domain you own.
In this case, we’re using codercoffee.ngrok.io.
However, if you’re using at least a Personal plan for your ngrok account, you can also set up your own custom domain.
You can find out how in our how to set up a custom domain guide.
Next, there are settings for two paths, one for a front end service and another for the API.
Now, when you launch your cluster, the ngrok Kubernetes Operator initiates a secure and persistent outbound TLS connection to ngrok’s Cloud Edge platform. Your cluster sends the configuration requirements from your manifest file and then ngrok sets up your configuration across all of our global points of presence in seconds.
That’s all you need to get your application online. And, thanks to ngrok, you can run your Kubernetes cluster in any environment–on your laptop, on a server at the coffee shop, or in a cloud provider–and you won’t need to change any of your network settings.
As mentioned earlier, this story only highlighted some of the benefits of running the ngrok Kubernetes Operator alongside HashiCorp’s Consul. For a detailed guide, with step-by-step instructions on how to set up the ngrok Kubernetes Operator and a Consul service mesh, take a look at the Ingress to services in a Consul Service Mesh on Kubernetes integration guide.