So we got our cluster and we are able
to use cube control with it.
One important thing is missing though.
We got the general cluster network and so on,
but the concrete worker nodes are missing.
And to add them, go to the compute section here
on your cluster and add a node group, click on,
Add node croup and give this node group a name,
for example, demo depth nodes.
But this name is totally up to you.
Next we need to add an IAM role.
And we did this earlier already, for the cluster
to define what the cluster may do on our behalf.
Now we need to do something similar again,
this time however, for the nodes,
because you have to keep in mind that the cluster needed
certain permissions to do some stuff behind the scenes,
the nodes, the worker nodes,
which are in the end EC2 instances
also need certain permissions.
For examples, so that they can write log files
or connect to certain over services,
which we might leverage in our code.
And therefore we need to attach an IAM role
to this node group and therefore to the EC2 instances,
the remote machines,
which will be launched in this node group.
Now the launching will happen automatically managed by AWS,
but we need to set up the permissions
these instances will have, and for this again,
open the IAM console in a new tab and create another role
here, select EC2 on common use cases
and click Next permissions.
And now here are a couple of permissions you need to add,
you should search for EKS here and then EKS worker
and add this EKS worker node policy,
which holds a couple of permissions worker nodes,
which is in the end, what we're going to start here, neat.
Also this CNI policy by searching for a CNI.
And add the ECQ container registry read only policy.
Now these are free policies with a bunch of permissions,
which allow these nodes, these EC2 instances,
which are part of our cluster to do various things,
which they need to do in order to pull images
and to run successfully.
Once you added these free policies,
click on Next tax and Next review,
make sure the free policies are there
and give this role a name like EKS node group,
something like this.
Once you debt click Create role.
And once that is done,
you can close that IAM console and then click
the Refresh button here in your cluster
node group configuration screen,
and then pick this newly created node group here.
With that done you can leave all the other defaults
and click Next.
Now on this page,
you control which kind of EC2 instances will be launched
and managed by AWS on your behalf.
You can keep the default image here
for the operating system,
but for the instance type I'm going to use t3 micro,
which is simply a cheaper instance,
actually make sure you use t3 small
as a minimum here, not micro.
Scheduling ports on micro can fail
and your application can end up
in a pending state, therefore.
So that's just an important node.
Make sure you use the small instance as a minimum value
here not micro, I picked micro here.
I ran into errors and changed it behind the scenes later.
So don't even go down that route, start with small.
The larger the instance here, the more powerful it is,
you can see the number of vertual CPU and memory here,
but of course the more it will cost.
So I will go for the cheapest one here, keep that default,
disc size, and then you can control your scaling policy.
Now, scaling is not something we will look into here,
but I'm happy with starting two nodes
and that's by the way important.
Now we're talking about nodes here.
Not ports, you can't have more than two ports,
but the nodes are just the physical machines
on which your ports run.
With mini cube, we had just one dummy node
in that virtual machine.
Now we have two actual nodes, two different computers,
different machines, so to say across which our ports
and containers will be distributed
automatically by Kubernetes.
that's the part Kubernetes will take care of.
It will start the ports, manage the ports
and distribute them across these nodes.
And the more nodes you have,
the more space you have for the ports to be distributed
so that if the ports on one node have a lot of work
at the moment, new ports could be started on another node.
But of course the more it will cost as well.
So I will go with two nodes here for this demo
and click Next.
Now the settings here should all be fine.
You can disable the remote access to nodes here,
if you want to and I will, then you will not be able
to connect to these nodes to the EC2 instances directly
with SSH, but that's fine for me
because I don't wanna connect anyways.
I wanna let EKS manage my nodes for me,
and therefore I will disable this enter, then click Next
again, we can have another look at all our settings here
and then click Create.
And this will now spin up a couple of EC2 instances
and add them to this cluster.
And of course it will not just launch these instances,
instead, EKS will also install all the Kubernetes software,
which is required like to cube LEDs and cube proxy
on these nodes.
And it will add them all to this cluster network
and do all the heavy lifting of wiring these things up.
And that's the part you would have
to do on your own manually, otherwise,
here, we just specify how many nodes we want
and they are launched and configured for us.
And we don't need to worry about that.
Now this will take a short while
until this is all up and running,
and therefore let's wait until this finished.
And then let's see if we can successfully deploy
our application here with these two Yamel files
onto this cluster.
Now, after a short while, couple of minutes,
this should be active.
Your node group should be active and you can, by the way,
go to the EC2 service page in a new tab, for example,
and you will see you're running EC2 instances here.
These are the instances which were created for us
automatically by EKS.
And that's what I meant when I said that EKS will work
together with other services,
AWS offers in order to bring your EKS cluster to life.
Here, for example, it launched EC2 instances,
through the EC2 service for us.
Whilst you're on that EC2 dashboard, by the way,
also have a look at load balancers,
and please node that you will not see any load balancers
here at the moment.
This will become important later.
So let's close this and go back to our cluster.
Now the cluster is up and running.
It has a network setup for it,
and it has nodes running in that network with all the
Kurbenetes tools installed on them.
And that is all we need to do.
with this our cluster is set up and now it's like mini cube,
just that it's not running in a virtual machine
on our local system,
but it now is a cluster to which we send commands
with the cube control command
just as we did it with mini cube.