SBTB 2023: Viktor Gamov, Gateway to the Future: A Brief History of Kubernetes Ingress
Recording: SBTB 2023: Viktor Gamov, Gateway to the Future: A Brief History of Kubernetes Ingress
um I was I was here on a few talks and uh somehow I surprised that no one use this as opportunity to joke about that welcome to my Netflix special there would be people from Netflix recording the show so make some noise in the room um so I'm using this as opportunity to do this um uh just a check uh this is the talk about about kubernetes and uh from um ground up like all the things that you need to know to send the data into your applications when they deployed into um into ques essentially what I will break down today for you is the way what is happening every time when you either try to hit API or open this with your um um tool that you use for testing your apis or using your browser like how this routes uh how this all the traffic will go and reach particular Port that have application uh deployed all the load balancers and all the things that happens with your traffic um also along the way we'll try to do some interesting things for example we will see how we can uh do something with this traffic without going in changeing application for example how we can um serve some of the D2 responsibilities like uh providing uh DET termination SSL termination or rate limiting for your applications my name is Victor gamou I work as a principal developer vated con and At Con we build different tools to help people to um do everything what they need to do with Cloud native connectivity uh con Gateway is the probably one of the biggest and most popular open source gateways s uh 45,000 um stars on a on a GitHub so it is kind of big deal and today I'm going to talk about another open source project that we develop at Kong uh it's called kongress controller that will help to translate um kubernetes Native configurations into the the form that the K Gateway will um um digest uh but before we jumping into all these examples let me talk a little bit about history and why you need to know this and why you need to care about this first of all so let's going to start uh with the brief explanation how the networking kuties Works uh we go into this uh Ingress object that is the standard way to expose your service TOS side World we're going to look how how it is good thing and what kind of bad things are coming into uh what what are shortcomings of this um Ingress object we will talk about what is uh happening in the community and how the community try to um address some of the shortcomings of the Ingress object so we're going to see what is happening after Ingress so essentially past present and the future of this of this technology uh let's start with the kuber is native apps so you deploy your app usually it is containerized most likely it's containerized some of the tools make these things uh easier so if you're not preparing your containers there are some tools that can do this for you uh and uh in kuus you deploy everything in pods and uh if you deploy your application say you have application that has orders uh you can have a multiple pods um those pods can include one or many containers and each of those uh can or cannot expose some of the ports so those things can be exposed outside world specifically if I would like to my application to be exposed TOS side world I need to put something in front of it um so the load or request will be balanced across multiple different parts because kubernetes allow me to um scale my application easily I can specified number of replicas in this particular case I have only three replicas but I can scale this up scale this down and um this should not affect the way how your users accept your the interact of your application um and in the world of kubernetes it's done through the multiple ways so let me show you one quick thing that you can do right right right now I will be using some of the uh some of the apis that I developed and those apis are pretty cool one is the API that we're going to explore right now it's the Back to Future API and one of the services that uh this this particular API expose um it is called type of cluster IP what does it mean it's routed inside kuber cluster So within kuber cluster any application can access to this one but what I need to do in order to access this application to site World easiest possible way if you try to Google or ask your chat GPT they will say hey use port forwarding so we're going to use port forwarding for this and for this service we're going to do port forwarding so what will happen here it creates a tunnel between this kuis cluster and your local machine so your on your local machine if you go and hit this Local Host you will get the response from Back to Future service this is not very scalable you cannot just like give everyone access to your community cluster for your users you want to do something that allows you to kind of give external access to your system um to your users um so in this case the type of the service can be changed to um load balancers so in this particular case if I will go and say type uh load uh balancer with a little bit of luck and little bit of cloud magic um and this particular cluster is running in Google cloud and Google Cloud provides external um globally routed IP address that would be associated with particular um Lo balancer so I changed the type of my service so now I don't need to have my port forwarding so let me um let me delete this port forwarding from now and get back to our service in a few seconds I will see external IP address that everyone in this room can uh try to hit with your favorite tool and you should be able to get um access to this API so if I will get this one and get back to uh to my tool and I hit this uh of course I did I didn't specify the port I need to specify port and I get the answer uh response so that's the easiest way how you can do um external access to your application just annotate your service inside the kubernetes it is also will be load balanced but you don't know what kind of underlying technology you need to rely on technology of your kubernetes uh cluster vendor so that's how load balancer thingy works when you start growing your applications you're running multiple applications kubernetes because why wouldn't you because kuus gives you ability to Bing pack your application they will use your resources more efficiently and things like that you start getting more more more apps say you need to have application that will be providing some of the building capabilities and to expose this to outside world you also need to have external IP address so you need to also provide load balancer um and if you go into another service this service also needs to have external address so this creates some some of the problems because each service um will have its own IP external IP address and some of the cloud providers this can be limitation because you might exceed depends on the number of services you're running you might exceed the pool of available external IP addresses so smart people in kuber world they come up with this idea okay so instead of having the multiple services will be exposed through this its own load balancer how about we will have something in between that will be responsible for routing things so this is how they come up of this idea of Ingress so Ingress it's another kubernetes object that will be sitting there it also will allocate external IP address but it will have a little bit more knowledge about how to route requests say if you want to go to your billing ad uh billing service it will have route SL billing but um or you can also route B based on U host name or whatnot so we're going to be focusing on the on Ingress and how how it works and why it is important so first of all it gives a very nice clear entrance uh over the how the traffic will go inside your um inside your kubernetes cluster so you can do some other inter things on top of it so kubernetes Ingress it is a vendor neutral again uh vendor neutral specification that runs inside kuber cluster um and it is really depends on uh one one particular thing it's what we called a Ingress class Ingress class name this is something that will distinguish this Ingress from others if you're running kubernetes you're using stock kubernetes you're probably running something called engine X in controller that is considered as a default thing but it's not necessarily it needs to be default um like uh maybe three three and a half years ago um we uh were inspired we at K were inspired by the work of community in engine x uh in Grass controllers so we start building con Andress controller on top of some of the ideas that were there in order to put the con Gateway um as a as a kuber native Ingress implementation so what is ingress uh it has multiple interesting things so first of all it has different paths that you can configure so in this case um one of the path that I want to expose that will be routed uh by by host name so every time when I hit this Ingress with host header I want to be routed to my back to future quote service how does it work let's take a look and um you already seen that um I do have some external IP address available uh but also before that I provisioned uh my Ingress and if I go to the service my uh Gateway service already allocated this external IP address and I also did some of the preparation where I because I don't want to type the IP address all the time um I just create a DNS record uh k. proxy Do Me O so that's the that's the um if I will hit this um end point so say I will just do GTP called proxy me I will get 404 I'll get the 404 because the way how the HTTP calls will work every time when I will be hitting this using DNS name it will transform this request into the part where it will get IP address of the service and also attach host header since my Gateway doesn't know anything about this Con proxy me header um we cannot do anything with this but if I will go say to the same um to the same system I will include uh actually let me do this one so if I will just do host Back to Future con proxy me and I get the response from from these um uh Back to Future service and also for the sake of demonstration I also included some of the additional information so you would know where this traffic coming from so in this particular case it's particular pod that will be serving this traffic that's actually responding with this request if I'll hit this few times you clearly see that some quotes actually coming um from uh Back to Future quote service so what you just see this is this is particular case of um routing by header so every time like when you go in your browser you put this in your browser and your DNS will resolve this IP address and you will get at so basically to to show how it works I can even simplify this I will just do this one and I also get access to my uh Back to Future service and if I will just do uh let's do Back to Future um it's same IP address so I'm allocating one IP address and I already do multiple things so I have a one service that is available through con proxy me another service available through Back to Future and uh just to do like a spoiler that is there's another service that is also attached to same IP address by from the different host and if I will hit this I will get access to the different service so Gateway in this particular case or Ingress is responsible for routing based on certain rules those rules can be uh related B based on um um I'm I'm showing the examples to do route based on headers but also it supports routing by path so things that I showed you here with this um with this picture um routing also can happen based on the path which is also normal and very common all right so let's go deeper and see what what is going on and what we actually can can do with this um the way how it works we take this specification that we Define the our Ingress we defined our uh ing class and after that we submit this to kubernetes API server kubernetes API server will translate this um into some some objects and some of these um uh what we call controllers that will be listening events that will be happening with these ingresses um will be responsible for taking care of this configuration I take this Ingress and it will convert this into engine X configuration it will convert to cor configuration it will convert it into traffic configuration whatever um uh Ingress controller you have really every vendor that has some sort of like things to deal with apis or L7 traffic management um they will have some similar capabilities so since uh since we're putting here not only just a simple web server but we're putting actual API Gateway we actually can do many interesting things with the traffic so U say I want to do something with my apis and I want to Pro provide teering for my apis I want to have ability that some of the users of my API will have uh different uh user experience say based on particular key uh they might have a different SLA so let me show you how this can be can be done with Ingress so the uh I like to joke about how um other systems uh or other the developers like to bash on Java but every one is actually taking a lot of inspiration from the Java things and look at this we have annotations here annotations inside the yaml and we have the annotations in Java and everyone is taking annotation from java so this is the way how you can extend functionality of this vendor uh specific of the vendor specific um um specification uh and put some additional things in this particular case what I do I actually have integration of a few interesting things one of the things that um in order for me to configure my DNS I use this project called external DNS that will based on this Ingress will read this information about the host name and it will talk to my DNS provider and create this uh a record between my host name and my IP address that would provide it to uh to to Ingress so this is kind of this what I was saying a little bit of magic and the luck because gns is always a tricky thing especially when you do live demo um at the KR controller we also rely on this um at in this case we can enable some of the plugins so if I'll go and uh hit my Back to Future and say let's hit this uh on interval let's hit this every second and again htps maybe the certificate is not provide Pro provisioned so let's do this repeat on interval every second and let's see if we will have some interesting cool demo yeah so after few requests we immediately get this um error that uh too many requests uh that happened and the way how it works that um I have a kubernetes object called cor plugin was created inside my kubernetes so if I'll go into my uh in my plugins and I'll show you free tier this is how this plugin looks like again yaml uh very kubernetes very very um very kubernetes style of configuring things and what this plugin says um for um for a minute with the on the free tier users of my API they will able to do only five requests so this easy way to restrict access very very very easy thing so let's go and explore this a little bit further so I want to have like a very cool API about Chuck Norris facts and this this Epi will be uh where's my Chuck Norris so for this I would like to have combination of the plugins so I want to different users who have a different experience here say if some user will come with one particular key they have one level of SLA if users will come with different type of key they will have a different layer U different different uh level of um of service so in this case I do have a pay tier that allows me to uh give people uh 10 requests per minute and um in this case I'll have a platinum tier in the Platinum tier I have 100 requests per minutes and the way how I distinguish them is by the thing that we call consumer that's the thing that will hold the state and will help to distinguish who is calling the service in our particular case we're going to be using API key but J talken or oidc providers all these things are supported as well for Simplicity we're going to do this um uh like this and uh let's since I updated my uh and I'm go with my folder will I have my kubernetes go to Chuck and I'll just do updated Ingress if it's still here yep I just do 03 Ingress so what will happened uh Ingress will be configured and when I will hit my Chuck nor service now uh let me show you there's no uh there's one header that I will disable when I send this I get unauthorized because now Chuck Norris will be available only through um the authorization so if I will put this API key it's called please with the Emoji um in this case I will get U response from Chuck noris as you can see Chuck Norris can compile syntax errors and let's see what else can do Chuck Norris doesn't need a debugger he just started down the bug until stairs down at the bug until the uh code confesses that's very funny um and as you can see here as a response of this request we'll have some additional information from the rate Li meting plugin that says okay so um you allow to do 10 requests per minute and you already eight use eight then we're doing next next next next next and after that we're going to do one more thing to no it's fine um no no I'm I'm running I'm running the um uh I'm running Mac and in this case it should be enough for another 30 minutes or whatnot thank you so much so uh now if I want to change the way say go in the Platinum tier and I have like a very cool sign of platinum users they will use roundhouse kick to uh get access and uh with the rhouse key API key they will be able to do things with with this oh um thousand uh hundreds requests okay all right so um now uh there's a bunch of things available con like I said is open source tool Congress controller is open source tools we at con we also build commercial offering but everything what I'm showing to you is possible to do with the open source tool so there's no uh there's no tricks and sleeves now uh you've seen some code um I do have an extended version of this present on my YouTube channel there would be Link at the end obviously because you know everyone should have a YouTube channel these days um and I really want to spend a little bit time to talking about future of this um Gateway API so some of the things that I also like to show is a non uh HTTP type of workloads uh I I get examples with the grpc I get examples with TCP UDP because people running those type of workloads on kubernetes um every time you run database and you want to expose this you need to expose it through uh TCP Ingress uh Co Ingress controll can do that some of the uh Ingress controllers can do some of them cannot um this is already kind of like a world of vendor specific and this is kind of like world where um people in the community start thinking okay so Ingress is only designed to be um L7 HTTP and with the number of annotations we can go very deep into this kind of like annotation hell again people inspired by Java world where we also have annotation hell uh and they realize that they there needs to be uh something else there needs to be happening something new uh and around maybe like a two and a half years the group of people during the cube con uh They Come Together start thinking about how they can improve this Ingress um Ingress API so uh enter the Gateway uh API that naming is terrible naming is hard because now you can what's the difference between API Gateway and Gateway API right but it was worse because the Gateway API before it was Gateway API it was called Services API it's even it's even it's even worse because the services it's the super overloaded term but essentially uh what they did they actually introduced few more entities in the in the specification few more entities in API that allows to have more clear separation between who is responsible for what so key component here now is Gateway object so Gateway object essentially the thing that will be uh getting external IP address external port and this is the thing that will route in your traffic Gateway class this is the way how um uh the Gateway uh operators or infrastructure provider will um provide you with the choices what you want to deploy say you go into Google cloud and you um you don't have anything uh to to choose from because Google Cloud provides you with one g ke based Gateway class and you create this Gateway you start pumping your traffic into your application it's good to go now if you deploy some of the vendor specific installation of kubernetes you will get things like um maybe some built-in Ingress controller maybe it would be traffic maybe it would be Co maybe it would be something else um and uh but you as a developer you really don't care what you want you care about is routes how you expose your applications through particular routes so we have a gateways we have a Gateway class now we have a different type of specifically designed API for specific type of work clouds because HTTP routes can be different from JPC routes uh Al so TCP and UDP routes um semantically they will be different and after that you connect those routes to your services um there's a more complex example that's kind of like breaks down to things how developers can use it um now developers will have a full control over what they want to do and how they can expose your applic their application don't worry about actual implementation of the Gateway they only say hey there's going to be like HTTP route SL customers and U the cool thing is that let's talk about this for a second um Gateway implementation by default uh will give you ability to Route by Header by path or by path and header um but people also want to have ability to Route by weight so say uh Implement very simple on very rudimentary kind of like a blue green deployment type of strategy where you can say that 90% of traffic needs to go to the service one and 10% of traffic go to version two so this is now part of specification that's the standard thing and now you can use this um in in your um in your application so the key component here that um is happening over here the is is is here so those key components can be human operator so there would be specially trained person that will deploy this uh operat Ator uh to deploy this Gateway or that can be automating operator that will be deploying those gateways so and uh we will um last week I was at the cucon and now it the specification is a 1.0 standard so we'll see multiple implementation from the different vendors very soon now like I said uh YouTube Channel please uh please subscribe to my YouTube channel new videos every week uh I'll talk about all things kubernetes Cloud native apps um a Management Service mches all this type of jazz um QR code for your convenience and uh the screens short so you know that you on the right place I didn't show it so I'm not going to talk about this so my name is Victor gamou and is always have a nice day and I will be available for enhanced interrogation after this talk for uh you know whatever questions you have I think we might have a one minute for one question from the audience so every time when there's there's a silence in the room it looks like everything is clear or nothing is clear and when when there's a silence it's very difficult to say which one is which please yes uh great talk by the way um thank you how do you uh compare especially with other um Ingress controllers out there particularly ones integrated to a cni like celium on the features and especially when it comes to multicluster how does Kong allow maybe applications to be able to span across multiple clusters using this uh approach and potentially even API Gateway as well if you can talk a little bit about that yeah so question was about uh multicluster uh application deployments and how this particular implementation of Ingress controller can help this um this is very good question and unfortunately I cannot answer this question in very simple form because it requires a littleit background sometimes people saying that oh you your k um thing is running on engine X and engine X is very old technology everyone is running on Vo right now and onvoy is the future and things like that and some of the implementations I just mentioned they either use onvoy or they use something else um and at you know I really hate to do comparison about feature by feature however you brought very good use case a multicloud multicloud application deployment is more on the side of how infrastructure will supp support application deployment and I do have a like I said I have a talk where I talking about service mesh and how you can deploy your applications multi across multiple kubernetes cluster using service mesh and uh since I brought onvoy the service mesh that we're working at K called Kuma has Gateway implementation same thing as you was talking about From perspective of Gateway but this Gateway implementation uses onvoy so technically at the con we have two implementation of gateways one is engine X based and one is onvoy based so I would uh I would suggest you take a look at the the service mesh how it simplifies like a multicluster deployment I have a demo on my YouTube channel about this where I have a Google Cloud Amazon and I'm shutting down the traffic there's a location based uh Gateway that would move application traffic to particular that will be close to you so all these things are supported so like I said it's it's not simple question to answer without giving a little bit more background cool all right so I will wait someone at the um uh at the integration table what table three table three