How to use Traefik as a Reverse Proxy in Kubernetes? // Ingress Controller Tutorial

[Music] in the last weeks i've spent a lot of time explaining fundamental concepts of kubernetes but from today on all these puzzle pieces are slowly coming together and we are getting closer to working on real projects the central part that was still missing is ingress in kubernetes so in this video i will show you how to control traffic to your parts in kubernetes create reverse proxies and manage ssl certificates we will deploy traffic by using helm and then we will use it to expose an nginx web server with trusted ssl certificates on my kubernetes cluster and because you might need a google analytics cluster follow this tutorial long which service could be better than the sponsor of this video sivu xevo is a cloud native service provider and makes it extremely easy to spin up your own kubernetes cluster in just about 90 seconds civo offers you flexible and fair pricing for kubernetes linux machines and storage which you can easily manage through their web interface an api a cli and other automation tools they also have excellent support and a very supportive community so if you want to use and try out ceo then just use their free credits when you sign up that gives you enough time to check it out and you will find a link to that in the description of this video so if you have your kubernetes cluster up and running and you start deploying some services on it you might want to expose them to the public internet and in the past we've used service objects in kubernetes to make our application available with the load balancer but that's just exposing the application on our pods directly and you often have this situation that applications don't offer an hd dps servers for example or you want to run multiple applications on the same port and route them based on subdomains so what we will do instead of creating separate load balancer services for our ports is we will use a reverse proxy in between and that can accept all the traffic on a given entry point like http and https and then forwards this traffic based on the rules and policies to our service objects and pods within the kubernetes cluster in kubernetes you can then manage the reverse proxies and traffic routes with ingress objects an ingress object defines how a service is accessed from outside the cluster so with that we can make more granular decisions about the traffic modify header information or expose even unencrypted services with trusted ssl sir to make this ingress rules work we will also need to deploy an ingress controller so this is our main reverse proxy that accepts the traffic and forwards it based on the ingress roads and kubernetes is as always very flexible about what the ingress controller can be so you can use nginx as your ingress controller you can use traffic and also other ones as well so on the kubernetes documentation you can find a list with all common reverse proxies which can work as an ingress controller depending on your cluster needs and that can make it sometimes a little bit confusing because you will find many different tutorials which will all teach you different things so i personally i just like to use traffic as my standard ingress controller in kubernetes and in docker but just know there are many many other possibilities to configure and use ingress in kubernetes as well so i just show you my approach which has worked for me pretty well in most scenarios that i've tested okay so let's start deploying traffic on my kubernetes cluster and use it as a default ingress controller so just to let you know we're using a bunch of different tools and techniques in this video that you actually should be familiar with such as the traffic reverse proxy the home package manager or reverse proxies entrusted ssl certs in general so just in case you're wondering what the hell is this guy talking about then i've done separate videos one about traffic setting up on docker one about the helm package manager and i've done many videos on reverse proxies so i will link you those videos and tutorials in the description down below so just in case you have any questions but i try to explain as much as i can in this video so just follow it and try to see if that works for you so the first thing we need to do is we need to install traffic with the helm package manager on our kubernetes cluster and the first thing that is very important is that you're always using the correct helm chart with the latest traffic version because i've seen that on some cloud providers when you use their one-click marketplace solutions to just install traffic with one simple click they are not always using the latest version of traffic and because traffic has changed in many configuration settings from version one to version two which are not backwards compatible yeah this is also sometimes not working but you follow this tutorial so make sure when you go to the artifact hub and download your traffic repository you're always using the latest version of the organization traffic labs and use this repository here this is very important of course you also need to inject some of the configuration settings via the values file inside the helm chart so you can obtain those default values in the artifact tab and see all the different configuration settings that you can apply to your helm installation but i also try to make it a little bit simpler for you and follow this tutorial better because i've added another template file on my boilerplates repository on github you will also find that in the description so just go to github to my boilerplates repository and then just go to the kubernetes directory go to traffic and inside this directory you will find a values file that you can use as a template so just copy this and let's create a new project folder and create a traffic dash values.yaml file for example and paste it here what you configure here that now depends on your setup so i will just show you one example with the dns challenge on cloudflare because this is my dns provider that i'm using but in case you're using a different dns provider you can check out configurations for this on the traffic documentation or you can just use a generic http challenge that will just try to make a dns request to the domain you want to obtain the certificate for and try to get um hdb connection working there and in case you're wondering uh what are the different configurations if you want to customize those certificate resolvers on the traffic documentation page you can find how this works so one thing that is very important on traffic configuration traffic has many different ways of configuring it and this sometimes makes it very confusing i've seen tutorial videos they use a yaml file i've seen other tutorials that use tommel file and i think on kubernetes it's the best way to use the cli commands to inject those configuration values and put them in the additional argument section of your helm chart and this is really making it easier so to configure my certificate resolvers i'm always using these cli commands here and you can see there are also some examples how to do that if you're using a different dns provider or you want to use the dns challenge it's also described in the documentation you can also find all the different settings for the dns providers like cloudflare like digitalocean or whatever dns provider you are using so on cloudflare it's actually very easy because in cloudflare we just need to obtain two environment variables here so one for the api email one for the api key or you are using an api token that depends on what you want to use so in this configuration of traffic let's first of all set our certificate resolver here so we don't need this http challenge so let's try to uncomment these lines here and now it's very important that when you configure a certificate resolver on traffic you would need to give it a name like cloudflare for example and then use the challenge a setting so in my case i want to use the dns challenge the provider will be set to cloudflare and then we also need to inject my email address here so i'm going to use cl creative.de and the dns challenge resolver 1.1.1.1 is the dns server of cloudflare and then we also want to store those certificates inside a folder which is called ssl-certs acme cloudflare.json this is a file where i store the certificates and this should point to a persistent volume and now we want to also inject the authentication for the dns challenge because the dns challenge will always need some kind of authentication so that you can prove that you have an ownership of the domain you want to obtain the certificate for so in the environment variable section we now can define our environment variables and you can see the cloudflare example is using cf api email cf api key just according to the official documentation like this one here you can change it with the other values of your dns provider if you want to customize it so let's just go to the configuration and uncomment the cloudflare example here so and what's also important is that you could pass the environment variables in clear text here in your hand chart values but this is not the preferred way how i'm doing it because i want to store it in a secret object in kubernetes so let's first of all create this object and call it cloudflare credentials.yaml and inside this file we want to configure a secret object version one the kind is the secret and the metadata should be cloudflare credentials in the namespace we want to change from cubesystem to traffic so just use the same namespace where you are deploying traffic later and um now we want to inject a string data the first one is the email address this will be my see creative.te and then we want to inject the api key so just in case you're wondering where to find those api token settings on cloudflare you can just go to your personal profile then you can see your email address here and go to api tokens you can create another dns token here but the settings that i'm using are the api keys so i'm just using the global api key view this and use it in my credentials so let's apply this file cloud flag credentials so the next section is some log information i've added this because if you run into some trouble this is not working for some reason you can change the lock level to debug and then just follow the log files once the pod is running and then you can see what is going wrong it will give you some more details about what a traffic is doing in the background but the default log level error should be still fine and now we can configure our entry points here so it is important to understand that traffic uses two parts here so the port 80 for http connections and port four for free for https connections and it always names it with entry points and you could also add custom entry points if you want to expose the port 9000 for example for portena you can add another entry point here which is called portena and set the port to 9000 and so on but for most cases you actually just need those two entry points a web for http and web secure for https and what is also now working in the latest version of traffic you can add a permanent redirect from http connections to https so in the past you would need to add those complicated and entries and configuration settings somewhere in the ingress controller so now you can also add just or enable this argument redirect to web secure and then you will always forward all http connections to the https counterpart so this is very useful um for security so you definitely should go with this setting and then in the web secure entry point you also should enable tls and set a default certificate resolver so this is very important to understand because um there are different ways of configuring the certificate resolver for your ingress objects and this can be configured per ingress object with annotations i will show you that later it's a little bit um yeah sometimes confusing that's why i added this heading here because if you configure a default certificate resolver for the web secure entry point and then traffic will always try to use this certificate resolver whenever and a connection is exposed with https which should be always the case and then it tries to obtain a trusted ssl certificate for that particular domain you will configure in the ingress object later so this is very very comfortable with this way you can just automatically obtain ssl certificates for every application you're exposing with ingress so the next configuration setting is to disable the dashboard because we don't want a default ingress route to this dashboard because there's no authentication there's no security and the next setting will be the persistent storage for all certificates so this is very important because otherwise whenever you're restarting traffic um and you're not persistently storing the ssl certificate traffic will always need to obtain this certificate every time you're restarting the service so that is not needed if you enable persistence and configure the path ssl certs as a persistent volume which should match the location where you're storing the certificates here and what i also needed to do is i needed to add a section in the deployment init containers that will um change the default permissions of the persistent volume and last but not least we will set traffic as my default ingress controller according to kubernetes 1.19 onwards changes so this is also another setting i need to explain because you can see it can get complex with traffic and reverse proxies or kubernetes this is why i've worked so hard on this project to make this work but um the ingress class is something that is new in kubernetes 1.19 you can read about this in the official documentation of kubernetes you can see the ingress classes can be implemented by different controllers often with different configurations so you could also add multiple ingress controllers on your kubernetes cluster and then you somehow need to configure which ingress controller do you want to use for these ingress objects and in the past you needed to um configure this in the ingress objects with annotations this is why in some outdated tutorials you will still see some annotations that will set the ingress object to traffic this is not needed when you create the ingress class in the first place and then configure it as your default ingress controller because with this heading you don't need any annotations in ingress controllers anymore because it will always use traffic as your ingress controller and it will always try to obtain a trusted sslt from the resolver so with these configuration settings i could completely get rid of any annotations in the ingress object which makes it very very comfortable so um this is my configuration and it works for me very very well but just to let you know it might not work for you because you're using a different dns provider you're using a different um challenge to obtain the certificates or whatever so uh in case you have any questions just join to the discord and just refer to the documentation obviously and use my templates it will hopefully help you okay so we now have created our secret object we have created our values file we now can install traffic and first of all make sure that you have um created a namespace that is called traffic so in case you haven't done this just create ns traffic and then switch your configuration in the current namespace so i'm doing this with an alias command which will use the traffic namespace you can also see if i'm applying any helm charts or kubernetes objects it will tell us this in the zsh extension that i've done by the way i've also done a separate video on my zsh terminal setup you can check it out in the description that is very very helpful for kubernetes okay so now we have done the repo update we now want to install um the traffic helm chart with the project name traffic so let's use the traffic helm chart and we also want to use the values file which is called traffic values.yaml and let's hit enter and see if it works so this is not deployed let's try to get everything in the current namespace and see if it's running you can see that traffic is still panning because it probably creates a persistent volume for the certificates in the background we also already have a load balancer object which has an external ip address so no it's very important that you choose this external ip address of your load balancer object copy this and on your dns server where you have set up your domain name then use this as a target so otherwise when you're trying to obtain certificates or you're forwarding any sub-domains to um services this wouldn't work so i've created an a record for the wild card that is using every sub-domain of clcreative.e forward this to the load balancer object and also the namesee creative.eve so every connection for every subdomain of this should be connected to my load balance object so now let's check if the services are running you can see everything is fine in case something is going wrong you're wondering so what the hell is not working you can always check the events so with coop um ctl get events you can also see what's going on you can see some log files of the kubernetes provisioner but you can also check the log files of the part so for example when we get the pot traffic this is the correct part you can also enter k locks and then the name of your part and you can see everything worked fine the configuration loaded from flex this is now perfectly working we can now start using the traffic reverse proxy okay so now that we have deployed our ingress controller we have prepared everything we can now use it to expose any applications and i will show you how easily it is to just expose an nginx web server with trusted ssl certificates and ingress objects so let's go into this project folder and let's create some new objects we want to expose so um let's for example create another object which is called ingress and not ingress engine x deployment dot yammo and i will just go back to my boilerplates repository because i'm also sharing some um general templates for kubernetes here so in the templates folder you can also see a deployment template for example so let's just use this here copy it and let's add this here so i will make some changes to this deployment because the app name that should be nginx and the namespace should be let's create a new namespace for this so let's create new namespace nginx test for example and let's use this namespace nginx test for our deployment the traffic selector will be set to engine x the replicas are one this is perfectly fine and now in the specifications we obviously won't use this hello world container we want to use an engine x container here and we don't need any resources we want to expose a container part so this is important to set this to port 80. and volume months we don't need persistent volumes for now so let's just go with this simple deployment here but we also want to add a service object because we need to expose this nginx deployment with a cluster ip because this is where traffic reverse proxy can connect to internally of the cluster so we have the kind deployment let's also add a service object to this file so let's go back to my boilerplates and let's go to a service and let's copy the service template with cluster ip for example and paste it here so there's a new service object i want to uncomment the service type object cluster ip we don't need this here the service name will be just nginx just use the same service name the namespace will be nginx test and the traffic selector will be the app name which is also nginx so i you can see i'm making it simple here and the cluster ib will be port 80 so let's just use port 80 that will be fine okay so this deployment will now create a new container nginx and will expose it internally in the cluster on port 80. so let's go with this deployment and apply it okay so if we now get our resources let's also switch into nginx test as my default namespace and let's get let's get all and you should see there are two objects here we have one deployment and the service object cluster ip we don't have any external ip address so no one can actually access this we know when to create an ingress object that will uh connect to traffic and just expose this nginx server on a specific subdomain for example let's just use nginx test.clcreative.de you we want to expose this application with trusted ssl search on this subdomain so now we want to create an ingress object an ingress object that will define the route for traffic so traffic knows where to route um yeah the traffic to okay so let's do that we can actually find this in the same deployment file we don't need to separate this so let's create a new ingress object and you also find a template for an ingress object in the boilerplates repository you can find it here but i also created in the traffic folder a template folder where i can just or where you will find separate templates for the traffic reverse proxy here in ingress object for example so let's copy this and just paste it in my deployment here so you can see the ingress objects let's get quickly through the ingress object it will use a different api version which is called networking k-8s dot io version one from the kind ingress and now we wanna set the name to nginx and the namespace will be nginxtest so now we can also add some optional annotations here so the annotations can configure certain aspects of traffic so you can see uh for example when you add an annotation traffic.ingress.com and then add like a router middleware you can inject middlewares into this ingress objects so we are not covering middlewares here because it obviously would be much more complex for this video this would be too much now what we need to do is we need to set up our host name so now we need to specify our rules here and we want to create a new rule for a specific host name which will be nginx test.here creative.de for example so this route will only listen on that host name and now we need to set up our paths so the paths are important you can set up routes for different path the prefix object will route every path that starts with that but anything behind this path will be also matched for this so for example when you just add this road path with prefix this stands for everything right so every path on this domain will be routed to this back end here and in the back end you can define the service object and then the port number of this service internally so this part number here so let's update this deployment and that should create a new object which is called ingress so when we get all resources you shouldn't see those ingress objects because they are not listed here but when you get ingress you can see this ingress object and you could also edit it we now should be able to open uh the nginx test seal creative.ede so let's uh so now it's working okay so you can see um this is our nginx server that we have just um created and you can see it's using an https connection and we don't get a certificate warning we have obtained a trusted ssl certificate or traffic has done that automatically so now we could deploy any kind of application with an ingress object okay so i hope this video helped you to understand ingress in kubernetes and how to use traffic as your ingress controller i think we covered most of the essential topics in kubernetes which you should know of course kubernetes is much bigger there are endless topics where i could make all videos about but instead of making a tutorial for every single section and aspects of kubernetes i think it might be more interesting to make some videos about projects and things where i will use kubernetes for to deploy my personal website or to run some services in my home lab and just experiment with it so expect more project based tutorials about kubernetes in the future but if there is anything you would like to see a tutorial video about then just let me know in the comments and as always thanks everybody for watching i'll catch you in the next one bye bye

Channel: Christian Lempa

Views: 73,257

Keywords: formation kubernetes, ingress in kubernetes, kubernetes ingress controller, kubernetes ingress controller setup, kubernetes ingress controller vs load balancer, kubernetes ingress example, kubernetes ingress explained, kubernetes ingress setup, kubernetes ingress traefik, kubernetes ingress tutorial, kubernetes ingress tutorial for beginners, kubernetes nginx ingress, load balancing, traefik kubernetes ingress controller, what is kubernetes ingress

Id: n5dpQLqOfqM

Length: 24min 51sec (1491 seconds)

Published: Tue Nov 30 2021