[music] Welcome to another episode of the Kubernetes Gateway API series. If you're new to Gateway API, this video might not be for you, and you need to watch this video, which is the introduction to Gateway API. In that video, we cover what it is, how it works, how to use it, and how we use Gateway API to route traffic and perform traffic management within your cluster. In this video, we'll be focusing specifically on Envoy.

This series will help you understand the different gateway API implementations, their features. We'll highlight their pros and cons, so you can make a better decision to choose which gateway API is right for you. So, be sure to like, subscribe, and share. And without further ado, let's go. [music] >> [music] >> In our introduction to gateway API video, we created a Kubernetes cluster using kind. Once we have our Kubernetes cluster ready to go, we go ahead and install the gateway API CRDs using cubectl and we use the experimental version.

We apply that to our cluster and that enables our cluster with gateway API features. It gives us the ability to say cubectl get gateway class gateway http routes and other routes. Then we set up some example applications. This includes a python microser, a go microser and a web front end. We apply that to our cluster using cubectl. Then we have applications we can now use for testing. Then we proceed to create some test domains like exampleapp.com, exampleappgo.com and exampleappyon.com.

We use a host file to simulate these domains. In a real world, you'll also need TLS. So, in my guides, we use HTTP and TLS. We use a tool called makesert, which allows us to generate a CA and generate a browser trusted TLS certificate using makesert install. We then go ahead and apply that certificate to our Kubernetes cluster. So now we can actually use HTTPS and mutual TLS. This now gives us a cluster with gateway API enabled features, TLS certificate for HTTPS and a few example applications.

So we can test traffic routing and gateway API features. So now we can go ahead and set up a gateway and a gateway class. But before we do so, what is Envoy? We firstly need to appreciate what Envoy is because Envoy is not only a gateway API that we'll cover in this video. Gateway API is just one of its features. I always start with the official documentation. Envoy is an open-source edge and service proxy and it's designed for cloudnative applications.

So on the docks, Envoy is an L7 proxy and communication bus designed for large modern serviceoriented architectures. So think microervices. So when we think of layer 7, we think of HTTP like web and microervices. Think of traffic routing. Routing by host name and routing by path. Kind of like an ingress. It's more important to know that envoy is a lot more than that. At its core, envoy is actually an L3 L4 [snorts] layer network proxy.

When we think of layer 3 and four, we think of lower level network layer communication, things like TCP and UDP. So it's actually a lower level network proxy than most ingress and gateway API controllers out there. Now the reasons for this is that Envoy is a lot more than just a gateway API. It's a lowlevel network proxy and it is designed to run and support an out of process architecture. So what does this mean? Envoy is designed to run side by side with applications.

So it's outside of the process of the application. That's basically what outofprocess architecture means. In a serviceoriented architecture like microervices, you often have services calling other services and those ones calling other ones. And you have this whole network topology of services talking to each other. For these service to talk to each other, developers have to write code like HTTP clients. And developers often resort to writing and creating libraries to facilitate this communication.

So if you build something like a product API, you want other developers to interact with that API. You may write a library that they can consume and use the library or SDK to allow clients to call the product API. So in that library, you will have code that allows you to call the API. So interact with services. So to perform retries when a call fails, exponential backoff like circuit breaking when requests fail too often.

Rate limiting to avoid many requests. And a lot of this happens within these libraries within code. Now think of if I want to patch a vulnerability or a bug in this library, I have to deploy all my microservices. So not only do I disturb the product API, but all of the APIs. So, Envoy allows us to move this logic out of process. This means we can run an envoy proxy side by side with each application. So, all the traffic coming to service A or service B or service D and C will flow through envoy proxies first.

And these proxies can perform things like rate limiting, circuit breaking, automatic retry, and other tasks without our product API even being aware. Envoy can also do things like load balancing. So when these servers calls each other, they can load balance to pods or instances on the back end. Or you could use envoy to be a mixture of these processes. So you can use it as an internal load balancer, an ingress proxy in the front, an egress network proxy at the back or sidecar out of process services.

So you can see envoy is a lot more than just an ingress or a gateway API. It's a proxy that is used to build things like service meshes. Think of things like So now that we know what it is, how do we run it? But when it comes to installing Envoy, Envoy runs on Linux as well as Mac. It runs in a container. So it's very portable. And as it runs in a container, we can also run it on Kubernetes. Now, it's also important to know that we can run Envoy on Kubernetes using the Envoy Gateway.

And there's a Helm chart for that. And the Envoy gateway has its own separate documentation site. And you'll find a link over here. This will take you to the Envoy gateway specific documentation. Now, as we've seen, Envoy proxy can be very complicated because it requires an understanding of deep networking. The Envoy gateway project uses Envoy as a proxy and allows us to implement the gateway API solution. So, using the Envoy gateway API is a lot simpler than using raw Envoy.

The envoy gateway API implementation helps us simplify the management and creation of envoy proxies. It simplifies it. We can use its features quite easily and it has a lot of extension capabilities. So today we'll go through this documentation. We'll take a look at installing envoy in our cluster and then some examples following the concepts. Now under the installation section we can see that there are many ways to install this.

We can use Helm, Argo CD, raw Kubernetes, YAML. They also have a CLI tool and an add-ons Helm chart. This is for add-ons, things like open telemetry, collectors, and Prometheus instances for observability. Today, we'll take a look at installing this using Helm. You can also install the CRDs for gateway APIs separately as well as the envoy gateway CRDs using the gateway CRDs Helm chart. To deploy the gateway API controller, I've recorded all the commands that I'm going to be using.

So I have the chart version in an environment variable and I use helm show chart pointing to the gateway API helm chart for envoy to show me the available versions and then that allows me to select a version. I can put that in an environment variable and then use the helm install command to go ahead and install that. Now before I install any Helm chart, I'd like to get the values file out of to see the default settings so I can see what I can customize.

It gives me an idea about all the customizations and the inputs for the chart. So for that I generally run helm show values and I output that to a file and I'm just going to call it default values. This will give us all the default values. There's some global settings on like the image you want to use. If you're building this yourself and you have your own image registry, you can use custom image names. There are settings to change the deployment.

So, anything related to the deployment like CPU and memory limits, number of replicas you want to run, what ports are exposed, any service settings for the Helm chart, horizontal pod autoscaling, and here you'll find envoy gateway configuration settings. We'll take a look at this in a bit. cert used to generate certificates used by envoy gateway and those are all the defaults. When I use a helm chart, I like to define my own values file.

This allows me to explicitly override certain things I want to in the future. So I'm just going to go with a very basic values file to start off with. First one is the controller name. When we taking a look at gateway API, we know that there will be things like a gateway and a gateway class. The gateway class tells the cluster what controller will be used. In our Helm install, we're going to be installing an envoy controller.

So, we need to provide the same name. So, I'll show you this in a little bit. The other one is just log settings. I can set the log level here and control verbosity of the log. So, I can see things like errors, warnings, and information or debug messages. This is great for triing out and testing and playing with these gateway APIs. So that is my basic values file to start off with. So first things first, I'm going to go ahead and set my version that I want for the chart.

And then I'm going to say Helm install. So I'm going to install the gateway Helm Helm repository. Pass in the version. Pass in my values file. I'm going to tell Helm to create a new nameace to put all of this stuff in. And that is it. Go ahead and run that. It'll take a couple of seconds to install. An envoy takes a while to get to this page, but after a good couple of seconds, you should see output like this. It does give you a message to be patient.

If we make any changes to the values file, we just run helm upgrade with the same settings. Then I like to check my installation by running cubectl and just getting the pods to see what is going on in that name space. I go ahead and run that. We can see we have one gateway pod running. It's important to know that in gateway API, this is the actual controller. This one is like the orchestrator that creates all the gateway APIs.

Unlike other gateway APIs we've seen, this is not the gateway API pod that will be taking our HTTP traffic. I also like to check the controller logs to make sure it's all healthy by running in that namespace just doing a minus L on logs and getting the envoy gateway logs on the output. So I go ahead and run that and we can see it looks good. Starting controller and workers and there are no accepted gateway classes yet.

So we still have to go ahead and create that. Now that we have the invoic controller for gateway API installed, this is not the gateway API proxy itself. This pod that's running is a controller and it will manage the CRDs that we'll be applying such as envoy classes and gateways and so forth. Envoy works a little bit different to the other gateway API controllers we've seen so far and we'll see why. Let's go ahead and install our gateway and gateway class.

Firstly, we'll start with an envoy gateway class. This is a simple cubectl apply and as we covered in our video on gateway APIs, the gateway class is not specific to envoy. This is the thing that the cloud infrastructure providers supply to the cluster administrators. It tells our cluster what controllers are available in the cluster for use. So we create this one called gateway class. We call it envoy. And this is the controller name that will implement this gateway.

This is the same controller name we've put in our Helm values file. So when we install this gateway class, our gateway controller will go ahead and accept it. This object also doesn't live in a name space. So we can just say cubectl get gateway class. We can see the class is there and it's now been accepted. You can also QCTL describe this to troubleshoot why it might not be accepted. Our gateway controller will now sit and listen for events when somebody wants a gateway.

So let's go ahead and define a gateway. This is another simple cubectl apply command. So a gateway is very simple. We give it a name and a namespace. And gateways are namespaced as we've learned before. We hook it up to a class so that the cluster will know that this gateway will belong to the class we created earlier and the controller on that class will implement this gateway. Infrastructure labels is something we looked at in our introduction video.

This allows us to put labels and annotations on any infrastructure that is created by this gateway. So here we can add labels and annotations to things like the deployments and the pods and the services that get spun up off the back of this. Then I have listeners. Now listeners are the core components of gateway. It allows us to basically define what ports are exposed and how traffic comes into our cluster. So we create a listener for HTTP.

We're exposing a protocol and a port and the allowed route that's allowed to attach to this gateway. We covered this in our introduction guide, so I'm not going to recover it now. Then we have another one for HTTPS exposing HTTPS and port 443. We say we want to terminate TLS. Here is the certificate I created earlier. So the gateway will know what certificate to use for TLS and it'll terminate everything at the edge.

This means we don't need TLS on every micro service we build. And upstream traffic will go to the upstream service port. Then we also have allowed routes and in here we only allow routes from the same name space. So, HTTP, gRPC, TCP, and UDP routes can only attach to this gateway if they are in the default name space. So, I go ahead and apply that. And that gives me my new gateway API. Now, when we apply this gateway that we just did, we'll notice new gateway API pods.

Let's take the cubectl command. Go ahead and say get pods. And now you can see not only do we have the gateway controller we deployed earlier. This one came from the helm chart. We now also have this envoy default gateway API. This pod over here has been created by our gateway that we've just defined. The more gateways we define in different namespaces, the more of these pods will spin up. So we'll get a dedicated gateway for each gateway we apply.

And Envoy is great at this. It allows us to manage a fleet of gateway APIs. You can do this. Maybe you want to separate the traffic and the load balances per department. And there might be other reasons why you may want to do this. Or you can just keep one and scale the number of replicas just like you've done potentially with ingress. We also have a new service that would be created. So if you say cubectl get service, you will see an envoy default gateway API service.

This default over here represents the namespace we deployed that gateway in. So all the actual infrastructure will live in the envoy gateway system namespace even though the gateway lives in the default namespace. And you'll see here its type is load balancer. We don't have load balancing here in this kind cluster. So we'll use port forwarding to test it. And here you'll see port 80 exposed and port 443. And these are our listener ports we defined on the gateway YAML.

Those two listeners. And that is as simple as that. That is how you create a gateway API in your cluster using Envoy. Now to get a feel for Envoy itself, it's important to dive onto the documentation and look at the concepts page. This talks about key concepts that are specific to Envoy Gateway. So you can see its strengths. And when you scroll down, you'll see this image that represents the different resources for Envoy Gateway.

So the blue ones are the ones that are Kubernetes default. So the CRDs we installed like gateway classes, the gateway we applied and then things like TLS, TCP, UDP, gRPC and HTTP routes that we'll take a look at in a little bit. These other resources on the right hand side here are provided by the envoy proxy CRDs. Things like client traffic policy, security policies, backend traffic policies, extension policies, route filters, and more.

The first one I find interesting to take a look at is the envoy proxy CRD object that attaches to a gateway class. To find that envoy proxy, we go to the documentation on the left side. Go to gateway API extensions. And here you'll see all the different types of extensions. We'll take a look at the important one is the envoy proxy one. Now, this text may be a little bit small over here, but it basically says it allows us to configure the envoy proxy fleet.

So, we can make changes to the actual Envoy proxies. defined by the gateway class and this envoy proxy CRD allows us to do so. If we take a look at the envoy proxy spec, you'll see we can change things like the provider, things like logging, telemetry, so observability settings. We'll take a look at this in a bit. If we go to provider, we have different providers. There's Kubernetes. If we click that, you can see we have envoy deployment as a field and damon set and service.

So this allows us to customize the actual deployment the service for the gateway APIs that we've just created now. So we can do things like change the number of replicas and I think this is important for a production grade deployment. So to do this in my example I'm going to use the envoy proxy CRD and I've just shown you we can change the deployment or the service by applying this YAML file and this is how you do so.

We're basically going to inject something on the gateway class we just created. So previously we only had the controller name as well as the name of the gateway class. Now gateway class allows us to add this extra field called parameter reference. So we can inject parameters into the gateway class and then basically change it. So here we're using the envoy proxy io kind is envoy proxy. This is that object we've just taken a look at in the documentation.

We give it a name. I'm just going to call it our gateway configuration and a namespace where this will live. So we'll put that in the system namespace that we defined where we had deployed the helm chart in. So that is the update to the gateway class and that points to this configuration object we need to create. So then we specify that one using kind as invoy proxy give it the name same name as above and here you might notice a few things we've just taken a look at.

So remember that provider we taking a look at. We say provider. We say types Kubernetes. Under Kubernetes we have this thing called envoy deployment. And here I can change anything I want to about that deployment. I can add extra labels and annotations. But what I find is important is setting the number of replicas to something more than one to make it highly available. So I go ahead and do that. And then for the invoice service I want to give it a name that is deterministic. so that I could put something like a CNAME to this load balancer if I have a cloud load balancer and a DNS that I want to tie to it.

So that is basically it. We'll come back to this file to introduce some more settings later on. I can go back to my terminal and run cubectl apply and apply that YAML file. Now that has created our envoy proxy configuration and configured our gateway class. After applying that we should now see two replicas. If we do a get deploy, you can see we now have two replicas on that deployment. And if I do get pods, you can see we have two gateway API proxies running.

Now we can also do get service. And we can see that we now have a deterministic name for our load balancer service. And we can go ahead and port forward to that load balancer service. This allows us to test it out without having a load balancer. [music] Now, Invoy Gateway supports all the basic default gateway API features such as traffic routing. So, we can manage HTTP traffic using different routes. For example, we've taken a look at HTTP route in our introduction video.

This allows us to set up our gateway API as an API gateway. So, we can do things like route by host name, route by path using URL rewrite, header modification, and HTTP and TLS. Now, since we have our example apps deployed to the cluster, I'll quickly run through these basics, but I won't cover them in detail as we've already done so in our introduction video. So, check that out. So, routing by hostn name allows us to route by host or DNS value.

Pretty much the host header in the HTTP request. So, we can do things like send all exampample app-pon.com to the Python service and all exampleappgo.com to the Go. This is what an HTTP route looks like to route by host name. We define the name of our route. This one is for our Python service. We define how we want to attach to the gateway. We then specify the host name and which backend we want to go to. In this case, the Python Kubernetes service on port 5000.

We have another one for the Go application called Go route. This one also attaching to the same gateway using the Go domain and pointing to the Go Kubernetes service. In the command line, I can apply that change. This will create our two HTTP routes. I can then go to my browser, go to exampleappgo.com since we have that in our host file and I can hit the go service. I can hit the example app python.com and hit the python service.

So that is how you route by domain or host. We can also route by path. So based on any path, we can route to an upstream server. So here we just have slash. So we still use the same domain names but the exact path will go to the upstream service. This is called exact matching. We can also do something called path prefix. So we can pass anything after the path to the upstream service. To do this we override our HTTP route.

Still the same name, the same gateway, same host name, but this time we put a type on the path value. So we introduce this path object and we say we want the exact path which is slash to go to the upstream. We do the same for the go route. If we scroll down, we also use type exact and the value is slash. We jump to the terminal. We update our Python and go routes. Now from a URL standpoint, nothing has changed. [music] If we refresh this, we still hit the Python service.

If we hit the Go one, we hit the Go service. But notice that I cannot go to any other URL like status that hits a 404 on my gateway API. This is because we've used exact matching. I can change this to something like a path prefix. That pretty much means that /star will be passed to my upstream. So any URL I pass in from the client will go to the upstream go micros service. If I go ahead and update that route, we refresh this page.

We can now see that I can hit the status endpoint on my go service. So path prefix may be more useful to you. Then we can route using URL rewrite and this is more popular because this allows us to act as a true API gateway because now we can consolidate all our services under one domain. So we got exampleapp.com and we can say something like /appi/python go to the python service and API/go go to the go service. It also means that we can go deeper.

So API go/ status will go to the go service and it'll go to the status page. So to do that we'll take a look at URL rewrite. So we got our same HTTP route. This time we attach to the same gateway but we change the host name. Now we're using a reusable single host name. So all our services will live under exampleapp.com. Then we update our path this time to path prefix and we say api/python will be our prefix. We then use a specific filter.

We covered filters in our introduction video and this filter type is the URL rewrite filter and it takes some configuration values. In our case, we say type is replace prefix match. So what this will do is this will replace the prefix we specified at the top here. So it will replace the matching / API/python and it'll replace it with slash. This means when we pass the URL to the upstream, anything behind API Python will pass to our backend service.

And then we have the same for the go route. So the name is go route. We have the gateway. Same host name. We say the path prefix here is API/go. And we do the same URL rewrite here. I can jump to my terminal and go ahead and apply that to configure my routes. Now if I refresh these, we'll see that they don't no longer exist. So I get a 404 because our microservices have moved. So now we can hit the exampleapp.com page and we can see it still gives us a 404.

That's because we don't have any routes serving this domain. We can hit each of our services saying /api/go. That'll hit the go service. And we can even go further and hit the status endpoint and that will send status to the go service. We can do the same for python. API/python will hit the python service. So that is how you do URL rewrite and routing by path. Next up, we can also do header modification. And we do this using the response header modifier filter.

Just like we did the URL rewrite filter, this is just a different filter. This means we can modify request and response headers. To achieve this, I'm just going to update my go route. Keep it exactly the same as it was before. same host name, same path prefix we had before, but this time I'm going to inject an additional filter called response header modifier. And then we can do things like we can ask it to add certain headers.

We can also remove and update headers. Here you can see I added a header called Xcustom header and I also added some course headers as well. I can go ahead to my terminal and apply that YAML file. And if I go back to my Go micros service in the browser, refresh this page and I have the network tab open, we can see our custom header has been added. So the gateway API allows us to manipulate headers. Then we also have HTTPS and TLS.

So in the beginning of this video, I showed you using makes it to generate a certificate, installing that locally, and then applying that as a secret. Now to enable TLS in our gateway, we need to update our listener, the HTTPS listener to make sure that it's configured correctly. So just to review that, we jump back to our YAML for our gateway. We have our HTTP listener. We're not going to need that now, but we're going to need the HTTPS listener.

You got to make sure you have that you have TLS set and you're pointing to a secret. Also make sure when you cubectl describe this gateway that it's been accepted and there are no issues with TLS. It'll tell you if your certificate is not found. Then the second thing you need to do is make sure your HTTP route is pointing and using that listener we defined. So reviewing our go HTTP route, we used to have just one parent reference pointing to a gateway listener pointing to the HTTP one.

You have to add a new entry and make sure you point to the HTTPS one. In production systems, you may want to think about disabling the HTTP one if you don't need it, but this is how you tell the route to bind to the right port on the edge. The rest of the HTTP route rules remain all the same. Then I hop back to my terminal. I go ahead and apply that. And now my HTTP route should attach to the HTTPS listener, which means I can access it through port 443.

To do this, I just need to jump back to my port forward. Ctrl C to escape from that one and open port 443. Now I can go to my browser and access https. And you can see we're hitting the okay page. Our connection is secure and we can see our makesert certificate. This means now that our example app.com/appi/go can be accessed over https and will route internally via http to our go service on port 5000. Feel free to check out the official guides for more HTTP route and other routes.

All of these examples should work on any gateway API implementation as these are the default basic features that all of the gateway API controllers implement. So that is the gateway class, the gateway as well as the routes. Now envoy proxy also has its own objects. We've taken a look at the first one which is the envoy proxy CRD used to manage the class and define settings for our invoy proxies. Next up, we'll take a look at the client traffic policies.

Client traffic policies are policies that allows us to define how the clients interact with our gateway API proxy. things like TLS termination, validating certificates, TCP keep alive, enforcement, connection limits, and timeout settings. Pretty much anything on the client end. So the client traffic policy sits under the gateway API extensions. So you got client traffic policy under there, security policy and back-end traffic policy.

The client traffic policies allows us to configure how the envoy proxy server will behave with downstream clients. So in this video, we'll take a look at what a client traffic policy looks like. We'll take a look at an example how to set connection limits to limit the number of connections to a specific gateway. So a client traffic policy looks like this. You say kind client traffic policy. You give it a name. I'm just going to call it connection limit policy.

It also lives in a name space and we can attach certain things to the client traffic policy. So here we use the field called target reference and we point this to a gateway in our case our gateway API. You can see this points to an entire gateway and then we can specify settings that are specific to the type of client policy. In this case connection we set a connection limit of five. So this will limit the number of connections made by clients to this entire gateway.

It's important to know that client traffic policies can be attached to gateway API resources using two targeting methods. We've used target reference where you explicitly reference a specific gateway to attach by name and kind. Then you also have label selection which is cool because you can dynamically match gateway resources based on their labels. There's also precedences to be aware of. This is not something I'm going to go into too much depth in this video, but they talk about the order of preferences that policies will take in terms of a priority.

For example, Envoy Gateway resolves conflicts using section level specificity and creation time priority. For example, section specific policies, so targeting listeners via the section name will take the highest precedence and policies that are targeting the entire gateway will take a lower precedence. Multiple policies at the same level will use certain priority like creation time. The oldest policy takes precedence as well as namebased sorting.

So policies with identical creation times they are sorted alphabetically by namespaced name with the first policy taking precedence. So as an example here what I'm going to do is I'm going to install a basic tool in an Alpine container called hey. This is a load testing tool where we can say we want to open up 10 connections over a period of 10 seconds and we're going to hit our go endpoint. So in Alpine I can just say APK add hey I can run this quick test and we can see that the test succeeds and I'm getting 100 responses of HTTP 200.

When I go ahead and apply the connection limit on my gateway using a traffic policy and I go ahead and rerun that test again, you can see that we're now getting less HTTP200 responses. So our client policy is effective. Another client traffic policy that's quite useful is mutual TLS. So currently we have a listener for TLS that has HTTPS enabled, but for normal TLS or HTTPS traffic, the client does not have to pass a private key.

So we can also enable mutual TLS if we want microservices to talk over TLS and handshake with a private key. This might be good for internal HTTPS communication as well. So firstly I have to create a new secret that holds my CA certificate that I created using makesert. So we tell envoy about the CA certificate. I go ahead and create that TLS secret. I can then use makeert to generate a new client certificate. And in our case, our client will be for curl.

Then we can go ahead and create a new client traffic policy. I'm going to call this one MTLS policy. So I want to enforce mutual TLS on my go service. So here I target a specific gateway and more specifically a listener. So I use section name HTTPS. So I'm targeting all HTTPS traffic in this case. and I specify a TLS section. I give the client validation field and I indicate what CA certificate which is a secret that I want it to refer to.

So here I'm telling invoy proxy about my mutual TLSCA certificate and it will use this to validate client calls on the client side to make sure the clients are trusted when they handshake TLS. So I can jump to my terminal and apply that. I also make sure my port forward is running on port 443 for testing. If I try to go back to the browser now and refresh, you can see the browser can no longer talk to HTTPS. This is because mutual TLS is on.

So clients need to pass a TLS certificate in order to communicate and do the handshake. So to demonstrate this, we can use curl and we can pass the certificate details to that endpoint. When we do that, you can see we get an HTTP 200 and the handshake and connection has been successful. So that is all client policies. Next up, we'll take a look at backend traffic policies. That basically is a policy that defines how Envoy interacts with backend or upstream services.

You will also find this document under the gateway API extension section. It's called backend traffic policy. And basically what this is is controls how envoy gateway communicates with your backend or upstream services and kubernetes or external services. So think of this as the controller between your gateway and the backend services. It can detect problems, prevent failures and optimize request handling. More importantly, what I wanted to cover here is the target.

How do you attach back-end policies to gateway API? And you use it using two targeting mechanisms. So either directly using a target reference or label selectors. So you can attach back-end traffic policies to things like HTTP routes. This is an example of a circuit breaker. So in this section here, you're using a direct target reference pointing to a route. Whereas in this example, you use a target selector using label selectors.

So you can attach to routes based on labels. This allows dynamic matching. And here's an example of a rate limit. The cool thing here is quite dynamic because you can target various gateway API resources. So things like a gateway, an HTTP route, gRPC, TCP, UDP, and TLS routes. Important to just take a read on the precedence if you're planning to use multiple traffic backend policies. You want to make sure you understand the priority and their precedence.

So I'll show you an example of what a back-end traffic policy can look like. And we'll just use some local and global rate limit examples here. So we can rate limit each of the HTTP routes using a local rate limit. And this is again a simple YAML file. So here we have the backend traffic policy. I'm going to call this one rate limit go HTTP route just so we know what it does. It is targeting an HTTP route called go route.

This is our go route we created earlier. And here I'm specifying a local rate limit setting. So basically we can rate limit based on HTTP headers here. This is an example of a user ID based rate limiting strategy and I can say I want to limit this to three requests an hour. You can do per second, per minute or whatever you like. Before we apply this, let's just take a look at this curl command. So if we run curl, this will make a request in a loop four times and you should see 200.

Okay, for all four of them. When we apply our local rate limit on that HTTP route, we try to rerun this curl. You will see that we're now getting rate limit headers back with an HTTP 429 too many requests. So, our rate limit is working. You can learn more about this if you expand the task section on the documentation. Go to traffic. You'll find all the traffic management tasks over here. Here is local rate limit which talks about the features of rate limiting.

It has two types of rate limiting global and local. Local applies to rate limits to traffic flowing through a single instance of envoy proxy. Whereas the global rate limit applies to traffic flowing through all instances of envoy proxy. They have an example here how to set up a local rate limit where you have rate limit local similar to what we've taken a look at earlier but in the documentation they also have the global rate limit rule and they have example on how to get that configured now to get that working it's a little bit more steps you need to install reddus reddus is a caching layer which allows envoy to cache some data it needs to enforce global rate limiting so this guide talks about installing a local reddus instance and then doing a Helm upgrade to tell Envoy about this new Reddus instance.

And once you've done that, you can go ahead and implement global rate limiting using the back-end traffic policy similar to what we've done before. So instead of local, you now have rate limit global. And you can do exactly what we've done before by limiting a user to three requests per hour based on headers. So that's an example of how to set up back-end traffic policies. The next important component for envoy gateway is the security policy.

So unlike client and backend policy, security policies define the authentication and authorization requirements for traffic coming into our gateway API. You can also find this in the documentation under the gateway API extensions section. You'll find security policies over there. Now the security policies is an envoy gateway extension allows us to define authentication and authorization requirements for all the traffic coming in.

It's basically a security layer. So we can do things like authenticate apps using mutual TLS WJT tokens, API keys and basic orth. We can also connect externally to things like OOTH servers if you're using OOTH proxies to authenticate using something like a Google or a Microsoft login. Also very importantly, we can assist with things like cores to allow or restrict cross origin requests for APIs. This is very common in HTTP and web applications.

Again, it's important to understand how security policies target resources and their precedents. So, you can either use direct reference or label selectors. Just like the other two we've taken a look at, we can attach to things like gateway or different routes like HTTP, gRPC, and TCP routes. There are some limitations and it's important to read through the precedents to understand the different priorities at which these policies will take effect depending on how you attach them.

So, route rule level, route level, listener level, and gateway level. So, here's an example of a course policy. I have a basic web app running in my cluster. I can access it using port forward. If I go to my terminal and port forward, I can access my application over localhost 8000. If I try to make a request, we can see that we got a cause error. Now, to solve corores, it's basically just applying a security policy that's attached to our route.

And that's what a security policy looks like. It has a name. I'm going to call it go route course. I'm going to target an HTTP route here. I could target my entire gateway and fix it for everyone, but I want to show you the specific targeting reference options here. So you can target a route or a gateway. Then you have a settings called coursees to tell envoy which policy to enable and the settings for that policy. So I've allow origins, allow methods, allow headers and expose headers.

These are all basic chorus functionality. If I hop into my terminal and I apply that and then I port forward again, try to make another request, this time it'll go through successfully. Another useful security policy is basic authentication. So what I'm just going to do is I'm going to clean up the policies we created earlier as they will conflict. Then I will proceed to port forward this time to 443. This is because when we use basic authentication or any type of API authentication where we pass details like login info via HTTP headers, we want to use 443 TLS as a best practice.

You don't want to be passing these things through in plain text. So I go ahead and run my port forward. Then what I go ahead and do is install HD password in Alpine. So I just say apk add apache tools and then I say ht password and I want to create a new password file. My user is Bob. My password is password 123. That will spit out an HD password file that I can create a secret within my cluster. So I go ahead and add the utils create that HD password file then create a Kubernetes secret by using that file.

Then take a look at our security policy that will enable that basic or So here I create a new security policy call it go route basic orth. I'm targeting my go route. Again you can target the whole gateway if you wanted to. And here I'm using the basic orth policy. Pass in my username and this points to the secret we've just created. This will tell invoy to use the secret we just created for any requests coming through and enforce basic authentication.

So I go ahead to my terminal and apply that. And if I try to access my go application now, I am presented with basic authentication login. So I have to login and then I can access my service. Another useful example is API authentication. So what I'm going to do is just clean up that previous basic or policy. Then we can go ahead and apply a new policy that enforces API authentication. And this one is very simple. Firstly, we create the secret that the APIs will use.

So I'm creating a new secret called go service secret. This is the client and password that that API will use or any client to authenticate with our go service. Then we create a security policy called go route API key orth. I target my go route here and it's as simple as just specifying API key or credential information. So we do a credential reference to a secret that we've created up here. That secret is defined at the top.

Give it a name and what we want to extract from there is the headers and we basically want to extract from all HTTP headers coming in X API key and use that to authenticate the value. So I go ahead and apply that. Now if I go back to the browser and refresh, you'll see we get an error. Client authentication failed. This is because clients have to pass the API token or API key in the header. We can do this using curl.

If I jump to the terminal and paste that, you can see that has worked. I got a HTTP 200 response. And that's how you do API key authentication using a security policy. Those are the main CRD and feature set for the envoy gateway API. It's important to know that the gateway API also has observability enabled. It supports the three pillars such as logs, metrics, and traces. Similarly to traffic that we've taken a look at in the previous video.

So for observability we can go to the documentation under tasks there is a section for observability. And underneath that you'll find three important section logs metrics and tracing. And this section is where we can learn all about logs. How to enable access logs customize them. So if you want your logs in formats like JSON because you want to parse it or you want to change the fields you can do that here. So here is what the default access logs will look like if you're not using a custom format string.

This is useful to see what's going on with the traffic in your cluster. You can customize or disable access logs on the gateway class using that envoy proxy object we've taken a look at earlier. So here we have our gateway class that we've taken a look at earlier. And remember we attached an envoy proxy configuration to that. This is where you can configure your envoy proxy fleet. So this is also where I've changed the replicas for the Kubernetes deployment.

But I want to do some more things. And here I can do things like telemetry enable access logs. So there's an access log section here where we can do things like provide the format of the log. So I can turn on JSON format. And here I can actually create and enable custom fields. And I can use the envoy command operators to get things like the HTTP method, response codes and more. So that is how you enable logs. Envoy proxy also supports metrics.

This metrics can either be used by open telemetry or Prometheus. And the envoy proxy documentations also has a whole different helm chart for add-ons related to monitoring. So you can get Prometheus instances and open telemetry collectors up and running as well or you can simply point them to your own. So under observability you can go ahead and click on proxy metrics and as I mentioned earlier there are some add-ons which you can use if you wanted to which employs observability components in a monitoring name space.

This allows you to deploy things like open telemetry collectors. It also supports Prometheus metrics and this is how you turn it on or disable it or configure it within the same envoy proxy configuration we've taken a look at earlier under telemetry you can add metrics so you can customize the metrics over here the same thing goes for tracing under the tracing section they talk about proxy tracing and they have an example of how to use the tracing provider.

So on the gateway class they again use an envoy proxy configuration object here and you can see under telemetry under the tracing section you can customize some of the tracing features and here you can have a backend reference to an open telemetry collector and port and you can also do things like set up custom tags for traces as well. The documentation also has a section on visualizing the metrics using graphana. So if you have a graphana instance running and you're getting these metrics out of the envoy proxy, this section might interest you as there's a lot of dashboards around global envoy proxy metrics, your envoy cluster metrics, global gateway metrics which is quite rich as well as resource monitors.

So that is how to get started with the envoy gateway API solution. So what is my verdict on this one? After taking a look at traffic, it really really depends on where you are in your journey. Are you looking to migrate off of like EngineX ingress controller into another ingress controller? Are you looking to migrate from ingress into something like API gateway? Are you looking to adopt a service mesh? How much simplicity do you need?

As I mentioned in my earlier video, you might want to take a look at my traffic guide as well. that one is focused a lot more on simplicity. Envoy proxy has a lot more deep functionality and configuration capability. I think envoy proxy is great for gateway API compared to traffic that we've taken a look at in a previous video. They're both featurerich. I do think envoy does however provide a little bit more configuration options.

In our next video we'll take a look at something like gateway. Now, ISTTO is built on top of Envoy, so they use Envoy proxy under the hood. If you're using any of these gateway API controllers, I'd like to hear from you down in the comments below. What is your experience? If you like the video, be sure to like, subscribe, hit the bell, and remember to follow on Instagram to follow the progress of the ultimate DevOps road map.

If you want to support the channel even further, hit the join button down below to become a YouTube member. And as always, thanks for watching and until next time. Peace.