DistOS 2021F Experience 1 - Revision history

Soma at 20:57, 30 September 2021

2021-09-30T20:57:05Z

← Older revision		Revision as of 20:57, 30 September 2021
Line 1:		Line 1:
	This experience is due November 2, 2021		This experience is due '''November 2, 2021'''.

	= Introduction =		= Introduction =

Soma at 20:56, 30 September 2021

2021-09-30T20:56:55Z

← Older revision		Revision as of 20:56, 30 September 2021
Line 1:		Line 1:
			This experience is due November 2, 2021

	= Introduction =		= Introduction =

Housedhorse at 17:50, 26 September 2021

2021-09-26T17:50:01Z

Show changes

Soma at 17:37, 26 September 2021

2021-09-26T17:37:55Z

← Older revision		Revision as of 17:37, 26 September 2021
Line 1:		Line 1:
	Getting Started with Kubernetes =		= Getting Started with Kubernetes =

	In this implementation experience, you will be configuring and deploying a simple “hello world” Kubernetes cluster using <code>minikube</code>. While your cluster is not yet truly “distributed”, it behaves just as a real Kubernetes cluster would. For more information on Kubernetes configuration, you may wish to consult the [https://kubernetes.io/docs/concepts/ official documentation]. Links to specific documentation items will also be provided as hints later on in this document.		In this implementation experience, you will be configuring and deploying a simple “hello world” Kubernetes cluster using <code>minikube</code>. While your cluster is not yet truly “distributed”, it behaves just as a real Kubernetes cluster would. For more information on Kubernetes configuration, you may wish to consult the [https://kubernetes.io/docs/concepts/ official documentation]. Links to specific documentation items will also be provided as hints later on in this document.

Soma at 17:37, 26 September 2021

2021-09-26T17:37:39Z

← Older revision		Revision as of 17:37, 26 September 2021
Line 1:		Line 1:
	~~= COMP4000 Implementation Experience 1:~~ Getting Started with Kubernetes =		Getting Started with Kubernetes =

	In this implementation experience, you will be configuring and deploying a simple “hello world” Kubernetes cluster using <code>minikube</code>. While your cluster is not yet truly “distributed”, it behaves just as a real Kubernetes cluster would. For more information on Kubernetes configuration, you may wish to consult the [https://kubernetes.io/docs/concepts/ official documentation]. Links to specific documentation items will also be provided as hints later on in this document.		In this implementation experience, you will be configuring and deploying a simple “hello world” Kubernetes cluster using <code>minikube</code>. While your cluster is not yet truly “distributed”, it behaves just as a real Kubernetes cluster would. For more information on Kubernetes configuration, you may wish to consult the [https://kubernetes.io/docs/concepts/ official documentation]. Links to specific documentation items will also be provided as hints later on in this document.

Soma: /* Receiving Your Grade */

2021-09-26T17:36:37Z

Receiving Your Grade

← Older revision		Revision as of 17:36, 26 September 2021
Line 19:		Line 19:
	# An opportunity to reflect on your experiences with Kubernetes and make connections to overall themes in the course.		# An opportunity to reflect on your experiences with Kubernetes and make connections to overall themes in the course.

	Students are expected to complete Part 1 and Part 3 to get a grade of at most B. Part 2 is optional, but must be completed to receive a grade of A- or higher. Marks will be deducted for insufficient explanations or answers that demonstrate a lack of effort. By this logic, you should have a fairly clear idea of what grade you will receive when you submit this experience, based on how much effort you put in.		Students are expected to complete Part 1 and Part 3 to get a grade of at most a B+. Part 2 is optional, but must be completed to receive a grade of A- or higher. Marks will be deducted for insufficient explanations or answers that demonstrate a lack of effort. By this logic, you should have a fairly clear idea of what grade you will receive when you submit this experience, based on how much effort you put in.

	== Getting Started ==		== Getting Started ==

Housedhorse at 17:34, 26 September 2021

2021-09-26T17:34:58Z

← Older revision		Revision as of 17:34, 26 September 2021
Line 50:		Line 50:
	<li><p>The simple web server running behind our <code>NodePort</code> service exposes a convenient end point called <code>/crashme</code> that bricks the server. Try calling this end point several times like <code>for i in $(seq 1 20); do curl <IP address here>/crashme; done</code>, then try interacting with the servers after a few moments.</p>		<li><p>The simple web server running behind our <code>NodePort</code> service exposes a convenient end point called <code>/crashme</code> that bricks the server. Try calling this end point several times like <code>for i in $(seq 1 20); do curl <IP address here>/crashme; done</code>, then try interacting with the servers after a few moments.</p>
	<p>Repeat the same experiment, but this time run <code>kubectl get pods -w</code> in another terminal to watch the status of your pods in real time. What do you think is happening? Try to come up with an explanation for the behaviour you see.</p></li>		<p>Repeat the same experiment, but this time run <code>kubectl get pods -w</code> in another terminal to watch the status of your pods in real time. What do you think is happening? Try to come up with an explanation for the behaviour you see.</p></li>
	<li><p>Another end point <code>/count</code> returns a count of how many GET requests the server has processed. Try spamming our <code>NodePort</code> with requests to <code>/count</code> like <code>for i in $(seq 1 ~~10000~~); do curl <IP address here>/count; done</code>. What do you notice about the count for each server? Try to explain what you see.</p>		<li><p>Another end point <code>/count</code> returns a count of how many GET requests the server has processed. Try spamming our <code>NodePort</code> with requests to <code>/count</code> like <code>for i in $(seq 1 4000); do curl <IP address here>/count; done</code>. What do you notice about the count for each server? Try to explain what you see.</p>
	<p>Hint: Think all the way back to the second question.</p></li>		<p>Hint: Think all the way back to the second question.</p></li>
	<li><p>Try scaling up the replication count of <code>comp4000server</code>. You can do this using <code>kubectl scale deployment comp4000server --replicas <n></code> where <code><n></code> is a number of your choosing. Try this a few different times with different numbers and examine the output of <code>kubectl get pods</code> each time. You might also want to try repeating some of the earlier exercises with your newly scaled deployment.</p></li></ol>		<li><p>Try scaling up the replication count of <code>comp4000server</code>. You can do this using <code>kubectl scale deployment comp4000server --replicas <n></code> where <code><n></code> is a number of your choosing. Try this a few different times with different numbers and examine the output of <code>kubectl get pods</code> each time. You might also want to try repeating some of the earlier exercises with your newly scaled deployment.</p></li></ol>

Housedhorse: Add link to deployment manifest

2021-09-26T17:28:31Z

Add link to deployment manifest

← Older revision		Revision as of 17:28, 26 September 2021
Line 28:		Line 28:
	# If you haven’t already, '''change your password''' with the <code>passwd</code> command.		# If you haven’t already, '''change your password''' with the <code>passwd</code> command.
	# Set up a simple minikube cluster using <code>minikube start</code>. After running this command, you should see some information printed to your terminal as minikube sets up your environment. Let the command run to completion.		# Set up a simple minikube cluster using <code>minikube start</code>. After running this command, you should see some information printed to your terminal as minikube sets up your environment. Let the command run to completion.
			# Download the <code>deployment.yml</code> file to your VM using <code>wget https://homeostasis.scs.carleton.ca/~soma/distos/2021f/experiences/deployment.yml</code>.
	# Deploy the experience 1 configuration by running <code>kubectl apply -f deployment.yml</code>. This should download some container images and create the necessary Kubernetes API objects to run our simple “distributed” application.		# Deploy the experience 1 configuration by running <code>kubectl apply -f deployment.yml</code>. This should download some container images and create the necessary Kubernetes API objects to run our simple “distributed” application.

Housedhorse: Created page with "= COMP4000 Implementation Experience 1: Getting Started with Kubernetes = In this implementation experience, you will be configuring and deploying a simple “hello world”..."

2021-09-26T17:24:37Z

Created page with "= COMP4000 Implementation Experience 1: Getting Started with Kubernetes = In this implementation experience, you will be configuring and deploying a simple “hello world”..."

New page

= COMP4000 Implementation Experience 1: Getting Started with Kubernetes =

In this implementation experience, you will be configuring and deploying a simple “hello world” Kubernetes cluster using <code>minikube</code>. While your cluster is not yet truly “distributed”, it behaves just as a real Kubernetes cluster would. For more information on Kubernetes configuration, you may wish to consult the [https://kubernetes.io/docs/concepts/ official documentation]. Links to specific documentation items will also be provided as hints later on in this document.

With the exception of Part 2, completing this experience shouldn’t take more than a couple of hours. Feel free to collaborate with other students if you get stuck. However, '''you must acknowledge any collaboration'''. Additionally, '''copying and pasting or simply “changing up” each other’s answers will be treated as an academic integrity violation'''.

== Submissions ==

Your experience report should be submitted as a PDF file on Brightspace, written in '''paragraph form'''. Code snippets or screen shots are allowed to augment your prose but are not required. We will post a submission link on Brightspace within the next few days.

The experience report is '''due on November 2nd, 2021'''. However, it may be a good idea to get started as quickly as possible, especially if you plan on doing an implementation-focused final project.

== Receiving Your Grade ==

This experience is broken up into three parts:

# A series of easy tasks designed to get you familiar with setting up a simple Kubernetes cluster.
# A harder challenge that involves you deploying your own image in your cluster to interact with a simple API.
# An opportunity to reflect on your experiences with Kubernetes and make connections to overall themes in the course.

Students are expected to complete Part 1 and Part 3 to get a grade of at most B. Part 2 is optional, but must be completed to receive a grade of A- or higher. Marks will be deducted for insufficient explanations or answers that demonstrate a lack of effort. By this logic, you should have a fairly clear idea of what grade you will receive when you submit this experience, based on how much effort you put in.

== Getting Started ==

To get started, you will need to run a few commands on your OpenStack course VM to set up the environment. If you are not yet on OpenStack, please get set up as quickly as possible. We have a [https://homeostasis.scs.carleton.ca/wiki/index.php/DistOS_2021F:_Using_Openstack detailed setup guide available] if you need assistance.

# SSH into your VM using your preferred SSH client. Remember that your username and password are both <code>student</code> by default.
# If you haven’t already, '''change your password''' with the <code>passwd</code> command.
# Set up a simple minikube cluster using <code>minikube start</code>. After running this command, you should see some information printed to your terminal as minikube sets up your environment. Let the command run to completion.
# Deploy the experience 1 configuration by running <code>kubectl apply -f deployment.yml</code>. This should download some container images and create the necessary Kubernetes API objects to run our simple “distributed” application.

== Part 1 (Easy) ==

Follow the instructions for each of the following numbered tasks. Make an effort to answer the accompanying questions, but more importantly please note down all of your observations and describe what you did for each task. You should also feel free to write down whatever questions you may have about a given task.

To achieve the best possible grade in this section, you must demonstrate that you have made an effort to understand the results of each task. (Note that an effort does not strictly mean a full understanding; it is okay to have questions!)

<ol style="list-style-type: decimal;">
<li>Kubernetes deploys Linux containers as “Pods”, which form an even higher-level abstraction around the container itself. In addition to Pods, Kubernetes supports several other API objects that abstract over various distributed systems concepts. The simple deployment you have installed uses a few of these API objects.
Using <code>kubectl get <object type></code>, <code>kubectl explain <object type></code>, and <code>kubectl describe <object name></code>, identify at least three different kinds of API object that are used in our deployment and briefly describe what they do. You can refer to <code>kubectl --help</code> as needed to explain what these commands do.
Hint 1: Some resources are encapsulated by multiple layers of abstraction. Each “layer” counts as a unique type of object for the purposes of this question.
Hint 2: The command <code>kubectl api-resources</code> will enumerate a full list of all supported API objects. You may also wish to consult [https://kubernetes.io/docs/concepts/workloads/pods/ the relevant documentation] if you are stuck.
Hint 3: You may want to have a look at the contents of the <code>deployment.yml</code> file.</li>
<li>Run <code>kubectl get pods</code> to see a list of the pods that are running in your cluster. You should notice several <code>comp4000server</code> pods and one <code>comp4000client</code> pod. Spawn an interactive shell into the <code>comp4000client</code> pod using <code>kubectl exec comp4000client -it -- /bin/sh</code>. Examine the layout of your container’s filesystem. What files and directories exist? Do you think these files exist on your VM or somewhere else? What commands can you run?
Hint: Try running <code>cd ..</code> to leave the empty <code>/client</code> directory.</li>
<li>Our cluster exposes the <code>comp4000server</code> pods using a <code>NodePort</code> service. To find its IP address, start by spawning another terminal by starting another SSH session. (You should probably have ''at least'' two terminals open for the rest of this experience.) In your second terminal, run <code>kubectl get services</code> and copy the <code>CLUSTER-IP</code> next to the <code>NodePort</code> service.
From inside your <code>comp4000client</code> container, use <code>curl <IP address here></code> to send a GET request to the <code>NodePort</code> service. Repeat the same command a few different times. What do you notice about the output? Explain.
Hint: Try running <code>kubectl get pods</code> again to refresh your memory about the topology of our cluster.</li>
<li>The simple web server running behind our <code>NodePort</code> service exposes a convenient end point called <code>/crashme</code> that bricks the server. Try calling this end point several times like <code>for i in $(seq 1 20); do curl <IP address here>/crashme; done</code>, then try interacting with the servers after a few moments.
Repeat the same experiment, but this time run <code>kubectl get pods -w</code> in another terminal to watch the status of your pods in real time. What do you think is happening? Try to come up with an explanation for the behaviour you see.</li>
<li>Another end point <code>/count</code> returns a count of how many GET requests the server has processed. Try spamming our <code>NodePort</code> with requests to <code>/count</code> like <code>for i in $(seq 1 10000); do curl <IP address here>/count; done</code>. What do you notice about the count for each server? Try to explain what you see.
Hint: Think all the way back to the second question.</li>
<li>Try scaling up the replication count of <code>comp4000server</code>. You can do this using <code>kubectl scale deployment comp4000server --replicas <n></code> where <code><n></code> is a number of your choosing. Try this a few different times with different numbers and examine the output of <code>kubectl get pods</code> each time. You might also want to try repeating some of the earlier exercises with your newly scaled deployment.</li></ol>

== Part 2: Deploying a Custom Container Image (Hard) ==

The simple web server for this experience has one last end point: <code>/printerfacts</code>. Making an HTTP GET request to this end point returns some totally non-suspicious facts about printers. Your task is to write a simple client application (in any language of your choosing) to consume the <code>printerfacts</code> API in some way. Feel free to be as creative as you like.

Once you have written your application, containerize it and deploy it to your cluster in any way you see fit. For example, you may wish to replicate it, make it stateful (e.g. persist a simple database), or expose it to the outside world using a <code>LoadBalancer</code> service.

Tell us about what you did and how you did it. In particular, we want to hear about the parts you had difficulty with, any ideas you had that didn’t pan out, what ended up working, and how your deployment fits together with the rest of the cluster.

Points for this question will be awarded based on:

<ol style="list-style-type: lower-alpha;">
<li>The sophistication of your deployment. (Challenge yourself!)</li>
<li>The quality of your explanation.</li></ol>

Here are some hints to help you get started:

<ol style="list-style-type: lower-alpha;">
<li>When you are creating your container image, you need to take extra care to ensure Kubernetes uses your local image. To do this, run <code>eval $(minikube docker-env)</code> before running any <code>docker</code> commands in your shell. In your <code>deployment.yml</code>, set <code>imagePullPolicy: Never</code> under the <code>container</code> field to force it to use your local image.</li>
<li>You can create a new container image by writing a Dockerfile for it and running <code>docker build -t <name> .</code> to build it.</li>
<li>You can modify the <code>deployment.yml</code> file to create your API object, then re-deploy it by running the same <code>kubectl apply -f</code> command from earlier. Feel free to copy-paste and/or modify any of the existing configuration.</li></ol>

== Part 3: Reflection ==

Summarize your experience with Kubernetes in a few paragraphs (both the good and the bad). What concepts do you see reflected here from the research papers we have read thus far? After having some hands on experience with a distributed system technology, have any of your opinions or initial assumptions changed? Feel free to list any other thoughts you have.

== Acknowledgements ==

The idea for the printerfacts API comes from Christine Dodrill’s [https://christine.website/blog/dev-printerfact-2021-04-17 wonderful blog post].