Lesson 2 — Using your cluster
In this lesson, you'll begin to deploy a range of resources onto the cluster. As we are working with an air-gapped installation, there are limitations to what we can deploy. Regardless, we will still be able to cover important topics including:
- Services, networking and Monitoring
- Resource Management and Failure Recovery
- Persistent Storage
- Jobs and Batch Execution
Through this session you will see first-hand the benefits of using Kubernetes to manage high availability application deployments and how this relates to HPC environments.
We will learn the above topics through a series of example deployments. Before doing so, we need to explain a bit more about deployments and namespaces. For further details, you can refer to our most recent Kubechaos Workshop Lesson Material.
Deployments
Deployments are the bread-and-butter of Kubernetes applications.
A Deployment
defining the desired state of your application—which container images to run
and how many replica pods to keep running them—and Kubernetes continuously works to
reconcile the actual state of the cluster with that desired state. Deployments are
specified in a .yaml file known as a manifest and 'applied', i.e., deployed,
using kubectl apply -f <manifest.yaml>. Upon running this command, the Kubernetes API server triggers a sequence
of events leading to the Kubelet process on a node pulling the relevant container image
and starting up the pod(s).
Namespaces
As introduced in the previous session, namespaces provide a mechanism for isolating groups of resources within a cluster. They are commonly used to separate environments (e.g., dev, staging, production), teams, or applications. A namespace can be created using:
You can then target resources in these namespace by appending-n my-app to any
kubectl call. For example, to get pods running my-app:
Without creating specific namespaces, every deployment your group makes will
land in the default namespace, making it difficult to distinguish whose
resources and whose.
Warning
If you choose to work asynchronously on different exercises within your group, make sure to communicate to each other which namespaces and deployments you create.
For convenience, whilst working on a specific deployment
you can change the target namespace for all kubectl commands:
-n my-app with each call. Just remember to
change back the default namespace when you are finished!
Tip
You can check the current namespace targeted by kubectl commands by running kubectl config get-contexts (* indicates the current namespace)
Preparation: Additional Setup
The cluster will need access to our demo deployment manifests, which you can retrieve from the main repository branch:
Warning
If you are connected to our router, you will need to temporarily disconnect and use the venue Wifi in order to perform the clone. You can then connect back to our router.
For those running kubectl from the nodes over a SSH connection (instead of
from their own device; see Access The Cluster Directly From Your Laptop),
you will need to copy at least the resources subdirectory to the node that you are using. For example,
scp -r resources/ chef@kmaster:~/
ssh chef@kmaster
ls -l
---
total 12
drwxr-xr-x 2 chef chef 4096 May 13 04:57 resources
-rwxrwxr-x 1 chef chef 4880 May 10 02:04 setup-rpi-worker.sh
While a single person from the group could deploy all the manifests, we recommend sharing deployments between you so that everyone gets practice.
In the following we use RES_HOME for where you chose to store the resource folder (~/resources above).
Since the cluster is air-gapped, we can't simply retrieve container images from, e.g., Docker Hub. We've put a collection of basic images
to use in this tutorial in the archive /root/workshop-images.tar which can be
made accessible to Kubernetes on the nodes with the K3s command
Tip
For following along at home, or with regular Docker Hub images on an internet-enabled RPi cluster, you will need to change the manifests in the resources folder to directly pull the chosen image. For example, in ./resources/iperf3.yaml, one would replace image: workshop-tools:arm64 with image: networkstatic/iperf3, and in ./resources/cronjob.yaml, image:workshop-tools:arm64 would be replaced with image: bash.