Kubernetes Ingress: NGINX Explained

[Music] so what is an ingress controller to understand we have to look at the fundamentals of web traffic and system every system whether it's a single application or a bunch of micro services has an entry point for receiving traffic this entry point can accept traffic in the form of a URL a protocol hostname or DNS and a path sometimes even a port number this end point is usually identified by either a DNS or an IP address so traffic comes in now some calls thus approxi and a load balancer or an API gateway but it doesn't matter this is an ingress controller an ingress controller is responsible for a few potential thing like accepting or denying HTTP traffic SSL termination meaning we can accept traffic on port 443 via TLS but then we may not need TLS and route to different port to reach private applications routing so basically deciding where traffic should go URL writing so deciding where traffic should go based on the URL path and load balancing so we can decide whether we want 60% of traffic to go to service a or instance a and 40% of traffic to go to service B or instance B now ingress controllers under the hood can be powered by many products such as engine X H a proxy invoice traffic conch and so forth every one of these products have a different configuration their own syntax and generally require their own expertise to manage ingress controllers allow us to speak the same language so what if we took the syntax of each one of these products and made that all the same in this case kubernetes Peaks y ml so ingress controllers accept their gamal in the form of an ingress one ingress controller can accept many ingresses in an ingress we simply describe the host dns we expect traffic on we say whether we want SSL the path we want to route based on and where we would like that traffic to go the rest really doesn't matter kubernetes will translate this into the syntax for the product we are using so in this video we're gonna be taking a look at an engine x cuban Eddie's ingress controller what it looks like and how to deploy it so check out the source code below and follow along so the first thing we're gonna need is a kubernetes cluster and an example application that requires an ingress so I have this kubernetes cluster on docker for windows and we can also see it has no namespaces so it's an empty kubernetes cluster so what I'm going to do is create an example app namespace that's going to house our example application so what I'm going to do now is in that example app namespace I'm going to apply a deployment file so it's the ployment gamal it lives in the structure of kubernetes we've got deployments config Maps secret services and ingress which we're going to cover in this video so I'm going to go ahead and deploy that example application it also requires a config map and a secret so I need to apply a config map and then I also want to apply the secret gamal now for my example app I'm also going to apply a kubernetes service this is a private service that's not publicly exposed so that will basically tell kubernetes to route traffic to our pods and because this service is not type load but and so this is where the ingress comes in so the ingress controller will help to expose that the service publicly ok so now we can say cube CTL get pods and we can see our example application is up and running given this application is private it does not have public access so we can't access it by an IP address or a load balancer and that is why we need an ingress so for the time being what I've done is port forward to the application over port 5000 and we can see here in the browser that my application is now up and running okay so to deploy an ingress controller this is very self-explanatory we're gonna need a bunch of yeah more files so it's under kubernetes ingress controller I also have a video on traffic so if you want to check that out check the link down below but we're gonna cover the nginx deployment now the first thing we're going to need is to apply a namespace name space allows us to isolate all the things we're about to deploy into a single group so what I'm gonna do is say cube CT I'll apply dot slash kubernetes ingress controllers nginx and I'm gonna apply the namespace file first if we take a look at the namespace like yeah more it's very self-explanatory it's just a little namespace called ingress - nginx and then what we're gonna do is deploy a service account now service account allows the process to run with a set of permissions giving ingress the ability the ingress controller the ability to do what it needs to do so if we take a look at the service account Akiyama it's also very self-explanatory so I'm gonna go ahead and apply that service accounts document and that's gonna go ahead and create the service account in that namespace now what we're gonna do is we're gonna apply the set of permissions that that service account needs so if we take a look at the cluster role the cluster role is the permissions that ingress will need so basically what it needs to do is list and watch config Maps endpoints nodes pods and secrets it needs to be able to get nodes it needs to be able to get lists watch services create and patch events and most importantly get less than watch ingress resources as well as update ingress statuses so to apply that we're gonna say cube city I'll apply and we're gonna apply the cluster role file so that's going to apply the set of permissions now what we need to do next is we need to actually bind those roles to the service account so I'm going to keep city I'll apply a roll binding now what this will do if we take a look at the file as this will simply bind our service account to the set of roles that we've just defined so this will give us service accountability to do all those permissions that I just described giving our ingress controller the power to do what it needs to do the next but we're going to take a look at is the config map so config map Gamal has a bunch of configuration now nginx has a ton of flexibility and in terms of configuration so go ahead and check out the engine X controller documentation and the engine X configuration there's a config map section with a massive amount of configuration options that you can apply now for example I've just applied a few of them so you can see what they look like there's client body buffer size there's things like turning up the verbosity of logs and then also the log format so you can customize the format of the log you want to write also it allows you to do certain things like location snippets and service snippet so you can inject custom engine x configuration files or nginx Lua scripts for each ingress rule that applies so if you take a look I've done an example here which is a location snippet which isn't pointing to another con file that's part of this custom snippets config map and here you can basically write any kind of Lua script that you want for each ingress rule that's deployed so just an example here that you'll find on the internet it's for cross-origin resource sharing so if you are debugging microservices running on different ports over localhost you can enable localhost gore's rule here I've left this one in again as an example so you can kind of fiddle around with it so what we gonna do to apply that is we're gonna say cube CT I'll apply we're gonna apply the config map the other bit here that's self-explanatory is there's a specific config mode for TCP services as well as UDP services and which I've left blank but it allows you again flexibility to expand that out as needed the last bit I'm going to apply is the custom snippets config map that's the one with custom location and service snippets that if you want to if you want to set those and that is our config map so that is gonna give us the ability to control what the ingress controller can do so now that we have all the bits and pieces in place we can go ahead and apply the deployment file so the deployment file if we take a look at that is very simple we're gonna apply two replicas of the nginx ingress controller which is this image version very important that you always point fix it to a specific version and then we also tell it where the config map is with TCP and UDP service config Maps and then the rest is all pretty self-explanatory we volume mount our custom snippets in so you can change this around if you want to mount different snippets into your ingress controller we set a liveliness probe and a readiness probe and then we have a volume for our custom snippet so I'm gonna go ahead and apply that deployment file and that'll also apply it in the same namespace so I have namespaces on each one of these llamo files so that you don't accidentally apply it into a different namespace okay and if we do a cube CT I'll get pods inside that namespace we can see our ingress controllers up and running so the final bit that we're gonna do is deploy a service of type of load balancer and what pew Benitez will do in this case if we take a look at that service y amyl and we can see that we basically just apply apply service called type load balancer and we expose port 80 for the health check and for 443 for our SSL based services what kubernetes will do is it will go in because I'm running docker for Windows here it's gonna run the service over localhost so what we gonna do is say cube CT I'll apply we're gonna apply that service and the last bit that I'm gonna need here is I've created a self-signed SSL certificate for this demo and the reason we want to deploy a self-signed certificate is because I want to show you how to get TLS and is this all working because I'm sure if you're gonna use this in production you're gonna want a real certificate so you're gonna need to come in and create a TLS secret so I've got TLS cert TLS key and this is a kubernetes secret of type T Alice so I'm gonna go ahead and apply that file but make sure you apply this TLS secret in the namespace where your application lives because remember in a micro service world you might have different services running over different hosts and they require maybe different ssl certificates so i'm gonna this specific certificate is for my application so I have a namespace example app and I'm gonna call this the taste TLS certificate here so I'm gonna go ahead and apply that so this I'm not applying this in the ingress controller namespace this the cialis certificate is specific to that micro-service so the ingress controller gives us the flexibility to have multiple TLS certificates and the developer doesn't have to know about the certificate all they do is describe the secret name in a yellow file so now that we have our English controller deployed we can go ahead and deploy ingress rules now remember you can have multiple ingress rules per ingress controller so this is kind of up to the developer to decide how they want to ingest the traffic so what I've done for our example app I've created an example ingress rule so let's take a look at that so we have kind ingress and we basically tell kubernetes that this is an engine X ingress controller so you can run multiple types of English classes with different you know API gateways and we want our application to refer to receive the traffic on its route path because we don't have any routes defined in the application we also deploy this to our example app namespace we specifically say we want TLS enabled here so we're expecting traffic on 443 and we want to run over this host dns name now I have a host file set for that DNS I don't own a DNS with that name so what we then do is we say secret name and we we set we indicate to kubernetes what secret we want to use for SSL this helps us abstract away the secret from the developer so the developer doesn't have to have access to the SSL certificate so it helps to keep it secure we then define a rule to say traffic is gonna come in over this DNS and it's gonna come over a blank path so just gonna come over that DNA straight up and then we tell it to go to our example service so I'm gonna go ahead and apply that example ingress file under kubernetes ingress ingress - nginx not example then go ahead and apply that and we should now be able to access our app over the browser URL so if we go to the browser and we go to that DNS we can see our via I was able to hit my applicator so very very simple way of routing I'm using an ingress controller so what I'm also able to do is I can define specific routes so I can have like v1 /hello and then what I can do is I can define multiple paths so I can do something like and define v1 and then I can also say I want v2 of my application to go to another service so I could say smae be serviced - v2 or something like that so if I go ahead now and apply that file we can now see that we can access our application over different URLs if we refresh this we see it's no longer found but then we can go to v1 /hello and we can access our application over that URL we can also change it to v2 and also access it over multiple URLs so this is kind of the URL routing feature that the ingress controller gives us so that is it for the ingress controller video hope you guys enjoyed it hope it was useful let me know down in the comments what sort of stuff you'd like me to cover in the future and remember to like and subscribe and until next time peace [Music]

Channel: That DevOps Guy

Views: 20,504

Rating: 4.9392266 out of 5

Keywords: kubernetes, k8s, python, coding, programming, learning, tutorial, docker, linux, py, pip, degree, computer, science, learn, study, vlog, technology, nodejs, vscode, visualstudio, ingress, ingresscontrollers, traefik, nginx, haproxy, proxy, loadbalance, api, gateway, networking, devops, azure, aws, cloud

Id: u948CURLDJA

Length: 14min 30sec (870 seconds)

Published: Mon Apr 27 2020