We have now set up the notes required to set up a Cuban natus cluster.
We have set up a master node and two worker nodes, node zero one and not zero two.
Let us now proceed to the Canadian documentation page to install a corporate netas cluster.
We will start with the prerequisites.
So we must have a supported operating system like, for example, open to sixteen point two or four
or higher, which we already do.
That's what we did in the previous demo.
We have some hardware requirements to have at least two gibi of RAM to S.P. use and network connectivity
between the rearms, which we have already taken care of in the previous video.
Another thing is to make sure that our firewall and network security settings are in place.
Otherwise, the nodes will run into connectivity issues.
For this, we must let IP tables see breached traffic.
We must first make sure the B r underscore net filter module is loaded before the step.
So we can do that by running the command allez mode.
Grep b r underscore net filter.
So we see that it's not loaded as there is no result.
So we run the more probe command to load the kernel module.
We know execute that on all the notes.
Once that is done, we run this set of commands to create the new COL parameters.
We then do that on all the nodes.
The next step is to install container runtime on the notes.
We will be using Docker in this example for this.
We use the documentation link and click on Docker.
We will use these commands to install the latest table version of Docker.
These neat route privileges.
So I will switch to Suda to make the next steps easier by running the Suda dash.
I command.
I will now paste the command a copy to set up the software repositories.
We will then proceed to execute the same on all the three machines.
OK, so that's done.
The next step is to install Docker's official ZPG keys.
So we will do that.
Also on all the machines.
The next step is to add the Docker APTN repository.
We will then do the same on all the systems.
The next step is to install the DOCA runtime.
We run the commands to install the latest table version of Docker.
As of this recording.
If the version of Docker that is shown here has changed as you're watching this, then feel free to
follow the latest version of documentation to install the latest version of Dr..
Run that on all the notes.
This may take a few minutes, so wait for that to finish.
The next step is to set up the Dr. Damon.
For this, we create a Damon Dodd Jason file and then create a directory for the doctor service.
We then run the system a demon reload and restart Docker command to load and start the Docker service.
To verify Docker's installed, run the system, cuttle status, dockyard service command and verify
that it is running.
Confirmed that that's the case on all the three notes.
We now go back to the documentation page to proceed with the installation of cabernets components using
rubidium.
The next step is to install the cabinet is related packages such as the two BDM Cube led and cube cuddle
on all the notes.
The cube, the end tool is used to bootstrap the cluster cube.
That is the process that's responsible to manage pods and containers on the note.
And the Cube Cuttle utility is the components command line tool for this run the commands to update
repository and install the required packages.
Run these on all the notes and wait for it to finish.
The next section about configuring Seagram driver is not applicable when using Docker as QB, GM will
automatically detect the group driver for the Kubla.
If you're not using Docker, then we must follow the step to specify the secret driver so we can skip
this for now.
The next step is to configure the QB GM cluster by clicking on this link.
This takes us to the cluster creation process using cubie a.T.M.
The first phase is to initialize control plane node.
The first step in that is only applicable if we are deploying a highly available cluster.
In this demo, we are not.
We just have a single master node.
So we will skip that for now.
The next step is to choose a part network, add on.
And when we do that.
Decide what is network IP address range.
We are going to use for the port.
There are multiple network options available for networking between ports in a coronets cluster.
So if you click on this link, which takes you down in that page today, pertinent Roxette section,
you will see different options for configuring a network such as Kalikow, Psyllium Quantitive, Kue,
Browder, Veev, etc..
In this case, we will make use of Weev and we can choose a network range that does not conflict with
the network of the nodes.
Remember that we configure the nodes to be in the 190 to that 168 or 56 network.
We will use a network sider that's different from that range for parts.
We will use tender to 44 dot zero zero slash 16 network.
The third step can be ignored as well, since we are using Docker as our container runtime.
But in case you're using a different one, you may use this option to specify that the fourth step is
what we will configure.
We must specify the cabinet is API servers, IP address as the API server advertize address.
This is so that the API server listens on that on the correct static IP address.
We have set on the master node which will make the API server accessible to the worker nodes on any
other clients on that IP address.
Once we have decided the values for the options, we can proceed with initializing the cluster, using
the Cube Edman in its command.
We will run this on the master node.
Remember, this step must only be run on the master node because that's where all the cluster components
have to be installed and initialized.
We copy and paste the cube admin in his command on the master node.
We will then pass in all the required parameters such as the pod network spider, which will be tender
to 44 dodgier Arturo's last 16.
And the API server advertize address is going to be the static IP address of the master node.
Which will be one only to 168 dot fifty six dot two, which is the IP address of the master.
Now if you're not sure about the IP address of the matter node, we can double check that.
So I will for now comment this command so that it is not executed and that I can later access it African
from the IP address.
I will then run the I have conflict command to confirm the IP address of the node.
I can confirm that it is the correct IP address.
I will now run the cube idiom in its command.
It runs a set of pre-flight checks to make sure all prerequisites are in place.
So let's give it some time to run.
The checks are complete and everything looks good.
So we proceed with the creation of security certificates and installation of the various components.
We give it some more time for the insulation to finish.
Now the insulation is complete.
We will now perform the post installation tasks as the output states to start the cluster.
You need to run the following as a regular user.
So we have been running things as the route user.
So we will run the logout command to log out and become the regular user.
Once we are a regular user, we must create a directory under the user's home directly and copy the
admin dot com file.
The admin, not con file, has the necessary information and credentials required to access the cabinet
cluster using the Cube Cuttle command line utility.
It must be placed in the user's home directory under the DOT Cube directory.
So we are on this command to create the DOT Cube directory and copy the admin dot com file into it and
also set the right ownership on it.
The next step is to deploy a part network to the cluster.
Earlier, we decided that we will use Weev as our port network solution.
So we need to do that.
After the port network solution is set up, we will have the worker node's join the cluster using the
command given here.
Keep a out of the command that will be used to join the work.
Noticed the cluster.
I'm just going to copy and echo the command to my screen terminal so that it is available in the terminal
history and I can retrieve it later.
Or you may just copy it to an external text editor.
Let's run the Cucuta's get node's command to check the status of the cluster.
Now we see that the cluster consists of the cube master node only.
And the status is not ready.
As of now, the version is one point eighteen point three.
The reason is not ready is because we do not have a port network solution for this.
We go back to the documentation side and go to the port network section, select Weev and copy the command
to install.
We've.
Pasted on the master note and executed.
We see that the port network solution is being installed and all the required components are created.
It creates a service account.
Rolls, roll bindings, deman sets, etc..
We discuss a lot about each of these in these certified as administrator course.
We have a section just for networking where we go from the absolute basics of network all the way to
how a weave solution works.
So check that out.
If you have time for now, let's proceed with adding the worker nodes to the cluster.
For this, we use the command we saved earlier.
We will copy it and run it on both the worker notes.
We see that the node has successfully joined the cluster.
Now we are on the KUKA to get notes.
Command on the master note and we will check the status.
It may take a few minutes for the worker notes to be in a ready state.
So let's monitor that.
We now see that they are in a red state.
Our cabinet is cluster is now ready.
We can now test by creating some objects.
Let's create a pot using the cube cuttle run engine next command and specify the engine X image.
We see it's created a pod by running the tube to get pods command.
The parts are still being created.
So we wait for a few minutes and we will see that it's now in a running state.
We will not delete it using the Cucuta delete part command.
Well, that's it for this demo.
Thank you for watching.