@import "./support/support"; @import "./color_schemes/"; @import "./modules"; @import "./custom/custom";

Lab 10 - Kubernetes

Facilitator: njha, bencuan

7 min read

Table of contents

  1. Overview
  2. Basic Concepts
  3. Resources
  4. Getting started with Minikube
    1. Installation notes
    2. Confirm successful install
  5. Creating your first deployment
  6. Helm
    1. Extending Helm deployments
  7. Choose your own adventure
    1. Questions


NOTE: This lab is completely optional. Completing it before the late lab deadline will count as an additional completed, on-time lab (so please try it out if you weren’t able to finish a previous lab)!

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.

Basic Concepts

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:

Getting started with Minikube

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!

Installation notes

  • 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 docker if you use the Docker driver on Linux.)
  • If the kubectl command 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.

Confirm successful install

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)

Creating your first deployment

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.

Next, run 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:

  1. Run 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.
  2. If you now run kubectl get svc -A, you should see a new service of type NodePort listed.
  3. 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.
  4. 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.

Extending Helm deployments

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 mocktail-space,
  • Its name is changed to ocf-mocktail,
  • There are a minimum of 3 Mocktail pods running at any time.


  1. Use the default values.yaml file provided by the Mocktail chart maintainers for reference.
  2. Here’s some documentation on values files:
  3. 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?
  4. You can specify the --dry-run flag to debug without actually committing any changes.
  5. 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.

Choose your own adventure

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:


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?