Welcome back everybody.
We need to change the way that we're accessing our entry point.
Our great submission portal.
Front end.
We can't be using the node port service anymore.
Zooming in on just the great submission portal pod.
Currently, we're using a node port service to expose a static port on our nodes as IP address.
Now, because we're prototyping and we're doing everything locally, the IP address in this case is
very obvious and we can just very easily say localhost 32,000 and direct our external request to the
internal pod.
But in a realistic scenario in production, when we've got a Kubernetes cluster on AWS with many, many
nodes, with each node with a different IP address, and only some of the nodes could be running our
app, keeping track of all the correct IP addresses would be very, very hard, especially in this day
and age where environments are very dynamic.
IP addresses are being changed very frequently, so relying on an IP address on a static IP address
to access our apps just doesn't make any sense.
All right.
So node port we're going to officially retire it in this section.
So we're going to replace it with a solution that can actually scale to when we deploy our cluster on
the cloud.
So when we do deploy our cluster on the cloud it's going to look something like this.
We're not going to have one node.
We're going to have many worker nodes running our container workloads.
And we can make an assumption in this case that each worker node is running an nginx ingress controller
pod.
So let's assume you bought a domain from a registrar like GoDaddy and you bought the domain.
Great submission portal.com, and you made that domain point to a load balancer that is provided by
AWS.
When you deploy your cluster on AWS, you get access to a load balancer, which is a server whose sole
purpose is to load balance traffic across your worker nodes.
Load balancing is important because you never want to put too much burden on one node.
The load balancer ensures that traffic is load balanced appropriately, so it's going to choose one
of the worker nodes to forward that request to.
But ultimately the recipient of that request is the nginx ingress controller.
The nginx ingress controller acts as a reverse proxy.
What do I mean by this?
Let's imagine a traditional forward proxy, which acts on behalf of the client to send a request to
a particular server.
A reverse proxy in this case acts on behalf of the server to decide where a request is going to go,
and it relies on ingress rules that we're going to write ourselves to direct the request to a certain
cluster IP service.
Once the nginx ingress controller determines which cluster IP service it needs to forward the traffic
to the cluster IP service, as you've seen in this course, or as we've talked about in this course,
is a natural load balancer itself.
If we assume that we had four pod replicas of the Great submission portal, the cluster IP service will
naturally load balance traffic to them.
So the cluster IP service is a natural load balancer at the pod level.
And by deploying our cluster on AWS, we get a load balancer at the node level.
Okay.
So we've got load balancers everywhere.
That's pretty cool.
But we haven't deployed our cluster on AWS just yet.
We're not going to buy a domain from GoDaddy.
We don't have a fancy schmancy load balancer just yet.
We're still doing things on our local machine, which means we still need to say localhost, and it
follows that an ingress service is going to expose a static port 80.
So we can say localhost 80.
Invoke our ingress controller, which will rely on ingress rules to determine which cluster IP service
it needs to send that traffic to, and then the cluster IP service will send that traffic to the appropriate
grade submission portal pod.
So technically we've still got this going on.
Okay.
Except that instead of having an AWS Elastic Load Balancer, we're still using localhost 80.
But the ingress controller solution will ultimately scale when we do deploy our cluster, our Kubernetes,
our Kubernetes cluster on AWS.
So enough talk.
Let's go ahead and do this right now.
Um copy and paste section nine.
Call it section ten.
All right.
And before we start what do I want to do?
So the horizontal pod autoscaler I'm not going to carry it over to the remaining sections.
So let's delete it was a very fun section to create however.
And let's delete the Horizontal Pod autoscaler from our grade submission namespace.
We'll keep the metric server because it is nice to say kubectl top pods, and be able to see the CPU
and memory usage of our apps, so we'll keep it in section nine.
That way you have reference to what a horizontal pod autoscaler is, but I don't intend on giving the
Great Submission API or the portal or our Mongo apps scaling auto scaling capabilities.
We're just prototyping.
Um, I don't imagine we're ever going to be flooded with requests, but in a production environment,
do consider the need of an autoscaler.
Okay, let's clear the output CD out of section nine.
Um, I'll CD into section ten.
All right.
And here, our great submission portal relies on a node port service to expose a static node port 32,000.
Ah, let's not do that.
We're going to make this a cluster IP service in accordance.
Nope.
Wrong thing.
In accordance to the diagram that we have right over here.
Okay.
So the cluster IP service is going to send traffic to the great submission portal pod.
But it relies on the ingress controller in order to receive traffic from the outside.
The ingress is ultimately the entry point into our Kubernetes cluster.
All right.
Now, before we do anything, let me grab a command.
Um, what I want you to do is say kubectl delete namespace ingress engine x.
So you probably don't have this namespace, but I don't want to take any chances, just in case you
decided to play around throughout this course.
So I don't have it yet.
You shouldn't either Um, and after you've made sure that you don't have that namespace because we want
to start off from a fresh installation.
I left you this command inside of your resources folder.
Okay.
Um, it's inside of a text file.
So copy and paste this command and we can use it to install and the nginx ingress controller.
So if I say kubectl get pods dash n nginx ingress or ingress nginx we can see that it's currently starting
up.
Okay.
We'll give it time.
All right.
So inside of section ten I'm going to say great submission portal ingress.
Dot YAML.
And now I'm just going to write ingress.
And it sets up an ingress resource I'm going to call the ingress resource great submission Mission portal
ingress.
Deploy it in the namespace.
I'm not going to forget the namespace this time.
Great submission.
Don't really need any labels for this one.
Here we specify the rules okay.
The host is the fully qualified domain name.
All right.
So we're not actually going to buy a domain.
Uh great submission portal.
Com or anything.
Uh so we can just remove host.
Basically this rule it accepts traffic from any host and will forward it to our cluster IP service,
which I'll define in a second.
Now path type prefix means it will match any path that starts with slash.
So basically we're allowing requests from any hosts with any path that starts with slash and forwarding
that to our cluster IP service.
So the host could be example.com uh great submission portal Com or in this case just localhost.
So this host is going to be accepted by our rule.
And prefix means it will match any path that starts with slash and forward it to the cluster IP service.
The service name I'm pretty sure is great submission portal and the port number is 5001.
Let me just make sure.
Great submission portal 5001.
We are golden.
All right.
And that's pretty much it.
We've got our ingress controller.
We've got ingress rules that will forward any external traffic to our cluster IP service.
All right I think we're done.
Um I'll go ahead and say kubectl apply dash f.
Great submission portal ingress or we'll just.
Yeah.
Great submission portal slash.
Great submission portal ingress dot YAML.
Uh, there's something I forgot to specify.
That is the ingress class name.
We need to associate this ingress rule with the engine X ingress controller.
How did I get this class name?
You can just say cube CTL get ingress class engine x.
Okay, now let's reapply the ingress.
Okay.
Clear the output.
Um, everything should be fine.
I'm going to say cube ctl get services dash n great submission.
All right.
We still have a great submission portal node port.
That's no good.
Cube CTL delete.
Great submission portal service
And so I need to actually apply.
Um, I need to actually apply the great submission Portal cluster IP service, because ultimately that
is what's going to receive the traffic from our ingress controller.
So kubectl apply dash f great submission portal slash great submission portal service.
I should have just deployed everything in the folder.
Uh whatever okay let's check on that again.
All cluster IP services.
Beautiful.
No more node ports.
The last service we want to check on is the one that exposes a port 80 on our local host machine.
So kubectl get services dash n uh ingress engine x beautiful All right.
Beautiful.
Okay, so all that's happening is the ingress controller is using the ingress rules to determine where
to forward the external request.
The ingress rules.
We programmed to accept requests from any host and any request that starts with the path.
Slash forward that to the great Submission Portal cluster IP service, which is exactly what happened.
This same ingress rule should scale when we deploy things on AWS, because ultimately, whether the
request comes from great submission portal com example.com mangos com it accepts requests from any host.
And if the path begins with slash it'll forward it to the great Submission Portal cluster IP service,
which will forward the request to one of the pods.
All right.
And that's pretty much it.
I hope you enjoyed this lesson.