@import "./support/support"; @import "./color_schemes/"; @import "./modules"; @import "./custom/custom";
Link
Sysadmin DeCal

Lab 11 - Kubernetes

Facilitator: kian

7 min read

Table of contents

  1. Overview
  2. Basic Concepts
  3. Resources
  4. Getting started with kind
    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

Overview

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?

Resources

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 kind

kind (Kubernetes in Docker) is a user-friendly way to run a single-node Kubernetes cluster locally on your computer. A popular alternative (and another valid way to complete this lab) is minikube which provides a variety of other ways to run a single-node Kubernetes cluster if you prefer to not use Docker. We chose to use kind in this guide because it supports IPv6 unlike minikube, and at the moment the VMs we provide are IPv6 only. Other popular Kubernetes distributions include k3s and microk8s, which are more feature-rich but more involved to set up compared to kind and minikube.

To begin, you can follow the official getting started guide for installation instructions (we recommend you install from release binaries).

Installation notes

  • Remember to run sudo usermod -aG docker $USER && newgrp docker if you’re getting Docker permissions issues.
  • If the kubectl command is not found, follow the instructions to install it.

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 && cd kubedoom.

Next, run kubectl apply -k manifest/ to create all the resources.

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. Port forward the service from your kind container by using kubectl port-forward service/kubedoom 5900 --address '127.0.0.1,::' -n kubedoom. This will allow you to access the service from either your VM at localhost:5900 or from outside with .decal.ocfhosted.com:5900.
  4. Try running telnet with telnet <username>.decal.ocfhosted.com 5900 on your local computer to make sure you can access it!
    • If you’re able to connect and it doesn’t disconnect you immediately, then it should be working (you can press control-] and then type quit to exit). Use <username>.decal.ocfhosted.com:5900 as your VNC address in the next step.
    • If you’re not able to connect, then you’ll probably have to port forward (run ssh <username>@<username>.decal.ocfhosted.com -J <username>@ssh.ocf.berkeley.edu -L 5900:localhost:5900 in another window) and then try telnet localhost 5900. If that works then use localhost:5900 as your VNC address in the next step.

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 use the address from the telnet step to connect. The password for the VNC connection is idbehold. If all goes well, you should see a window that looks like this!

kubedoom

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.

Helm

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 below:

$ helm repo add ocf https://decal.ocf.berkeley.edu/helm/
$ helm install mocktail ocf/mocktail

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.

Hints:

  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.

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 kind 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:

Questions

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?