Kat Morgan – Rapid API Developer Success with Kong Konnect

Hello and welcome to Cloud native day. My name is Kat Morgan. I am a developer Advocate at Kong is a connectivity company specializing in connecting people to application services.

So mainly focusing and enabling your users to reach your applications with all of the requirements of a major production. Today, I want to share connect cloud with you. We will be demonstrating Cloud native developer workflow using connectcloud.

That is a cloud-hosted control plane. And we will pay pairing it with a cloud hosted load balancer as well and a local kind kubernetes Docker environment. So I always encourage Cloud application developers to utilize as much of the cloud native tooling during development Cycles as possible.

To mostly most accurately align their development workflows with the final production outcome. Kong as the most widely adopted API Gateway offers a new SAS product that is that connect cloud. To enable a centralized Global control plane as a service.

And you can think of it as a single pane of glass if you will to observe all Global a API Gateway data plane configuration. getting started with it for local development in a cloud-native way is simple and I'll be showing you that now so we're going to go ahead and switch over to sharing my screen here. And you'll see that I have the connectcloud portal pulled up.

So this portal is actually a hosted and Kong's Cloud offering. We are running that on AWS of course and One thing I love about the connectcloud is that the hardest part from my experience in running Kong at a production scale is actually deploying operating and maintaining the control plane itself. So this removes most of that workload from your operations team.

So I'm going to be logging in with my personal credentials today. And I am operating on a free account. So this is a good example of what you can access if you are a developer just using this for your local development workflows.

One of the reasons I'm pairing it with a cloud hosted load balancer is to enable. Interacting with and sharing of development resource across multiple developers if collaboration is required or to share it with CI testing in a way that is accessible to pre-prod scenarios. Even if you're running the development itself locally.

So the first thing we're going to do is actually start up our kind cluster. We're going to have a few dependencies for everything that we're doing today. And you'll see we are installing Helm kind arcade and Kube cuddle.

And these are just gonna be easy paths to achieving that final outcome that we're going to be developing on. Obviously there are multiple ways to install our components. But this is what we're going to run today.

You may notice that I already have these installed. but that is The path to to reaching them. So now we're going to go ahead and create Our Kind cluster.

This should run pretty quickly and then we will be monitoring for the pods to start spinning up. besides running the data plane that we're going to install on our kind cluster here. in kubernetes itself this same data plane can be run directly with a apologies this data plane can also be run either directly as a binary on your local system, or you can run it in Docker if you are developing in Docker locally as well.

So there are a few different ways to actually achieving this outcome besides just the kind or kubernetes method that I'm showing today. so we have our kind cluster and now we're installing cert manager. It is common for I think a lot of operations teams to see and utilize certain manager.

But what this does is just enable more integrated and declarative certificate life cycle management. All right. so let's go ahead and make sure we have our cert manager pods running so now this is something that I'm really excited about.

I mentioned that we're going to be developing locally and exposing this with a public load balancer to do that. There are multiple options. There are things like and engrock and inlets.

We're going to be using inlets the inlets operator itself. And it integrates with a number of different Cloud providers. So if your production is AWS native and you want to integrate into some of those resources plugging this in with AWS is a great option.

Personally today. I'm going to be using digital ocean. And you can see that I'm providing a digital ocean access token here.

So we're going to go ahead and start that now it won't take too long for the cloud-hosted load balancer to go ahead and spin up. we're actually going to see that here shortly. All right while that is deploying we are going to go ahead and see this is adding the helm chart for Kong and this is the same Helm chart.

That is used to deploy the self-hosted Kong Gateway. The self-hosted Cong Gateway can be deployed with a local control plane. But we're just going to be isolating the reverse proxy itself for this deployment with his home chart.

Not going to be a really easy to do. The next thing we're going to do of course is make our Kong namespace to deploy our data plane into and we are going to Jump in now that we have a local cluster ready. We're going to jump into our connect Cloud runtime manager.

So run times can be thought of as logical groupings for your distributed data planes, you might have a multi-cluster or multi-region story or even a global story and the different run times are logical groupings for those different data planes So we're going to come over here and click on create runtime instance. And what this is going to do is allow us to go ahead and run that local proxy and connect up to the connectcloud global control plane API. We're going to do that and like as I mentioned earlier you can do this in Docker you can do this with.

Linux directly on the CLI. We're going to be opting for the kubernetes method today so the next thing that we're going to do is create the mtls certificates. These certificates are how we instantiate trust between the data plane and the cloud hosted API.

So we're going to go ahead and drop this. and a certificate file and then we're going to grab the next one. And this is the private key for the mtls connection.

and now we have both our certificate and our key. so we can go ahead and create the the TL at the mtls secret in our cluster. So now we can go ahead before we do our deployment and Take a look at all of the pods that we're running in our local kind cluster.

and finally before we can deploy we need to go ahead and create our home values. So the connectcloud console has this handy little values file. and of course if I remember it's correctly.

That is going to be our values file. So you can see that we are reaching up to a the cloud hosted API for that control plane. And we are instantiating authentication through that mtls with the certificates that we just provided.

All right. So let's let's go ahead and install our Kong Gateway. And this is going to be the point where we start seeing the inlets operator identify that the data plane is publishing a service of type load balancer in kubernetes.

You will have different types of services. They might be cluster IP, which is for that internal cluster traffic or nodeport. If you're wanting to expose a pod directly to the host ports that it is running on or in our case.

We're going to be operating. With a load balancer and this is going to connect up to that digital ocean instance that inlets operators. Correct creating.

with a tunnel making everything that we're developing locally publicly accessible. and we're going to see how we actually control the traffic that is allowed in here in just a moment. So let's go ahead and they might get a couple of Crash loops on the proxy tunnel while that's spinning up.

There we go, and we're going to go ahead and stop and take a look. at our digital ocean console And again if you're using Azure or AWS, you can integrate there. 99 instance.

And the next way to actually identify that that is the IP address that we have attached to. our load balancer This is by going ahead and taking a look at the services in the Kong namespace. And there it is.

So now we have the Kong load balancer service and it has that same IP that is associated with that load balancer in the cloud. Um now we're going to go ahead and start utilizing we're gonna create two different Services. We're going to create a service that the data plane that Kong Gateway proxy container.

Will point to outside of the cluster and then we'll create a service that shows something deployed inside of the cloud the cluster itself. Alright, so the service that I'm going to be using external to the cluster is called mock bin. It's a place where you can go to.

create mock endpoints API endpoints we're going to drop that right here and In here, you can configure all kinds of things. I can figure it a very simple just plain text response and we're going to take a look at that in just a minute. So now that we've installed we're going to click done on adding our runtime instance.

You can see I have this one. It's last seen just now and it is in zinc. So the next thing we're gonna do and we're just scratching the very surface of the possibilities with Kong Gateway And the connectcloud but we're going to jump in here and create a service.

This is just a named pointer to the service itself. So I'm going to name this service. Mock bin will do.

we are going to practice a pretty rudimentary method of this right now. And we're gonna call it. com.

That is the Upstream service. And we're not configuring anything wildly fancy. We're just using Port 80.

We're not getting into TLS certificate integration right now, but all of that is available. and of course So now that we've created the service and we've established what the Upstream is. We're gonna come in here to the routes.

We're going to add a route and it will allow us to select the mock-in service that we just created. We're going to name the route machbin because I'm feeling unoriginal today. And the host is going to be the IP address of the load balancer itself.

io or any other methods like editing Etsy hosts to point out this target. But for the moment, we're just going to go ahead and use the IP itself. and then in the methods we can go ahead and just Itemize, ah, I hit enter.

We can go ahead and itemize all of the various methods that we want to allow against the said point. We're only going to be practicing the get endpoint. So all of this is a little excessive but those are available.

Finally the route needs to be accessed at a path at them at a minimum. We can access it at the root path of where we're going to name it bin. And that's going to be our path here.

There are other Advanced configurations that you can set up like strip path, but we actually don't want to strip the path for this one. All right. So at this point we should be able to call them mock bin.

service Upstream at this URL So let's take a look. And we're gonna do Ben. And we are going to run.

with a special endpoint that I created. It's never DNS right except for when it is and it always is. Okay, so that was creating an upstream service and accessing it through the load balancer.

That pointed down to our data plane and then reached back out to the Upstream mockman service that is publicly available on the internet. Another alternative is that that could be a service on my local network or inside my cluster. We are going to go ahead and jump to Cluster internal service now.

And we're just going to do a simple nginx. Container, so we're going to run that here. and I'm gonna check that our services running.

This is our service here. I'm going to be really lazy at the moment and run directly off of the IP and the cluster. This could be don't domain name resolution inside the cluster instead.

So again, we're going to go to our Gateway service. And we are going to create a new service. We're going to name this.

and Gen X our URL is going to be that cluster IP address. And we are using Port 80. and then we're gonna save that.

What did I do? We're going to do the path at the root. and now we have our Upstream nginx service.

So again, we need to create a route that pairs with that. and it'll be quickly like the last one but nginx service appears here. We're going to name it nginx.

And my autocorrect on this new system is driving me crazy. We're going to go ahead and set our methods to just get. and the path Which is how it distinguishes between whether it's going to that mock bin service or engine X?

Is going to be nginx. Again, we're leading the rest of everything pretty safe. Similar we are stripping the path.

So that it reaches the service itself at that root of the path. and so again, we're going to find the IP address of that load balancer since we don't have DNS set up for this yet. See that's how I'm skirting the demo gods.

And we're going to type. Nginx as that path. So here you can see that we were able to quickly deploy a local developer environment and still integrate into things like cloud-hosted control planes that are valid for our production workloads and Keep our development environment in its own runtime workspace.

And publish our development resources publicly. and publish both a an application internal to Our Kind cluster and an application external to Our Kind cluster the same ways now all of this was heavily web UI driven, but there is also an automation API, which allows you to create a get-ups workflow for declarative configuration or create your own application logic to configure the global control plane as part of your CI pipeline tooling. with that it was a pleasure introducing you today to the Kong API Gateway if it's new to you and to the cloud hosted connect Cloud platform.