Let's go through this lab on Ingress Controller.
We have deployed Ingress Controller resources
and applications to explore the setup.
Let's first look at the environment.
Let's look at the nodes.
There's a single node.
Let's look at the deployments.
There are no deployments.
Let's check all namespaces.
There are deployments in other namespaces.
There are deployments in the app-space,
the ingress-nginx space,
the kube-system space.
Let's look at the Ingress Controller,
which is usually in kube-system namespace.
We'll see it's in the ingress namespace, which is--
Sorry.
It's given here, it's ingress-nginx.
We see the Ingress Controller and the other parts right here.
Okay, which namespace is the Ingress Controller deployed in?
If you run a get pods -A command,
we see all the pods and we see the Ingress Controller here,
and we see that it's part of the ingress-nginx namespace.
It's the ingress-nginx namespace.
Now, what is the name of the Ingress Controller Deployment?
The Ingress Controller Deployment--
This is the name of the deployment.
We can also verify that by doing a get
deploy in the ingress-nginx namespace,
and we see that it's ingress-nginx-controller.
It's ingress-nginx-controller.
Now, which namespace are the applications deployed in?
Here, we have the pods for the application,
and we have the video there
and the default backend application there in the app-space namespace.
How many applications are deployed in the app-space namespace?
We see that there are three pods, so that's three applications.
Now, which namespace is the Ingress Resource deployed in?
Let's look at the Ingress Resource, so the kubectl get ingress,
and we'll look at all namespaces, and we see
that we have the ingress-wear-watch resource,
and it's in the app-space namespace.
Now, what is the name of the Ingress Resource?
The name of the Ingress Resource is ingress-wear-watch.
Now, what is the Host configured on the Ingress Resource?
You can see that right here, it's set to star.
That means all hosts are applicable, or all or any hosts.
What backend is the /wear path on the Ingress configured in?
Let's look at the ingress
ingress-wear-watch Ingress Resource in a bit more detail.
That's in the app-space namespace.
Here, we see the additional details, and we can see the rules.
We see the host, and then we see the path,
and we have the /wear and the /watch path.
What backend is the /wear path configured to?
The /wear path is configured to the wear-service,
that's the wear-service.
At what path is the video streaming
application made available on the Ingress?
The video streaming application,
the video-service is at the watch path.
Watch is the answer.
If the requirement does not match any of the configured paths,
what service are the requests forwarded to?
We know that if it does not match any of these,
it's going to go to the default backend.
Here, it is default-http-backend.
That's the service, so that's default-http-backend.
Now, view the Ingress Service using the tab at the top of the terminal.
Here, we have Ingress Service, and if you look at it,
it gives us a 404 not found error.
Which page do you see?
We see a 404 error page.
Now, view the applications by appending the /wear
and /watch to the URL that you opened.
Let me open this,
and I have a /wear, which is this.
This is the wear application, and then we have the watch.
Apparently, this is the video streaming application.
You are requested to change the URLs
at which the applications are made available.
Make the video streaming application available at /stream.
For that, let's go and edit
the Ingress Resource.
Let's just replace describe with edit,
and this one should be fairly easy.
Here, we have the paths.
We have the wear path for the wear service
and then we have the watch path for the watch service.
All we have to do is replace this with /stream.
Now, let's save that.
It's immediately replaced.
If we refresh the watch path, now we get a 404 error,
and we replace it with stream,
and we now get the video streaming application.
Let's check that out, yes, that's successful.
Now, view the video application using the stream,
which we already did it, so let's skip that.
Now, a user is trying to view the /eat URL on the Ingress Service.
Which page would he see?
We know that there's nothing called /eat.
Let's just verify.
There is nothing called /eat here,
but we don't know if it's there in another space.
Let's try that out.
Eat, it doesn't--
There's nothing, it's a 404 error.
There's a 404 error.
Now, due to increased demand,
your business decides to take on a new venture.
You acquired a food delivery company.
Their applications have been migrated over to your cluster.
Inspect the new deployments in the app-space namespace.
Okay, let's check out
deploy in the app-space namespace,
and we see that we have the default backend,
we have food along with the video and wear application.
This is the new application.
Now, you're requested to add a new path to your ingress to make
the food delivery application available to your customers,
so make the new application available at /eat.
We want to make it available at /eat.
We know that we need to find out the service that this is exposed on.
Let's try and find that.
Instead of deployment, let's look at services in the same namespace.
Now, we see that we have the food-service,
and let's also verify and make sure that the Port is 8080.
It's food-service at Port 8080.
I'm going to copy that, and let's go and edit
the Ingress Resource again.
We have a command for that already, kubectl edit ingress,
the name of the Ingress Resource in the app-space.
What we need to do is add an additional path here.
We're going to copy this,
paste that.
What we'll do is you know
that it's food service, so food-service, and
the port number is 8080, that's fine, and the path is /eat.
Let's save that.
Let's wait for it to finish.
Okay, and let's try to refresh,
and we see the food-service application.
Okay, let's check the work.
Now, view the food delivery application
using /eat, which we already did.
Now, a new payment service has been introduced.
Since it is critical,
the new application is deployed in its own namespace.
Identify the namespace.
Let's do a get pods -A, and see what the new namespace is.
We have a new namespace called critical space.
Let's do a get deploy in the critical space,
and we see that we have our webapp-pay.
This is the new deployment.
Identify the namespace.
That's critical space.
What is the name of the deployment of the new applications?
We just found that out, it's called webapp-pay.
You are requested to make
the new application available at /pay.
Identify and implement the best approach to making
this application available on the Ingress Controller
and test to make sure it's working.
Look into annotations as well.
Okay, we know that for the app-space applications,
we have the Ingress Resource in the app-space.
Now, we cannot use that resource to add something in another space.
What we're going to do is we're going to create
an Ingress Resource for this critical space itself.
Well, at least, that's the best practice.
The best practice is to create--
For different teams who maybe are having
access to different namespaces
to create their own Ingress Resource.
That's should be the approach that we should be using.
You can assume that maybe those who are working
on this application only has access to this namespace,
but those who are working on the web-pay application
only has access to this namespace.
Any ingress-related resources that are created
would have to be created in this namespace.
We'll create a new ingress,
and then we'll set the path as we did before.
We'll set the backend service.
Let's first find out what the backend service is
to this web-pay, it's called pay-service,
just like food service [?] this one's called pay-service,
and the deployment is webapp-pay.
We want to direct traffic that goes to the path /pay, which as of now,
there won't be anything.
We want to direct that to this pay service on port.
Remember that the port now is 8282.
That should be the port.
Let's do a kubectl create ingress.
We do have an imperative command for that.
Let's do a -h to see the format.
We're going to other multiple examples.
Let's just pick the simplest one, so kubectl create ingress,
the name, and then the role.
That's basically it.
Let's do that.
The name, let's see if there's a name given.
There's no name given here, so we could give it any name.
This is going to be ingress-pay maybe,
and then it's in the namespace.
Remember that this has to be in the critical space.
Then, the rule is that anything that goes to--
Sorry, /pay, the path /pay, so that's /pay here,
would go to the pay-service, that's what we just saw,
and the port is 8282.
We don't have any certs for now, so let's just get rid of this.
That's the ingress-pay.
Let's check it out
what ingress in the critical space.
Obviously, that is indeed created.
Let's take a look at it, ingress in critical space.
We see that we have the ingress-pay
is going to catch everything that goes to pay
and then redirect that to pay service.
Let's go and try it out here.
You see that it's still not working as expected.
It still gives a 404 error.
Let's take a look at the logs and find out why.
If you look at the logs
of this application in the critical space,
we have the webapp-pay service, the webapp-pay pod.
Then, what we're going to do is we're going to do a logs
for that pod in the critical space.
We see that these are the requests that are coming in.
It's coming in as pay.
The thing is, these applications may not have a /pay at the end.
It should be without this pay.
What's happening is, when you're calling /pay,
the Ingress Resource is just forwarding as is,
the URL as is to this application,
and this application does not really have a /pay path.
It should just be just /.
Let's do that.
For that, we have to put in the ingress, the annotations, and the rewrite rules.
If you look at this, the watch, wear, or even the pay service,
they're just available at this.
They don't have a /watch or /wear at the end,
but with the default rule that the Ingress Controller creates,
anything that goes to watch is going to have watch at the end.
Anything that goes to wear is going to have wear at the end,
so that's why the error.
We want to put in this rewrite annotation to get that removed.
Let's copy that.
Let's edit the ingress-pay
in the critical space.
We should have ingress and then
we've got to add an annotation here.
Annotations go in metadata section here.
We're going to save the rewrite target.
This is basically going to take that out
and take out the pay at the end and just put / there.
That seems to be set.
When you refresh it,
you can actually see that this is working as expected.
Let's check our work, looks good.
Yes, we've already gone here and verified that it's working.
Okay, that's the end of this lab.