How to use NGINX Ingress with Kubernetes in 2023

you have to see my name so you've taken the Journey of learning kubernetes and you've heard about kubernetes Ingress which essentially helps you seen traffic from the internet to your services running in your cluster now if you want to use Ingress in kubernetes as a feature you need to learn about Ingress controllers in this video we'll take a look at how to use the nginx Ingress controller we're going to take a look at the installation process some of the important and Powerful features and some real world examples we've got a lot to cover in this video so without further Ado let's go [Music] an Ingress controller is a proxy that acts as a Gateway for your services it can be any type of proxy in our case nginx an Ingress controller listens for Ingress objects when an Ingress yaml is applied to the cluster it automatically synchronizes this with engine X by gracefully updating the nginx configuration we can send traffic based on domain and path to different services so if you take a look at my GitHub repo I have a kubernetes folder and in here I have everything related to kubernetes I have an Ingress folder and under the Ingress folder I have a controller folder and this is my folders where all my Ingress controller guides are located today we're going to be taking a look at nginx if I go down there you can see we have a readme file and this is our introduction to nginx Ingress controller we're going to take a look at spinning up a kubernetes cluster installing some tools and essentially installing the nginx Ingress controller take a look at all the features and everything that I've done is documented in this GitHub repo so be sure to check out the link down below to the source code so you can follow along now the first step in our guide is to create a kubernetes cluster now for this I'd like to use a utility called kind which helps us run lightweight kubernetes clusters in Docker containers this is very useful because we can spin up kubernetes clusters as many as we want it starts up really quickly and we can throw them away once we're done so to create a cluster it's very simple I just say kind create cluster I'm going to call this one nginx Ingress so I give it a name and I'm going to run kubernetes 1.23.5 so I go ahead and copy this paste it to the terminal and that will create a new kubernetes cluster that we can use for testing once that command is finished you can see we now have a kubernetes cluster up and running ready to go and to see my cluster up and running I simply say Cube CTL get nodes and when I run that we can see we have a OneNote kubernetes cluster up and running now the next thing I'm going to do is run a lightweight Alpine container on my machine to install some utilities and the reason why I do this is for portability because most of you are running Linux environments you may use tools like JQ curl W git and other utilities such as cube CTL and Helm I'm going to create this lightweight Alpine container install all of the dependencies that I need for this demo and this is very simple all I do is say Docker run minus it I want to remove the container when it's done I want to mount my home directory into the home directory of the container this is so that I can access my kubernetes cluster because the dot Cube folder is also inside there so Cube CTL will use that Cube config file and then I also Mount the working directory that is the directory we are in at the moment for this repo into the work folder and I set my working directory to slash work then I want to run my container on the host Network as well and simply create a small Alpine container with a shell terminal I go ahead and copy this paste it to the terminal and I have a container if I do LS minus L we can see I have all the files here that are all the files on the left hand side now I'm going to go ahead and install some utilities I install curl so I just say APK add install curl and then I use Curl to download and install cubectl so simple command curl get Cube CTL give it chmod execution rights and move it to use a local bin go ahead and copy paste that to the terminal and that'll install Cube CTL inside of the container go ahead and clear the terminal and now I can install Helms I say curl the same way I downloaded cubectl I'm going to grab the helm tar file I'm going to extract it using tar I'm going to move it to use a local bin and give it execute omissions go ahead and paste that to the terminal and that will install Helm CLI in my container so now I can say Cube CTL get nodes we can access our cluster I can also say Helm and I have Helm installed and this is because we're going to be using Helm to deploy the nginx Ingress controller or at least manage the templates now there are a number of ways you can deploy the nginx Ingress controller you can install it directly using the helm chart or you can use the helm template command to grab the Manifest and then store that in your git repo and use something like flux or a git Ops pipeline to deploy it I like to just get the manifests and deploy them myself this means I can look at the Manifest I can compare it with older versions and I can see exactly what's going to change I can also take that yaml files and store it inside my git repo and keep it as my infrastructure source of Truth so before we continue just a quick word from our sponsor who made this video possible so you have kubernetes clusters how many pods and deployments do you manage across how many kubernetes clusters how many environments do you maintain with kubernetes in the cloud it is very easy to reach scale and with kubernetes at scale the chances of misconfigurations are high the tree is an open source tool that can help us secure our kubernetes environments by blocking deployments of misconfigured resources the tree is very to install on your platform once the tree is installed when deploying resources to kubernetes the tree will create warnings when misconfigured resources are deployed to your clusters and when ready you can enforce your policies by turning on in Force Mode now when deploying resources to kubernetes the tree will block when misconfigured resources are deployed to your clusters the tree has a dashboard that shows your cluster's score and all failing policies but more importantly shows you a detailed view of each failure the fixed complexity and exactly how to fix it the tree also has an open source CLI so your engineers can test and validate their deployments during development the tree ultimately helps you build a roadmap to better kubernetes security and best practices so your cluster can go from a d-score to an a score and prevents your clustered posture from degrading this video is proudly sponsored by the tree remember to check out the link down below for the full the tree tutorial now I always like to start with the nginx Ingress documentation now there's two Ingress controllers so don't get it messed up one is managed by nginx the other one is managed by the kubernetes nginx community you can find the link in my readme file right here this is the documentation for the Ingress controller now on the right hand side here there's also a GitHub link if you go to that you will get to the GitHub repo which has an overview page a getting started guide as well as an important part that I like to emphasize on which is the supported versions table this is very important when you're deploying kubernetes cluster that you make sure that the nginx Ingress version is compatible with the kubernetes version so you have to make sure you pick one that is either forwards and backwards compatible if you're going to be doing cluster upgrades so you can plan accordingly so we are going to be interested in the Ingress nginx version 1.5.1 because it's compatible with our kubernetes cluster and it's also forwards compatible with kubernetes 1.24 and 25. now I've documented all the steps that we're about to take so we're going to get the installation yaml and we do this by saying Helm repo add we're going to add that Helm repo you can see here I'm saying kubernetes Dot github.io and I put the link of the repository go ahead and copy paste this to my terminal and now the repo is added I can go ahead and search it so I can say Helm search repo and show me the versions copy paste this and you can see all these versions are now available you can see the chart versions but don't get that mixed up we're interested in the app version and we saw on the compatibility page that we're looking for at version 1.5.1 so we're interested in this Helm chart so to get that version of the yaml it's very simple I set two environment variables I'm going to say chart version 4.4.0 and app version 1.5.1 go ahead and copy paste this I'm going to go ahead and create a manifest directory inside my kubernetes Ingress controller nginx folder so we can store this manifest in GitHub go ahead and create that directory and that directory has been created on the left here so instead of saying Helm install I say Helm template I pass in the helm repair I want to install I give it the repo you can see here the kubernetes.getup.io and then I give it the version of the chart that I'm interested in and then what I'm going to do is I'm going to also specify the default namespace this is the namespace the controller generally goes into and then I'm going to Output that yaml on the left hand side in that folder that I created under kubernetes Ingress controller nginx manifests and in the file name I'm going to put the app version so I know which version of the nginx controller has been installed so go ahead and copy paste that to the terminal and you'll see this creates the yaml file on the left hand side here and this is very useful because when new upgrades come I can simply follow this process and get the new yaml and compare it with the old one and see what's changed I can use something like flux or Argo to deploy and manage this as well and to deploy this Ingress controller it's very simple I create the namespace first so I say Cube CTL create namespace Ingress nginx run that that'll create the namespace and then I deploy that yaml inside of that namespace and I do that by saying Cube CTL apply minus F and I apply that yaml file that I've just created go ahead and run that and you can see it deploys all the components to get the Ingress controller up and running and to check my installation I say Cube CTL in that namespace I deployed it get pods and we can see there are some jobs that have completed to help set up nginx and the nginx Ingress controller which is up and running now the next thing that's very important to understand is that our traffic for our cluster will come in over the Ingress service so to see the Ingress service we have to say Cube CTL in the namespace get service if we run the this we can see we have a service of type load balancer which has an external IP pending because I don't have load balancer support in my local kind cluster now for testing purpose of testing this nginx Ingress I can simply run a port forward command so in a new terminal what I can do is say Cube CTL in that namespace port forward to a service and port forward to the Ingress nginx controller service on Port 443 by default an Ingress controller uses 443 for TLS traffic I go and paste this to the terminal and you see it starts port forwarding I can then reach my Ingress controller on https localhost and if I open up https localhost you can see that we are getting SSL warning I can proceed and we get a default back-end page which is a 404 because there's nothing listening behind this our English controller doesn't know how to deal with this traffic so all the requests that it doesn't know how to deal with it'll get 404. now it's import important for us to understand that a kubernetes service is a thing that allows us to expose pods to the Internet so traffic will come in from the internet and hit our Ingress nginx pods now a service can expose pods either publicly or privately a public service can use something like a node port or in better cases a load balancer Ingress controllers generally run in the cloud and prefer load balances this means that all your public traffic will come through and hit the load balancer first which will be the entry of the cluster and then route to your nginx Ingress controller which will do more complex routing like HTTP routing via domain and path and more complex and advanced HTTP features it's also important to know that the Ingress controller runs on two ports 80 and 443 the Ingress also creates a fake certificate and this is the common name kubernetes Ingress controller fake certificate this is a default certificate that Ingress will serve so now we've covered the installation process now the next things to use an Ingress controller and its features we need to have some Services running that we want to expose so let's go ahead and do that let's create two micro services in our cluster called service a and service B and I have the yaml for these applications under kubernetes Ingress controller under nginx under features this is the folder that'll contain all our test yaml and in here I have service a service A and B are two micro Services running in our cluster if I look at the yaml for service a you can see there are two config Maps a deployment and a service if we take a look at more importantly the deployment we'll see that we're going to run one replica the app is service a and we take a look at this app and it's going to be running on container Port 80. so we're not exposing this application to the public and we're not using Port 443 and this is more important we'll see this later if we go down and look at the service the service tells us how to expose this application and if we take a look we're not exposed closing this publicly because it's not a type load balancer service or a node Port service it simply is a private service running in the cluster and it's running Ford 80 which maps to The Container Port 80. so we can run all our services privately if I take a look at service B dot yaml it looks very similar it's got two config Maps a deployment and a service if we take a look at the deployment it's called service B it also exposed Port 80 and the service is also a private service exposing Port 80. so it's typically how we deploy micro services in kubernetes by keeping them all private and using an Ingress controller to expose them now to deploy Service A and B I'm simply going to apply the two yaml files and I'm just going to deploy this to the default namespace I'm going to say Cube CTL apply minus if and I'm going to apply service a.yaml go ahead and paste that that'll create my config maps and my deployment and its service and I do the same thing for service B go ahead and paste that and that'll also deploy two config Maps a deployment and a service I can do Cube CTL get pods and we can see I have service a running and service B running as private services in my cluster Let's test service a by running port forward command to service a I'm going to do that I'm going to just say Cube CTL port forward to service a on Port 80. go ahead and run that and you can see if I go to localhost I'm hitting slash as the path on service a so what I've done with Service A and B is I've actually just written the path that you're trying to access and if I try to access any other path it'll give me a 404 page I've given examples here of what service A and B can do if I try to hit localhost path a it'll route to slash path a DOT HTML which is an endpoint of my service if I hit that you can see we're now hitting path a and similarly I also have path B so you can see we have path a and path B both being exposed by service a and then any other path that it doesn't understand n goes to a 404 page so this application can only serve root it serves path a and path B and anything else goes to 404. [Music] now the most common feature used by Ingress controllers is to Route via domain so routing traffic by domain so this is the most common way to Route traffic where you create like a domain so here I have public service a and public service B let's say you own these domains you would configure these to point to your Cloud load balancer from the load balancer it'll go and hit the Ingress and it will technically route from the Ingress to the kubernetes service of service a and service B so you can see internally this will offload TLS and route to service Dash a or service Dash B based on the domain that's coming in now you can see here I'm using public dot service a.com this is just a fake domain that I don't own to mimic this fake domain I've just created a host file entry you can see I have public.servicea.com and public dot service b.com pointing to my logo so generally you'd go ahead and purchase domain and pointer to your Cloud load balancer so that traffic will be coming from that domain to your Ingress controller and then you would create a very basic Ingress so here's an example of an Ingress for service a if I want to expose service a publicly I create this thing called Ingress I give it a name so I'm going to call it service a and here I say my Ingress class name is nginx I want to use the nginx Ingress controller this is the host I'm expecting traffic to be on so this is my domain where traffic is coming from and I am expecting all traffic so from the roots of my URL to go to my backend service and the backend service is called service a this is the kubernetes service we created earlier in our service a.yaml and the port that it is exposing so this will tell the nginx Ingress controller to forward all traffic from the root path on this domain forward it to service a on Port 80. very very simple I have this example people yaml defined in a folder under kubernetes Ingress controller nginx features and I have it called routing by domain if you click that you can see the Ingress that I'm deploying and in this case I'm deploying two of them I'm deploying one for service a which is what I showed earlier and exactly the same thing for service B but I'm using a different name for service B and I'm telling it I want to Route all traffic to service B so this shows you how to route multiple domains to different pods behind the scene and this is a good way in kubernetes to Define where traffic must go without me having to have knowledge about how to configure nginx proxies so I declaratively state that I want all this traffic to go from this domain to these services so to deploy that I have the example command here Cube CTL apply minus if and I just go ahead and apply that routing by domain yaml file that will deploy the two ingressors that I've showed earlier go ahead and deploy that you can see it created an Ingress called service a and an Ingress called service B now we can go ahead and access our service A and B on their domains now remember we don't have a load balancer service for our nginx Ingress so I'm port forwarding to it so that we can access it for this demo and then when I access these URLs we get to the basic page for TLS we go ahead and proceed and we can see now we're hitting service a from the service a domain and we're actually reaching the same path so we're reaching roots on service a and if I change this to service B the same thing happens there I go ahead and accept the TLs connection and I'm now accessing service B on Route also note that I can access the sub paths as well so the path a and path B that I defined I can also expose that so anything that comes with Slash will go to myservice A or B so you can see here I've accessed service B on path a and I've hit path a on service B now another strategy for routing is based on the URL path so instead of every single service having its own domain especially in a microservice world you can combine them under one domain and simply route by URL path so we can do something like say path a goes to service a and slash path B goes to service B so for example I can create one domain in this case I can say public.myservices.com I'll create a host file entry for that and then I can say route all of the traffic that has path a route that to my service slash path a and I can do the same thing for service B I can say anything that says slash path B go to service B and to do that via an Ingress I create a new Ingress in this case I'm going to update our Ingress called service a and I say I want all traffic coming in on my combined my shared DNS name so I'm going to create a new one called myservices.com anything that goes on must go to my back end service a on Port 80. and I create this new field this annotation called rewrite targets that means I want to rewrite the URL that the service sees to slash so let's go ahead and deploy that Ingress so I say skip CTL apply minus F and this time I've got this nginx Ingress saved under routing by path.yaml so I'm going to go ahead and copy and paste that to the terminal and configure Service A and B you can take a look at that gamble which has the Ingress for service a as well as the Ingress for service B and it has the changes that I showed you in the readme file so now we can see if I access my shared domain and I say slash path a I'm I'm hitting root on path a if I change this path to path B I'm hitting root on service B so very simple to route based on path now there's one side effect here notice that no matter what I put in behind this part off if I put slash test or any kind of test query string or any kind of URL parameters it'll always simply hit the slash because we have a rewrite URL configured so no matter what I put behind the path even though our service is configured to serve something like path a if I try to hit that path a we'll not hit the path a inside of the service you see it always hits the root page and it's very important to learn how to troubleshoot this sort of behavior and to do that you need to start learning how to read the Ingress logs So within the Ingress namespace you can run the logs command you can just get the logs out of one of the pods I'm doing it via label so I'm reading all of the logs using Cube CTL if I go ahead and run that we can see all the different web logs so we see exactly what our Ingress sees and what it passes to the Upstream so you can see here get on path a hit our default service service a and if I look at path B path B also hit service B so the routing is working correctly but you can see that no matter what we pass behind path B we always just go to service B it's not passing the Upstream route as you can see it's blank now to get around this we'll use a thing called URL rewrite which we'll take a look at next but before I take a look at that it's important to also understand what approot means if we take a look at the routing by path that we deploy you can see that nginx supports various annotations so URL rewriting is part of a thing called rewrite Target there is another annotation which is called approot now we're not going to look at it in this demo because I don't have an application that looks like this but a lot of the times you'll deploy something like grafana or something else you want to expose via an Ingress but sometimes you might have a URL that looks like this where the application is expecting traffic to go to slash home in that case we just set a annotation called called nginx Ingress kubernetes.io approot to slash home this means that the controller will be aware that all traffic that matches path a will go to slash home on service a now probably the most popular feature of the nginx Ingress controller is the URL rewriting previously when routing by path we basically said all traffic coming from this domain on path a go to service a and all the traffic on the same domain going to path B go to service B and we notice when traffic goes to the Upstream services that it always hits the root of the URL it doesn't actually pass any remaining path behind it to the Upstream this is where URL rewriting comes in we can dictate what paths the customer will see in the browser and what path and URL parameters to pass to the Upstream services so if we take a look at my readme to do URL rewrite and allow the Ingress controller to pass paths to the Upstream we need to look at rewrite configurations I put the link right here this will take you to the Ingress controller documentations to the rewrite section and this gives you examples on how to do rewrite rules you can also find the link on the left hand side for rewrite and there's a whole lot of other configuration so feel free to save this URL and dive deeper into the documentation now for URL rewrite we have a specific annotation it's called nginx Ingress kubernetes.io rewrite targets and this is the target URI where the traffic must be redirected and this is what it looks like so we say we want an Ingress we give the name here's The annotation for the rewrite Target and notice that we say we don't just say stash but we say slash dollar two the reason we put a dollar two here is we are telling nginx to pass the second capture group to the Upstream the first capture group is not important to us because that's going to be the domain the front of the URL we want the back part of the URL to be passed to the Upstream then we say our Ingress classes nginx and we say we want all traffic for public.myservices.com and the path is slash path a so anything that matches slash path a will be routed to our backend service which has a name service.a but notice that I have some capture group regex here and this is the regex to pass everything behind path a to the Upstream if we take a look at the documentation they have an example on how to do that so here they pass something and everything after to the Upstream so everything after here becomes dollar two and dollar two you pass it to slash dollar two and that's as simple as that and to deploy it we're just going to apply the yaml file I'm going to say Cube CTL apply and this time I'm going to apply the feature called routing by path rewrite.yaml if you want to take a look at that example file so I go ahead and paste that in the terminal and that'll reconfigure Service A and B's Ingress now you can see to test that I can just go to my domain and I can say slash path B which will hit root on service Dash B but if I pass any path that my application expects remember Service A and B can expect path a and path b as well so I can say slash path a or I can say slash path B and the server should see that so if I run that you can see now we've accessed path a.html on service B and I can also say I want to access path B which will access path B dot HTML on service B so now my service can see the URLs passed to it and I can control what the customer sees in the browser which is this path B portion and it's also very important to understand how to troubleshoot these requests because it can be really confusing when you start getting 404 not found is it the 404 of the Ingress controller or is it the 404 of your service did your service receive the right path did the Ingress send the right path to your server to understand this it's very important to enable access logs on both the Ingress controller as well as the service you're working with so URL rewrite it gives you that flexibility to control parts of the path that the browser sees and what the application sees now if you pay close attention to the logs and what we've been doing you'll notice that traffic comes in over Port 443 but when it hits our service A or B it goes over Port 80. that is because by default Ingress controllers terminate SSL this means that if you use a valid TLS certificate the client coming in will talk over Port 443 to the Ingress controller but behind the scenes the Ingress controller will create a new connection over Port 80 which is non-tls this is the default behavior and a very common approach is we don't want to configure TLS on every single micro service the downside is that Upstream requests are not encrypted but it greatly simplifies the implementation especially in large microservice environments now if you want SSL to be passed through you can use the SSL pass-through annotation so on your Ingress as we saw earlier where you have annotation sections you can just update and add this annotation which will tell the Ingress controller to pass through the TLs so it doesn't need to decrypt the packet it'll just pass it to your service A and B but that means your service A and B needs to be configured to read and decrypt SSL now you can also go ahead and protect certain Services by using the IP whitelist annotation that is if you want only certain customers to come to that micro service so it's protected by ipwitless and we achieve IP whitelisting by looking at the whitelist Source range annotation this is another annotation we can put on the Ingress object which looks like this it's nginx Ingress kubernetes on iO slash whitelist Source range and you can put comma delimited list of IP addresses here this is also documented here in the documentation under the whitelist Source range so when doing this only individual Ingress objects are whitelisted for example I can protect service a with whitelisting but make service B completely public and that's also possible or I can just globally apply it to all Ingress Rules by using the nginx config map and we'll take a look at the nginx configuration config map in a bit now on top of ipwide listing there's also some extra ways to secure our services with different authentication methods the Ingress controller supports oauth basic authentication as well as certificate authentication so what I'm going to do is I'm going to show you a basic one using HTTP basic authentication this is controlled by annotation so you need three annotations on your Ingress object so you can protect one service with a username and password and leave the other one public it's entirely up to you so we have one annotation which says our auth type is basic and then we add a secret which is our username and password we want the client to use and we give a secret type which is going to be the authentication file now to do this to set this up what I'm going to do is I'm just going to install a utility HD password I say APK add Apache to utils go ahead and run that and that'll give me access to this ability I can say HD password minus C auth Service a user go ahead and copy that and so this is my username and then I give it a password so we can say my password is test and I type it again and that has added a password for our new service a user so you see this has created a file here on the left called auth if I open that file we can see this is what a username and password combination looks like in HTTP basic authentication so if I run the ls command you can see the auth file is there now what I need to do is create a kubernetes secret from that file so I say Cube Ctrl create secret generic I'm going to call it service a secret because that is what we specify in our yaml on the right hand side here and from file the auth file so go ahead and run this and that's created a new Secret and the secret has to be in the same location as our Ingress rule so if I say Cube Ctrl gets secrets we can see there's a secret there and if I say Cube CT I'll get Ingress we can see how Ingress is here as well so it's all in the default namespace so to deploy that I can say Cube CTL apply and I'm going to apply in my features folder the basic auth.yaml go ahead and run that and that'll configure my service a but leave my service be unchanged so to test that I can just refresh this page and notice that there's no authentication on this one but as soon as I change to path a it's going to ask me for my username and password my username is service a user so go ahead and put that username and my password is test and you can see I've now accessed my service now the nginx Ingress controller is one of my favorites this is because nginx is a very very powerful HTTP proxy for web applications and the nginx Ingress controller exposes the full capabilities of nginx and allows us to customize it there is a full config map where you can take advantage of all of this and you can do things like rate limiting custom cross origin requests and even lower scripting you can even control things like setting header and body size limits and adjust the log format and more now I added a link to my readme file under customization it'll take you to the config map section and this is the documentation on the config mapping you can just see by the looking at the right hand side all the different options that you can see here to customize nginx everything from global settings to proxy timeout settings open tracing Zipkin Jaeger keep alive timeout settings gzip and broadly compression different SSL settings and more we can also do things like setup server Snippets so if we wanted to do something specific for service a and not service B we can use the service snippet annotation so here you can see that they have an example on an Ingress where they redirect the traffic to the mobile side so you can say if this request comes to service a go to the mobile site of service a if it comes to service B go to the mobile site of service B by setting a service snippet this will inject for the specific nginx block a snippet that you wish to set now in this demo I'm going to show you how to customize nginx a little bit by using the config map and what I'm going to do is just show you how to change the log format for example so here you can see I've customized the log format by adding this property so I add log format Escape Json to true this will make sure the log format for my nginx is escaped so it can be parsed by any service like elasticsearch or wherever I'm planning to send my logs and then I'm also going to set the Upstream format I'm going to say log format upstream and I'm just going to set it to this big block of Json so you can see this is very important because I can control the time format I can say the remote address so who's connecting to my nginx Ingress controller I can see the X5 forwarded four I can see the host where the traffic came from which domain the request method whether it's get or post the request URI that came in so I can see the full path I can see things like the request time how long it took for the request to come back this is very useful in troubleshooting the bytes sent the Upstream name which is which services that request going to the Upstream address this is the kubernetes service or the Pod IP depending on where it connects the URI which is very important the Upstream URI this is like what URL does the service on the other side see so to apply the setting what I'm going to do is open up the Manifest yaml file that I downloaded earlier and I'm going to find the config map so this is the config map here its name is ingress Dash nginx-controller and I can expand and add all my config Flags in here as it's documented in the config map section I showed earlier so what I'm going to do is I'm going to add two new Flags the first one is log format Escape Json set that to true so I'm going to go ahead and set that and the next one is the log format Upstream I'm going to go ahead and copy that and set it as the next line so you can see that's now been set ready to go and to apply the changes I simply reapply the cube CTR yaml file so I say Cube CTL apply minus if and I apply my Ingress like yaml this will go ahead and apply the config map so you can see it's applied my config map and then what I'm going to do is just restart the Pod so I'm just going to go ahead and delete this pod go ahead and do that that'll launch a new pod which will consume the config map and if I do qctl get pods we can see we now have a new Ingress controller coming up now remember because we use port forward to test that we have to recreate our port forward so what I'm going to do is just go ahead and pull forward again and then what I'm going to do is just go and hit service b a couple of times refresh that a few times now if we go back and check our logs we can now see that our logs is coming through in Json format and this will greatly help you in debugging the application because now we can exactly see the Upstream path as well as the path that comes in over the browser so we can see if we look at this log entry we can see this is the host that traffic came on this is the request URI the path in the browser so path B slash path B dot HTML and more importantly we can see the Upstream URI so we know the Upstream address we know the service it went to which is service B and the Upstream URI so this is the path that our Upstream saw which is slash path B so any misconfigurations or 404 you can just use this log format to troubleshoot to know exactly what path came in and where it went so hopefully this video helped you dive head first into the Ingress ocean if you like the video be sure to like And subscribe and hit the bell and if you want to support the channel even further be sure to check the patreon link down below or click the join button to become a YouTube member and as always thanks for watching and until next time peace [Music]

Channel: That DevOps Guy

Views: 18,877

Keywords: devops, infrastructure, code, kubernetes, k8s, cloud, training, course, development, deployment, containers, engineer, tech, tips, linux, nginx, ingress, loadbalancer, proxy

Id: 72zYxSxifpM

Length: 38min 32sec (2312 seconds)

Published: Sun Mar 19 2023