Kubernetes Gateway API with Spring Boot Microservices

Hey everyone, welcome back. So, in the last video we added Kubernetes Ingress as the public-facing component to the demo and we learned how Ingress solves the problem of a consistent interface while still implementing the routing for different services. And towards the end we discussed that the Ingress is getting retired and we should now use the Gateway API. So, in this video we will learn how to implement Gateway API and we will see implementing Gateway API doesn't need any change to our Java services. So, the Spring Boot services that we already developed, they don't need any change in order to move from Ingress to Gateway API. The only change is that it requires is some Kubernetes objects. So, we still need to implement a controller that we will see in a second. Then we need to write some YAML files to define the routes, that's all. So, let's understand what this Gateway API is, what are different components that we have to implement. So, as you can see here, Gateway API is similar to Ingress. In Ingress we used to have two components, the Ingress resource that used to have the controller. So, there you define which controller do you want and you also define the routing rules in a YAML file. So, that defines your Ingress resource. Then we also used to install the controller. So, in the demo we installed Nginx as the controller. So, there were two components, Ingress resource and Ingress controller. In case of Gateway API we have three components. The first one is Gateway class, then the Gateway itself and then the routes. So, the Gateway class is basically what is the controller that you want to use. It could be Nginx, it could be HAProxy. So, it depends on the vendor, there are different vendors available which implement the Gateway class. So, your Gateway class is essentially the controller that you want to implement, that you want to install. Then you also define the Gateway. Gateway is the entry point to your application. So, it defines the entry point that the clients would hit in order to access your services. And then in the end we have the routes and the routes are simply the routing rules that you define. So, in the last demo if you remember, we wrote the HTTP rules that depending on the endpoint, which service to redirect to. Now, the thing is with Gateway API, we have native support for different types of routes. For example, we have support for HTTP route, we have support for GRPC route, and in the same way there is TCP route as well. With Ingress, things were mainly focused around HTTP. The other thing that you would notice is in case of Ingress, these two resources were coupled. So, in the same YAML file, we were defining the class as well as the routes. But here, standards are accurately defined, the boundaries are set. So, you have gateway in a separate YAML file and the routes in a different YAML file. And it makes sense because from a developer's perspective, if you think about it, you will generally write the routes because that defines how the traffic should be diverted between your services. But gateway is kind of a one-time activity which can be owned by the ops team. So, hence, the segregation is much clearer in Gateway API. So, that also defines why Ingress is getting retired and why the Gateway API is the new solution. So, in a nutshell, there are three components: the Gateway class, which is your controller, the Gateway, which is your entry point, and then you have the routes which define the routing rules. So, now that we understand the basic components of Gateway API, let's start with the demo and change the application so that it uses Gateway API rather than Ingress. So, here we have the same code base. We still have the inventory service, we still have the order service, and we have the shared folder, and I have moved the Ingress to a folder Ingress not used, and I have added a new folder Gateway, which would have the Gateway files. And following the same pattern, I have created a new feature branch just for this video, which has the Gateway API changes. So, as I said, there is no need to change your existing services. Your Java code remains the same. Once you create the image, which is the Docker image, you don't need to change anything in order to move from Ingress to Gateway API. Your images will be used in the deployments, your deployments will be used with Kubernetes services, and this is all already defined, and we already deployed it in the last video. The only thing is since we deployed Ingress also, for this video, we need to remove the Ingress, and we need to install the Gateway API component. So, that is something we will do. So, to make it easier, we have a file steps.md in the same project directory, and it has all the steps that we need to perform to deploy the Gateway controller, and to finally move from Ingress to Gateway API. So, the first two are related to removing Ingress Nginx Ingress controller if you have that controller on your local, otherwise, skip these two. So, in my case, since in the last video, we had deployed the Ingress controller, so I need to perform these two steps, which I already did. So, that means I have deleted the Ingress app Ingress that I created in the last video, and I also deleted the Nginx Ingress controller. So, now I can move on to the third step, which starts the Gateway API setup. So, the first command is to basically install the Gateway API CRDs. So, this step is about installing the Gateway API constructs using CRDs, so that your Kubernetes is aware of Gateway API things. So, this is the first command that we will run to install the CRDs. And then, we will verify if this was success. So, we can see we have everything that we need to install the Gateway API. Then, the next step is to actually install a Gateway controller. So, if you remember, the Gateway class represents the controller, and you still need a controller. In case of Ingress, we chose Nginx, and in case of Gateway controller, we are again picking Nginx. So, Nginx provides both the solutions, the Ingress controller, as well as the Gateway Fabric. So, we will run this command to install Nginx Gateway controller using Helm. So, you must have Helm installed on your local. It is a very simple step that you can find on internet. Then if you notice we are exposing this controller as a Kubernetes service and this is of type load balancer. As an experiment you can install it and expose it as a node port service, but then the challenge is you have to specify the port and that is something that we want to avoid. So even though load balancers generally work with cloud offerings and on local we don't have any cloud setup, but still we can expose it as a load balancer and with load balancer you get just the local host colon 8080 kind of IP address and you don't have to specify the node port. So that is why we will run this command which will install the Nginx gateway controller, then it will expose it as a load balancer service. So this will install Nginx gateway controller on my local Kubernetes. So this has been done. Let's verify if we have the pods in the same name space in the name space in which we created the gateway controller. So you can see that it has its own name space Nginx gateway hyphen n command shows the name of your name space. So let me copy this command to verify the setup and we will run it. So I can see there are two pods in this name space and then we can verify by running this command to get the gateway class. And gateway class is your controller. So you can see we have one entry that means the Nginx gateway class has been installed and this is the gateway controller. All right. So once we have the gateway controller, we need to then create the gateway. Gateway is your entry point as we discussed in the beginning. So how we create the gateway is we write a YAML file and those YAML files you would find in this folder shared gateway. So first of all let's check out the gateway.yaml. Now in this gateway.yaml we are creating the gateway so we are telling the API version and this is coming via the same CRD that we installed when we ran the first command. Then if you notice the kind is gateway that tells Kubernetes that it is a gateway object. And then you give it a name app gateway and then you specify the class name and class name represents your controller. So in case of Engine X gateway controller, the name would be Engine X. And then you define that this gateway controller your gateway would listen on 80 port with protocol HTTP. So if you notice in this gateway.yaml, we are not writing any HTTP routing rule and that is a separation of concern. So your gateway simply represents your entry point, your gateway, the port, the controller class and that's it. You don't specify rules in your gateway.yaml as compared to ingress resource where we had to specify the entry point as well as the routing rules. So this is the YAML that you will apply to create the gateway. So let's go back to the steps and the command is simple, the same kubectl apply command. So let's run it. And this will actually create the application gateway or your Engine X gateway. Then we will verify it. Let's run this command. And I can see the app gateway is there on localhost and you can find more information about this gateway by running the describe command. Now describe command does not have anything to do with your application gateway or Engine X controller. It is a usual kubectl command that you can use to describe any resource that you create. So if you run this command, you will find a lot more details about this gateway like So you can see it here that this particular gateway supports HTTP routes and GRPC routes by default. And then you would find other details as well here. So it's the usual describe command. Now that we have the gateway, the next step is to actually create the routes so that you can redirect the traffic. And it follows the same pattern. You again create a YAML. So this YAML you would find in the same folder. And now in this YAML you define the routing rules. So, first of all, let's talk about the rules. So, this is similar to Ingress. You define the HTTP routing rule, and you are saying that any request that matches {slash} API {slash} orders, redirect it to order service, which is running on 8080 port. And similarly, any request matching API inventory path, redirect it to inventory service, which is also running on 8080 port. Now, the question is how do we link these routing rules to your gateway? And that is where this particular tag comes into play. So, this particular field spec.parentRefs.name links your routing rule to your gateway. Here, we give the name app-gateway, and this is the same name that we gave to the gateway when we created it. So, this must be same, and that is how the linking will be done. So, Kubernetes will know the gateway API, will know that these routing rules are related to this gateway that you created like this. Right? So, this will be your Nginx controller gateway controller, which is running on 80 port using HTTP protocol, and this will handle these routes. So, that is how the linking is done between the routes and gateway. All right. Going back to the steps, now that we understand the role of routes.yaml, we will create the routes, and that is again a simple thing, kubectl apply command. So, let's run these commands to actually deploy the routes. And there is a mismatch in the file name. It says HTTP routes. So, S is missing. Let me correct it. And the routes have been deployed. Let's verify them. And you can see the routes app-routes, and app-routes is the same name that we gave to the HTTP route resource, and it has your routing rules. All right. So, in the same way, you can also describe the HTTP route that you just created to have more information. So, now that we have deployed everything, we have deployed the Nginx gateway controller, we have deployed the Gateway and the routes. The last step is to test the application. Now, testing steps remain the same. We still run the curl command. We access localhost:80 address. Then, we call the order service which starts with /api/orders and it has multiple endpoints, but the one we are going to use the SKU one because it internally calls inventory service. So, we also want to test service-to-service calls. So, if we open the order controller, this one, then this is the endpoint that we are going to call. So, if you notice /api/orders and then the SKU with a random SKU. So, when we call this endpoint internally, it will call the inventory client. So, let's go to the terminal, clear it out, and now we will call the order service. The endpoint would be /api/orders and then a random SKU. And I made a mistake, the port must be 80 not 8080 because, if you remember, in the gateway.yml, you are listening on port 80. So, let me correct it. And now we can see the response by the order service that order was handled by this particular pod. Then, it called the inventory service and got a response from the inventory service as well. So, we can see the whole chain is working fine from the order service to inventory service. In the same way, we can actually call the inventory service also directly to test that it is also working fine. So, it has the endpoint /api/inventory then SKU. So, you can see we are also calling inventory service directly. Now, if you notice, the important thing is we still have the consistent interface for the client localhost:80, which represents your base address, and the routing is done on the basis of your endpoints. But this time, this routing is done by Gateway API. So, that's it for this video. That's what I wanted to cover on Gateway API. So, we We at why Gateway API was introduced, what are different components of Gateway API, then how to migrate an existing Ingress based application to Gateway API without changing the services. So, that is the good part. You don't have to change your existing services. So, while Ingress is still widely used, Gateway API is where this Kubernetes networking is heading as we talked about because it provides a flexible as well as an extensible model for managing traffic and managing different components. So, that's all for this video. In the next video, we will evolve this service to have more production like features and we will explore some other features of Kubernetes. So, I will see you in the next video. Thanks for watching.