Lab 10 - Kubernetes
Facilitator: njha, bencuan7 min read
- Basic Concepts
- Getting started with Minikube
- Creating your first deployment
- Choose your own adventure
This lab is designed to give you some hands-on experience with Kubernetes. By the end of this lab, you should be able to:
- Understand the basic components of a Kubernetes deployment, including pods, services, and ingresses
- Run your own simple Kubernetes deployment
Keep track of your answers to the questions, as you’ll need to submit them to Gradescope.
For your own future reference, answer the following conceptual questions on Gradescope:
Question 1a. In your own words, describe what Kubernetes is, and why it is useful (i.e. what problems it solves).
Question 1b. What are some similarities and differences between Kubernetes and Docker?
In addition to the standard “just Google it” procedure, you can find answers to your many Kubernetes-related questions in the following resources:
- Kubernetes documentation
- Kubernetes deployments
- njha’s kubernetes intro
- Actual OCF kubernetes deployment
- kubectl cheatsheet
Minikube is a user-friendly way to run a single-node Kubernetes cluster locally on your computer. Other popular Kubernetes distributions include k3s and microk8s, which are more feature-rich but more involved to set up compared to Minikube.
To begin, you can follow the official getting started guide for installation instructions. You should install this on your local computer, rather than your Linux VM!
- Installing Kubernetes can take a decent chunk of disk space. Make sure you have at least 20GB to spare!
- If you get errors starting your cluster, you might need to install a custom driver. The Docker driver seems to work well for most use cases where the default driver is broken. (Remember to run
sudo usermod -aG docker $USER && newgrp dockerif you use the Docker driver on Linux.)
- If the
kubectlcommand is not found, you can use
minikube kubectl --instead. For example, to view the config, you could run
minikube kubectl -- config view. You can run
alias kubectl='minikube kubectl --'if you get tired of typing this out every time.
Question 2a. What command can you run to get all pods in all namespaces?
Question 2b. What is the output of that command? (hint: “No resources found in default namespace.” is an incorrect answer- there should be something running if your install was successful)
For this first part, we’ll walk through how to set up a simple deployment of kubedoom using your new cluster.
First, you’ll want to fetch the source code:
git clone https://github.com/storax/kubedoom.
kubectl apply -k manifest/.
Once this completes, you should have one new deployment (
kubectl get deployments -A) and one new pod (
kubectl get pods -A). It may take a couple minutes for the pod to show as “ready”.
However, you still won’t be able to access this pod from the outside world! In order to do so, we’ll need to create a service and expose it:
kubectl expose deployment kubedoom -n kubedoom --type=NodePort --port=5900. This will take the deployment we just made in the namespace
kubedoom, and map it to a new service.
- If you now run
kubectl get svc -A, you should see a new service of type NodePort listed.
- Create a service tunnel using
minikube service kubedoom -n kubedoom --url. This should print out an IP address into the console. Note that this address is only resolvable from your local computer.
- Try pinging this IP address to make sure you can access it!
Further documentation on the process above can be found here.
Finally, let’s access our kubedoom instance. The pod is actually running a GUI application, which can be accessed using VNC. You can download your VNC viewer of choice (some popular choices include TigerVNC, TightVNC, and RealVNC), and paste in the IP address from above into your viewer. If all goes well, you should see a window that looks like this!
Question 3a. Upload a screenshot of your working Kubedoom instance. If you were unable to get it to work, describe your debugging journey instead, and where you got stuck.
Since many people have probably needed to deploy the same services that you’re hoping to deploy, chances are you’ll be able to find all the configurations you need online already! Helm is a package manager for Kubernetes, which makes it easy to find and manage these configs. Similarly to a package manager like
apt for Linux, Helm will automatically download and install whatever you want it to with a few commands.
You can install Helm using this guide.
Once you’ve got it installed, let’s create a basic mocktail deployment by following the instructions in the README. Specifically,
helm repo add and
helm install will be useful.
Although taking the default deployment from Helm will be enough in some cases, we might also want to change up the configuration. Fortunately, Helm lets us do this!
Your task: Figure out a way to modify Mocktail such that:
- It runs on its own namespace
- Its name is changed to
- There are a minimum of 3 Mocktail pods running at any time.
- Use the default
values.yamlfile provided by the Mocktail chart maintainers for reference.
- Here’s some documentation on values files:
- Best practices dictate that you should not specify a custom namespace in the values file. Can you modify the commands you run to get around this?
- You can specify the
--dry-runflag to debug without actually committing any changes.
- You may have to create a horizontal pod autoscaler.
Question 4a. If applicable, paste the
values.yaml file you created.
Question 4b. Paste the command(s) you ran to create your Helm deployment.
Question 4c. Paste the output of
kubectl get deployments -A showing that your custom namespace appears.
Question 4d. Paste the output of
kubectl get pods -A showing that you have 3
ocf-mocktail pods running.
At this point, you should hopefully have an idea of how to create deployments and modify them to suit your needs!
Now, we will provide the opportunity for you to find your own deployment(s) to create- you’re welcome to try whatever you find interesting.
Requirements: You should host a service on your Minikube cluster that is externally accessible on your computer through some means (whether that be a GUI like kubedoom, web client like mocktail, or CLI). Document the process you took to install and expose this service.
Some suggestions include but are not limited to:
- Run your own blog using Ghost
- Run your own wiki using Outline
- Run a Minecraft server
- Run kubeinvaders to stress-test your cluster
Question 5a. What did you choose to install?
Question 5b. Upload a screenshot of your working installation, or describe how/why you got stuck while trying to install it.
Question 5c. Document any steps you took and commands you ran to create this deployment.
Question 5d. What is one new thing you learned about Kubernetes, Linux, or system administration while creating this deployment?