[No Audio]
And we are back to GCP dashboard. We are still
running on our credits, our bill is still 0, so
we are quite safe on that front, let's go to the
navigation menu, or the hamburger icon or the
3 horizontal lines on the top left corner of
our dashboard. Scroll down to the Kubernetes
Engine and click on the Clusters. We don't have
any clusters created yet. So we are having this
screen, it is giving us a few options.
Take a quick start, deploy a container directly, or create
cluster. The most friendly looking one seems to be
Create cluster, so let's go for it.
Just like VM instances, GCP is prompting us to define some of
the specifications of our cluster.
But before that, let's see what do we have under cluster
templates. We have Standard cluster, CPU intensive
application cluster, Memory intensive cluster,
GPU accelerated cluster, and Highly available
cluster. All of these are useful for different
applications. But we will stick to Standard cluster.
The default given name is standard-cluster-1,
but that's too cliche. Let's name it something else.
Call it k8s which stands for
Kubernetes cluster. Next choice is Location type,
we can have either a Zonal or a Regional cluster,
which means, do you want to spread out your cluster
across different zones of a region, or do you want
to spread out your cluster across different
regions themselves? The choice of location type is
permanent. For higher reliability, Regional might
be the better choice. But we are not opting for
such performance intensive applications at the
moment, so we'll just run with zonal.
Let's choose our zone, you can choose any zone you prefer.
We'll pick europe-north1-a, next is Master version.
This means the Kubernetes version, which
will be running on the master instance.
The default is 1.9.7 or gke.6 and we will
keep it at that. Now let's define our node pool,
which means the number of nodes and their machine types.
We are creating a three node cluster and
all of these nodes will help Container Optimized OS
or cos install on them.
We are using machines with one virtual CPU and 3.75
gigs of memory and our boot disk size is 10 GB per node.
We have enabled auto repairing to avoid
any potential failures and our service account is
Compute Engine default service account.
Let's allow full access to all of the Coud APIs.
We can also provide metadata to our cluster, like
label and taint, but that feature is under beta
right now. So let's skip it and click on Save.
Finally, let's click Create.
And here we are, our cluster is created. We have the name of the
cluster which is k8s cluster, our zonal location,
which is europe-north1-a, amount of nodes or
cluster size, which is 3, total number of
cores which is 3 vCPUs, because each of the
node has 1 vCPU, and total memory, which is 11.25 gigs,
because each of the nodes has three
point 75 gigs of memory, we can look at the
description of this cluster by clicking on the name of it.
Starting from the top, we have Master
version, which is the default one, endpoint for
this particular cluster and some other
information such as Pod address, range, and
and the affirmation of Stackdriver Logging and Monitoring.
Below that we also have Node Pool specs, which are
pretty much what we had provided.
Let's go to storage section. Well, this is not about the
storage disk size of nodes. It is about the
storage objects within the cluster. Since we
haven't done anything to the cluster. Both of the
fields of persistent volumes and storage classes
don't have any special entries. And if you notice
closely, there is a storage class called standard.
Which provisions Google Compute Engine Standard
persistent dis will use the storage class in
future to provision some persistent volumes.
Finally, let's go to Nodes section.
These are the details of all three nodes of our cluster.
These long and complicated names are the names of VMs
which are used to create the cluster.
All of their status is Ready.
Next up, we have requested and allocatable CPU size, while the
requested CPU sizes are different, allocatable size
is common which is 940 mCPU, which means more
or less 1 vCPU. Next up, we have requested
memory and allocatable memory. 2.7 gigs are
allocatable whereas we had provided 3.7 gigs.
So what about the rest of the memory? Well, you can
comprehend allocatable memory as user space memory
of all of these virtual machines, which means
remaining 1 gigabyte will be used by the kernel
space of these machines. Till now we haven't
requested or allocated any storage yet.
It seems like we know our cluster better than before.
In next lecture, we will navigate to the cluster
and play around with it a bit.