Welcome back everybody.
By the end of this video we're going to set up a Kubernetes cluster on AWS.
We're going to have worker nodes where each one is an actual virtual machine that's running our container
workloads on the cloud.
We're going to have master nodes that orchestrate how, where and when these containers run.
We're going to have a load balancer.
So remember that a load balancer is simply a server that receives traffic from the outside and distributes
it, load balances it across our worker nodes.
Remember that if I go back to a previous diagram, uh, the ingress controller, your ingress is the
entry point of your cluster such that whenever you make requests to your load balancer, it eventually
ends up going to the ingress controller, which decides where to forward that traffic.
So the load balancer is what receives traffic from the outside, and the ingress is the entry point.
But let's go back here and look at the big picture.
We want to set up a Kubernetes cluster.
Okay.
We're tired of working on a single node cluster on our local machines.
We want to scale up, and AWS makes it very easy to set up Kubernetes clusters using its Elastic Kubernetes
service.
So before we start using that service to set up our cluster, um, you should be able to write this
command AWS Configure list, get a secret key, and get the access key for your IAM user that you've
created, the IAM user that ideally you've given administrative privileges.
That's really important, and you've set a region that is geographically close to wherever you are to
minimize latency and improve network performance.
So make sure that you've got all that set up.
You've got the access key not for the root user, but for the IAM user with administrative privileges.
Okay.
It's really important that you use the IAM user, not the root user.
If you haven't done that, please go back and follow the articles.
Okay.
If you've got all that set up, um, we're pretty much ready to set up our cluster.
So another thing I would have expected you to do is set up the ECS command line utility.
So we'll say CTL.
If you execute this you should be able to get some output.
All right.
So you've got your AWS command line configured.
You've got Eksctl set up.
Let's have some fun.
And we're going to create a cluster.
And the command by the way at this point it doesn't matter which directory you're in.
We're going to say eksctl create cluster.
Go figure.
All right.
The cluster name you can call it whatever the heck you want.
I'm just going to call it my cluster.
If you are working for some organization that cluster would typically be your organization name dash
region So my region is US East two.
Please choose the region that is geographically closest to you.
So if you go to AWS you can find the list of regions here.
Choose the one that makes the most sense for your location.
All right.
Mine is US East two.
And then we specify the node type.
All right.
So basically here you're specifying the resource what kind of resource requirements you want from your
worker nodes.
Okay.
I'm going to say T3 dot medium I'll go over some other options in a bit.
So T3 dot medium.
This has two virtual CPUs four gigabytes of memory.
It's very suitable for medium workloads application servers medium databases.
Uh below that is T3 dot small um two virtual CPUs here, two gigabytes of memory, also suitable for
medium workloads.
There is also T3 micro.
This one only has one gigabyte of memory.
Um, we'll probably end up using T3 medium for this course.
So above T3 medium is M5 large.
Um, you know what?
I'm not going to list them all.
You can go on the AWS documentation.
Uh, T3 medium should suit our purposes just fine.
Okay, so it's pretty cool that we can decide the resource requirements for our worker nodes, and then
we can decide how many worker nodes we want.
We can just say two worker nodes.
Let's just create two worker nodes in the cluster.
You might be wondering what about the master nodes?
The master nodes will already be managed and provisioned by AWS.
We don't have direct control over the number or the configuration of the master nodes, but we do have
control over how many worker nodes we want and their resource requirements, their configuration That's
enough to create a Kubernetes cluster on AWS.
And by virtue of executing this command, our kubectl command line, it's context is going to automatically
be set to our Kubernetes cluster on the cloud.
So it's going to ditch our Docker desktop Kubernetes cluster.
And it's going to start working with the Kubernetes cluster on AWS.
I can't wait to show you.
Let's just go ahead and execute this command.
This is going to take a really, really long time.
So what I'm going to do is see you in a bit.
All right.
My Kubernetes cluster was just created.
And now you can see that my kubectl context was switched to the cluster that I have on AWS.
Because upon saying kubectl get nodes, it showed me the two worker nodes that I have in US East two.
That's pretty darn cool.
And if you go to your AWS dashboard, so make sure that you're logged in as the IAM user that you created
in the articles.
If you forgot how to do that, go to IAM.
All right.
I'll just show you real quick.
Use the sign in URL and then sign in using your credentials.
Okay, I'm already signed in as the IAM user developer.
It's going to make me reload now.
Darn it.
Okay, whatever I got to show you at least.
All right, so I'm signed in.
So if I go to my elastic Kubernetes service.
You can see that I've got a cluster deployed on AWS.
Beautiful.
Now, if for some reason you don't get a cluster, but you very clearly have it deployed, this cluster
was deployed in US East two.
So you might have specified the wrong, um, region by mistake.
All right.
So if I say us East one, we're not going to see a cluster.
Our worker nodes are in US East two.
Our nodes that make up the Kubernetes cluster are in US East two.
Okay.
Pretty cool stuff.
Look how far we've gotten in this course.
All right.
Now I'm going to say kubectl config current context, just to show you that the context has been switched
such that our kubectl commands will now interact with our cluster in AWS.
Okay.
Anything else I wanted to show you?
Um, what I want to do is get you to copy the link.
I should be pointing here, I think.
Copy the link in your resources folder.
Sorry.
Not copy the link.
Copy the kubectl command in your resources folder because that kubectl command.
What it's going to do is deploy Nginx ingress controller on our cluster, and thereby orchestrate the
creation of a load balancer that allows us to make public requests to our cluster.
That's why we typically see that the ingress is the entry point of our cluster, because it works alongside
the load balancer to allow public requests to allow public traffic into our container workloads.
All right.
Now if I go ahead and say kubectl get namespaces, here are the namespaces that divide our Kubernetes
cluster on AWS into logical boundaries.
Here I'm going to say kubectl get services inside of ingress engine x.
R dash n.
Sorry guys it's so late again.
And this is the external IP that's going to allow us to make public requests to our cluster.
So we've got that set up.
The last thing I want to do is I'm only going to deploy the Great submission portal.
Okay.
We could deploy all of the other applications, but there's no point.
We're being charged for this.
Um, whether we deploy one or the other.
All we're doing is deploying a helm chart, which, as you've seen, is really, really easy.
So in the last section, we set up a helm package for the great submission portal.
If for some reason you skipped that section, you can just say helm package followed by a dot to create
a package that packages up all the configuration files for the Great Submission Portal application,
and then we can release the contents of that package into our Kubernetes cluster on AWS, into this
cluster.
Right over here, we can release its contents by saying great submission portal release.
That's going to be the name of our helm release.
And we can create a helm release from the Great Submission Portal package.
Namespaces.
Great submission not found.
Ah, I forgot about that.
So these templates are trying to deploy artifacts into a great submission namespace, but we don't have
such a namespace in our cluster.
So let's say kubectl create namespace.
Great submission.
Isn't it cool how seamlessly we can interact with the AWS cluster through our command line at very,
very minimal latency.
All right kubectl create namespace.
Great submission.
Now we can go ahead and install our helm release.
It already installed this one.
Even though this helm release failed to deploy any of these artifacts, it was still installed.
So we need to uninstall it.
Helm uninstall.
Great submission.
Portal release.
Reinstall it.
Wonderful.
All right.
Um, so make sure that you're logged in as the IAM user first and foremost.
Otherwise you're not going to be able to access or look at any of the resources in the cluster because
you need to be signed in to the IAM user that created the cluster.
Okay.
The one with administrative privileges.
If I go to resources here, we can actually view all the configurations that we've deployed.
So we've got the ingress engine X workload.
Let's go on.
Um deployments.
Great submission portal.
Um no stateful sets.
I'm not going to deploy the database.
Um, simply because we're paying money for this stuff.
Guys.
No sense prototyping anymore if you already know how it works.
All we did was deploy a helm release.
Okay, we can look at the cluster, look at the nodes.
Here are our two worker nodes.
Pretty cool.
The amount of things we can look at.
Remember that deployments.
They manage a replica set of pods.
We've only defined one pod replica, so we only see the following.
And all of this is being orchestrated by helm.
Pretty, pretty cool stuff, because the great Submission Portal app is the entry point of the great
submission platform.
It's the front end that browsers are going to interact with.
It has an ingress resource.
Okay, so the ingress resource for the Great Submission portal, it doesn't define a specific host,
which means it's going to map any URL request with any host.
That starts with the following path to the Great Submission Portal service.
Okay.
Which means if I make a request.
Moment of truth guys kubectl get services.
We need to get the load balancer dash n ingress engine x.
If I make a request to this URL that starts with the empty path slash, that's going to get redirected
to the great Submission portal cluster IP service.
So the ingress rule determines that that client request is going to get forwarded to this cluster IP
service, which will in turn forward it to one of the pod replicas As you saw, we only have one pod
replica here, but then that pod replica is going to process the request and send us back a response
to our browser.
Okay, you're probably like Ryan, just shut up and do it.
Let's do it so we can specify an empty path or not.
There you go.
All right.
I'm not going to deploy the API or Mongo because we're paying for these resources.
And I don't want you to pay too much money.
We probably just got charged like a couple cents right now, so don't worry too much about it.
I'm going to go ahead and say helm and install the great submission portal release.
So I guess one point that I really wanted to drive home is that the great submission portal is ultimately
the entry point of the great submission platform, and if we were to deploy the Great Submission API,
it already has all the configurations that it needs to interact with the cluster IP service.
So if we were to deploy the following helm releases, everything would work seamlessly.
All right That's the beautiful thing about Kubernetes is it's very portable in the sense that you only
have to define your configurations once, and you can scale them to any cluster that you want.
The great submission portal is already orchestrated to interact with the Great Submission API, and
the Great Submission API has already been orchestrated to interact with this MongoDB database.
All right.
You just have to define your configurations once and you can deploy them wherever you want.
That is one of the many benefits of using a Kubernetes cluster.
Because we're running everything on a cluster, it abstracts away all the underlying AWS infrastructure
details.
All right.
You don't have to worry about this platform or that platform.
Kubernetes runs the same regardless of the cloud provider that you're using.
Okay.
These configurations will scale to any Kubernetes cluster on any cloud provider that you use.
Now enough talking.
Let's finalize this entire course by deleting our Kubernetes cluster.
We don't want to keep getting charged to run nodes that we're not going to use.
So we're going to once again leverage the Eksctl command.
We're going to delete the cluster that's named whatever you called your cluster.
My cluster.
All right.
As this is happening, I just want to say that I hope you enjoyed this course.
When I first created this course, I had a vision of, hey, can I take someone from not knowing any
Kubernetes at all to eventually deploy their container workloads on the cloud?
And if you were able to benefit from this type of curriculum, then I would really appreciate it if
you were to leave me a review at the end of this course to be very transparent.
Reviews helped me a lot in getting discovered as an instructor, so if you'd be kind enough to leave
one, if this course benefited you, I would really, really appreciate it.
Thank you so much for trusting me with your education, and I hope I get to see you again