The cluster has now been initialised. The Master node will manage the cluster, while our one worker node will run our container workloads.

Task

To manage the Kubernetes cluster, the client configuration and certificates are required. This configuration is created when kubeadm initialises the cluster. The command copies the configuration to the users home directory and sets the environment variable for use with the CLI.

sudo cp /etc/kubernetes/admin.conf $HOME/
sudo chown $(id -u):$(id -g) $HOME/admin.conf
export KUBECONFIG=$HOME/admin.conf

The Kubernetes CLI, known as kubectl, can now use the configuration to access the cluster. For example, the command below will return the two nodes in our cluster.

kubectl get nodes

We can verify the Container Runtime used by describing the node.

kubectl describe node master01 | grep "Container Runtime Version:"

In this scenario a single node has been provisioned. Remove the taint to deploy applications to the Master node.

kubectl taint nodes --all node-role.kubernetes.io/master-

Kubernetes has abstract away the underlying Container runtime meaning the commands behave as expected.

kubectl get pods --all-namespaces

The Container Network Interface (CNI) defines how the different nodes and their workloads should communicate. There are multiple network providers available, some are listed here.

Task

In this scenario we'll use WeaveWorks. The deployment definition can be viewed at cat /opt/weave-kube

This can be deployed using kubectl apply.

kubectl apply -f /opt/weave-kube

Weave will now deploy as a series of Pods on the cluster. The status of this can be viewed using the command kubectl get pod -n kube-system

When installing Weave on your cluster, visit https://www.weave.works/docs/net/latest/kube-addon/ for details.

The state of the two nodes in the cluster should now be Ready. This means that our deployments can be scheduled and launched.

Using Kubectl, it's possible to deploy pods. Commands are always issued for the Master with each node only responsible for executing the workloads.

The command below create a Pod based on the Docker Image katacoda/docker-http-server.

kubectl run http --image=katacoda/docker-http-server:latest --replicas=1

The status of the Pod creation can be viewed using kubectl get pods

You will notice this is ImageInspectError. This is expected. This is because all images need to be prefixed with the Container Image Registry, such as docker.io for the Docker Hub.

Fix the problem by chaging the image to include the Registry URL.

kubectl set image deployment/http http=docker.io/katacoda/docker-http-server:latest

Because we Tainted the master, once running, you can see the Container running on the master node.

crictl ps | grep docker-http-server

Kubernetes has a web-based dashboard UI giving visibility into the Kubernetes cluster.

Task

Deploy the dashboard yaml with the command kubectl apply -f dashboard.yaml

The dashboard is deployed into the kube-system namespace. View the status of the deployment with kubectl get pods -n kube-system

When the dashboard was deployed, it was assigned a NodePort of 30000. This makes the dashboard available to outside of the cluster and viewable at https://[[HOST_SUBDOMAIN]]-30000-[[KATACODA_HOST]].environments.katacoda.com/

For your cluster, the dashboard yaml definition can be downloaded from https://raw.githubusercontent.com/kubernetes/dashboard/master/src/deploy/recommended/kubernetes-dashboard.yaml.