About this video
What You'll Learn
- Expose a Kubernetes service through ngrok without creating a cloud load balancer.
- Install the ngrok ingress controller with Helm and verify the created resources.
- Attach an ngrok module set to enforce Google OAuth access.
Walks through ngrok's Kubernetes Ingress Controller as an alternative to a cloud load balancer on EKS. Installs the controller via Helm, exposes a service through an Ingress, then layers on Google OAuth using an ngrok module set CRD.
Jump to a chapter
- 0:00 Introduction
- 0:35 Comparing to Traditional Cloud Load Balancers
- 2:28 How the ngrok Controller Works (Architecture & Benefits)
- 3:26 Configuring the ngrok Ingress Resource
- 4:05 Installing the ngrok Controller
- 4:39 Applying Ingress and Verifying Deployment
- 5:04 Testing Basic Ingress Access
- 5:28 Introduction to ngrok Middlewares
- 5:44 Configuring Middleware with Kubernetes CRDs
- 6:15 Applying Middleware via Ingress Annotation
- 6:36 Applying the Configuration
- 6:48 Demonstrating OAuth Authentication (Success)
- 7:18 Finding CRD Documentation
- 7:33 Demonstrating Access Denial (Failure)
- 7:44 Conclusion
Full transcript
Generated from the English captions. Timestamps jump the player to that moment.
Read the full transcript
0:00 Introduction
0:00 Hello and welcome back to the Rawkode Academy. I'm your host David Flanagan, although you can find me across the Internet as Rawkode. Today we're taking a look at a new ngrok controller for Kubernetes. This ngrok controller is different from all the other ngrok controllers And you'll find out why in just a few moments. This ngrok controller is from a company called ngrok. Yes. The company that provides a CLI that tunnels your local development environment onto the Internet for you to share with anyone you want. They're now entering the Kubernetes ngrok space and like I said, it's a little bit different.
0:35 Comparing to Traditional Cloud Load Balancers
0:35 So before we dive in to what's different with ngrok, let's take a look at this traditional load balancer approach on EKS, the managed Kubernetes service from AWS. First, we have some pods and a service. We have the clustered v one application, which is just a video of me tapping my watch. It's exposed currently only within the cluster as a cluster IP service called clustered v one. Now if I want to expose this to the Internet, I would go to Versus Code, open the v one YAML, and change cluster IP to a load balancer. We would then come back and reapply our
1:17 configuration for v one. Now when we run get service in the background, AWS has something called a cloud controller manager. And in fact, this is true for all cloud providers. It monitors for load balancer services and provisions a cloud load balancer. In this case, a classic load balancer on AWS. This gives us a domain name that we can then curl on the right port. Now these take time. Cloud load balancers typically take anywhere from two to three minutes before they'll start serving traffic. Not only that, they're quite expensive. So a classic load balancer as provisioned this
1:53 way by requesting a load balancer service will typically run around 18 to $20 per month per load balancer. So if you go down this path and do this for all of your services that you need to expose, you can end up paying more load balancers than anything else. And let's not forget, you've also got to pay the gigabytes of traffic submitted over the network too. Okay. So let's run it again. And now we have our exposed service via the expensive ELB. But we don't wanna go that route. So let's revert this to cluster IP and reapply our v one YAML.
2:27 Now I said the ngrok's approach was a little bit different. So if you want to learn more, well, watch this video, but also check out the release blog on ngrok.com. If you scroll down just a little bit, you'll find an architecture diagram for how this works. Now ngrok ngrok controller does not use in cloud provider load balancer at all, meaning you don't need to pay for one. What actually happens is that they have the ngrok ngrok service, which sits between your cluster and the Internet. As your quest comes in, it hits the ngrok service, which will tunnel the traffic through to your
2:28 How the ngrok Controller Works (Architecture & Benefits)
3:01 ngrok's controller and through to your application. There's also a little bit of magic sauce, and that is that when you go through the ngrok ngrok service, you can also take advantage of all of their middlewares. So on today's demo, we're going to deploy the ngrok ngrok controller, attach a middleware for authentication to protect our application, and it's gonna be faster than the ELB. Let's take a look. So let's go back to code and open ngrok ngrok dot yaml. Here, we have a standard networking v one ngrok object where I've set the ngrok class name to be ngrok.
3:26 Configuring the ngrok Ingress Resource
3:36 We have the back end configured to root everything on slash as a prefix to clustered v one on the correct port. However, we need a host. So we're gonna go to the ngrok portal where we can ask for a new domain. Now everything I'm doing today is on the ngrok free plan, which gives you access to one domain. We paste this in as the host and remove the ngrok CLI stuff. Like so. Now I also have a just file here that has a helm upgrade install command. This installs the ngrok ngrok ngrok controller. For more details on how to install the
4:05 Installing the ngrok Controller
4:17 ngrok controller, you can go github.com/ngrok/kubernetes-ngrok-controller, where the instructions to add the repository and configure the installation are all available. But for us, we're just going to run just ngrok to run the helm upgrade command, which consumes my API token and authentication token from my environment. We can now do a kubectl apply on my ngrok resource. Now we can run kubectl get pods service ing. We'll see the ingress controller is running. We still only have a cluster IP service and no other load balancer service available, and our ngrok is here. So let's head back to the ngrok portal
5:04 Testing Basic Ingress Access
5:04 where we're now on the endpoints page. We'll give that a quick refresh, and we now see an endpoint created by the ngrok ngrok controller. We can click on this and we see it's configured to the edge. This just means that our back end is available for the app. So let's click, and right away, we have the video where I'll tap on my watch. Now ngrok metalwares can be configured through this portal too. If you want to enable MTLS, you can. TLS termination, sure. Circuit breakers, yes. Compression, IP restrictions, OAuth, OIDC, request headers, response headers, SAML, and webhook verification.
5:44 Configuring Middleware with Kubernetes CRDs
5:44 But, of course, we don't want to configure this through the ngrok UI. As nice as that is, let's keep this Kubernetes native. So let's go back to Versus Code where I have a google.yaml. Here, we're going to create a custom resource. This is an ngrok module set. We're gonna call this Google auth and what we're saying is enable the auth module, the Google provider, and only allow access to this application with the email address david@rawkode.academy. We can also update our ingress to take advantage of this module set. We do this via annotations where we set
6:15 Applying Middleware via Ingress Annotation
6:22 case.ngrok.com/modules and we say apply Google off. Now I've called this Google off because it has a single module, but you can enable multiple modules at the same time. So now we can go back to our terminal and we can apply a Google authentication module set. We can reapply our ngrok with the new annotation. So let's head back to the portal and click on our application again. This time, we get presented with a Google OAuth flow using ngrok.com as OAuth application. We click login and there's the video. Let's go to OAuth and hit refresh. You can see here it's
6:48 Demonstrating OAuth Authentication (Success)
7:05 configured on the back end using a managed ngrok application. Of course, if you want to bring your own OAuth application, all you need do is add a client ID and client secret to the CRD. You can get all the details you need from kubectl explainngrokmoduleset.modules.0auth. You can then add to Google and you'll see everything you need is documented. So let's just try that again from another browser. This time I'll switch to my personal profile which has a different Google account. We click login and we get access denied. So that's pretty sweet. You can expose an
7:44 Conclusion
7:47 application in Kubernetes with the ngrok ingress controller, take advantage of their middlewares and avoid load balance or fees with your cloud provider. So go check out ngrok ingress and get started today for free. Go have some fun.
Technologies featured
Stay ahead in cloud native
Tutorials, deep dives, and curated events. No fluff.
Comments