In last lecture, we had created this cluster on GKE
or Google Kubernetes Engine. This time, let's
connect to it, let's navigate to it. The most
intuitive option seems like pressing that Connect button.
Let's do it.
When we click on Connect,
Google prompts us a command to run in Cloud Shell.
Cloud Shell is a CLI shell provided by Google to
perform all sorts of commands. You can define
Cloud Shell as an SSH access to a VM, which
already has gcloud command line set up for us.
Without further delay, let's click on run in Cloud Shell.
And our Cloud Shell has opened.
Let's resize it a bit while it's connecting to make it look prettier.
And there we go, Google welcomes us to our Cloud Shell,
and they are friendly enough to print that command on terminal as well.
All we have to do is press enter. But before we do that,
let's try to comprehend this command.
It says that we are getting credentials of a cluster
named k8s-cluster, from project rapid-being-218812
on europe-north1-a zone. In a nutshell,
it is giving access to our k8s-cluster to the
VM, which is hosting the Cloud Shell, there we go.
Now, we should be able to run kubectl command line.
Let's run kubectl get nodes.
Depending on your network connectivity, the zone or region
which you have chosen, or the load on Google Cloud
itself, the speed of operation may vary a bit.
But you will definitely get the fruitful results.
And here we go, here's the list of all of these three
nodes, which we had seen in previous lecture as well.
It looks more or less like output of the
cluster which we had bootstrap by ourselves.
But there is a little difference.
Check out the ROLES column. None of the nodes have master role, why is that?
Well, we have not bootstrap this cluster.
We have just provision it, Google has bootstrapped it,
and it is allowing us to use it as a hosted
Kubernetes or managed Kubernetes cluster. So the
master is managed by Google. What is the IP
address of Master, what is the VM name of Master,
what is the size of Master, what is the
architecture of Master, we know nothing about it.
All we know is it is learning Kubernetes version 1.9.7.
Because we had said so, while creating the cluster.
This doesn't just add
another layer of reliability and security,
but also saves us from handling the taints of master
which blocks pods from being scheduled on it.
Let's run kubectl get pods.
And as expected,
no resources found. Moving further, let's have pods
from all namespaces. And here we get a long list
again, but this time, the pods are not the same.
All of these pods are on Node instances. And none
of the Master's pods are available here.
Can you find kube-apiserver or kube-controllermanager
or even kube-scheduler, none of them are here, because
Master is completely out of access. Instead, what
we do have is kube-proxy for all of our nodes,
preconfigured kubernetes-dashboard, dns, fluentd as
the pod network, and heapster for monitoring our
Kubernetes cluster. It feels like an entirely
different cluster from what we had bootstrap by
ourselves, which it is on the backend at least.
But on frontend, we'll be using kubectl command
line just the way we use on our previous cluster.
So no worries there. In next lecture,
we'll create an application on this GKE cluster.