site: Kubernetes 101 tutorial

site/content/en/docs/tutorials/kubernetes_101/_index.md

@@ -0,0 +1,6 @@
+---
+title: "Kubernetes 101"
+weight: -1
+description: >     
+  Tutorial showing how to deploy, explore, expose, scale, and update your applications
+--- 

site/content/en/docs/tutorials/kubernetes_101/module1.md

@@ -0,0 +1,53 @@
+---
+title: "Module 1 - Create a Kubernetes Cluster"
+weight: 1
+--- 
+
+**Difficulty**: Beginner
+**Estimated Time:** 10 minutes
+
+The goal of this scenario is to deploy a local development Kubernetes cluster using minikube
+
+## Step 1 - Cluster up and running
+
+If you haven't already, first [install minikube]({{< ref "/docs/start" >}}). Check that it is properly installed, by running the *minikube version* command:
+
+```shell
+minikube version
+```
+
+Once minikube is installed, start the cluster, by running the *minikube start* command:
+
+```shell
+minikube start
+```
+
+Great! You now have a runnning Kubernetes cluster in your terminal. minikube started a virtual environment for you, and a Kubernetes cluster is now running in that environment.
+
+## Step 2 - Cluster version
+
+To interact with Kubernetes during this bootcamp we'll use the command line interface, kubectl. We'll explain kubectl in detail in the next modules, but for now, we're just going to look at some cluster information. To check if kubectl is installed you can run the *kubectl version* command:
+
+```shell
+kubectl version
+```
+
+OK, kubectl is configured and we can see both the version of the client and as well as the server. The client version is the kubectl version; the server version is the Kubernetes version installed on the master. You can also see details about the build.
+
+## Step 3 - Cluster details
+
+Let's view the cluster details. We'll do that by running *kubectl cluster-info*:
+
+```shell
+kubectl cluster-info
+```
+
+During this tutorial, we'll be focusing on the command line for deploying and exploring our application. To view the nodes in the cluster, run the *kubectl get nodes* command:
+
+```shell
+kubectl get nodes
+```
+
+This command shows all nodes that can be used to host our applications. Now we have only one node, and we can see that its status it ready (it is ready to accept applications for deployment).
+
+{{% button link="/docs/tutorials/kubernetes_101/module2" %}}

site/content/en/docs/tutorials/kubernetes_101/module2.md

@@ -0,0 +1,93 @@
+---
+title: "Module 2 - Deploy an app"                  
+weight: 2
+--- 
+
+**Difficulty**: Beginner
+**Estimated Time:** 10 minutes
+
+The goal of this scenario is to help you deploy your first app on Kubernetes using kubectl. You will learn the basics about kubectl cli and how to interact with your application.
+
+## Step 1 - kubectl basics
+
+Type kubectl in the terminal to see its usage. The common format of a kubectl command is: kubectl action resource. This performs the specified action (like create, describe) on the specified resource (like node, container). You can use `--help` after the command to get additional info about possible parameters (`kubectl get nodes --help`).
+
+Check the kubectl is configured to talk to your cluster, by running the `kubectl version` command:
+
+```shell
+kubectl version
+```
+
+OK, kubectl is installed and you can see both the client and the server versions.
+
+To view the nodes in the cluster, run the `kubectl get nodes` command:
+
+```shell
+kubectl get nodes
+```
+
+Here we see the available nodes (1 in our case). Kubernetes will choose where to deploy our application based on Node available resources.
+
+## Step 2 - Deploy our app
+
+Let's deploy our first app on Kubernetes with the `kubectl create deployment` command. We need to provide the deployment name and app image location (include the full repository url for images hosted outside Docker Hub).
+
+```shell
+kubectl create deployment kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1
+```
+
+Great! You just deployed your first application by creating a deployment. This performed a few things for you:
+
+- searched for a suitable node where an instance of the application could be run (we have only 1 available node)
+- scheduled the application to run on that Node
+- configured the cluster to reschedule the instance on a new Node when needed
+
+To list your deployments use the `get deployments` command:
+
+```shell
+kubectl get deployments
+```
+
+We see that there is 1 deployment running a single instance of your app. The instance is running inside a Docker container on your node.
+
+## Step 3 - View our app
+
+Pods that are running inside Kubernetes are running on a private, isolated network. By default they are visible from other pods and services within the same Kubernetes cluster, but not outside that network. When we use `kubectl`, we're interacting through an API endpoint to communicate with our application.
+
+We will cover other options on how to expose your application outside the Kubernetes cluster in Module 4.
+
+The `kubectl` command can create a proxy that will forward communications into the cluster-wide, private network. The proxy can be terminiated by pressing control-C and won't show any output while its running.
+
+We will open a second terminal window to run the proxy.
+
+```shell
+echo -e "Starting Proxy. After starting it will not output a response. Please return to your original terminal window\n"; kubectl proxy
+```
+
+We now have a connection between our host (the online terminal) and the Kubernetes cluster. The proxy enabled direct access to the API from these terminals.
+
+You can see all those APIs hosted through the proxy endpoint. For example, we can query the version directly through the API using the `curl` command:
+```shell
+curl http://localhost:8001/version
+```
+
+*Note: The proxy was run in a new tab, and the recent commands were executed in the original tab. The proxy still runs in the second tab, and this allowed our curl command to work using `localhost:8001`.*
+
+**If Port 8001 is not accessible, ensure that the `kubectl proxy` started above is running.**
+
+The API server will automatically create an endpoint for each pod, based on the pod name, that is also accessible through the proxy.
+
+First we need to get the Pod name, and we'll store in the environment variable POD_NAME:
+```shell
+export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')
+echo Name of the Pod: $POD_NAME
+```
+
+You can access the Pod through the API by running:
+```shell
+curl http://localhost:8001/api/v1/namespaces/default/pods/$PODNAME
+```
+
+In order for the new deployment to be accessible without using the Proxy, a Service is required which will be explained in the next modules.
+
+{{% button link="/docs/tutorials/kubernetes_101/module3" %}}

site/content/en/docs/tutorials/kubernetes_101/module3.md

@@ -0,0 +1,96 @@
+---
+title: "Module 3 - Explore your app"                                
+weight: 3
+--- 
+
+**Difficulty**: Beginner
+**Estimated Time:** 10 minutes
+
+In this scenario you will learn how to troubleshoot Kubernetes applications using the kubectl get, describe, logs and exec commands.
+
+## Step 1 - Check application configuration
+
+Let's verify that the application we deployed in the previous scenario is running. We'll use the `kubectl get` command and look for existing Pods:
+
+```shell
+kubectl get pods
+```
+
+Next, to view what containers are inside that Pod and what images are used to build those containers we run the `describe pods` command:
+
+```shell
+kubectl describe pods
+```
+
+We see here details about the Pod's container: IP address, the ports used and a list of events related to the lifecycle of the Pod.
+
+The output of the `describe` command is extensive and covers some concepts that we didn't explain yet, but don't worry, they will become familiar by the end of this bootcamp.
+
+*Note: the describe command can be used to get detailed information about most of the Kubernetes primitives: node, pods, deployments. The describe output is designed to be human readable, not to be scripted against.*
+
+## Step 2 - Show the app in the terminal
+
+Recall that Pods are running in an isolated, private network - so we need to proxy access to them so we can debug and interact with them. To do this, we'll use the `kubectl proxy` command to run a proxy in a second terminal window. Run the command below in a new terminal window to run the proxy:
+
+```shell
+echo -e "Starting Proxy. After starting it will not output a response. Please return to your original terminal window\n"; kubectl proxy
+```
+
+Now again, we'll get the Pod name and query that pod directly through the proxy. To get the Pod name and store it in the POD_NAME ennvironment variable:
+
+```shell
+export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')
+echo Name of the Pod: $POD_NAME
+```
+
+To see the output of our application, run a `curl` request.
+
+```shell
+curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME
+```
+
+The url is the route to the API of the Pod.
+
+## Step 3 - View the container logs
+
+Anything that the application would normally send to `STDOUT` becomes logs for the container within the Pod. We can retrieve these logs using the `kubectl logs` command:
+
+```shell
+kubectl logs $POD_NAME
+```
+
+*Note: We don't need to specify the container name, because we only have one container inside the pod.
+
+## Step 4 - Executing command on the container
+
+We can execute commands directly on the container once the Pod is up and running. For this, we use the `exec` command and use the name of the Pod as a paramater. Let's list the environment variables:
+
+```shell
+kubectl exec $POD_NAME -- env
+```
+
+Again, worth mentioning that the name of the container itself can be omitted since we only have a single container in the Pod.
+
+Next let's start a bash session in the Pod's container:
+
+```shell
+kubectl exec -ti $POD_NAME -- bash
+```
+
+We have now an open console on the container where we run our NodeJS application. The source code of the app is in the server.js file:
+
+```shell
+cat server.js
+```
+
+You can check that the application is up by running a curl command:
+
+```shell
+curl localhost:8080
+```
+
+*Note: here we used localhost because we executed the command inside the NodeJS Pod. If you cannot connect to localhost:8080, check to make sure you have run the kubectl exec command and are launching the command from within the Pod*
+
+To close your container connection type `exit`.
+
+{{% button link="/docs/tutorials/kubernetes_101/module4" %}}

site/content/en/docs/tutorials/kubernetes_101/module4.md

@@ -0,0 +1,137 @@
+---
+title: "Module 4 - Expose your app publicly"                                
+weight: 4
+--- 
+
+**Difficulty**: Beginner
+**Estimated Time:** 10 minutes
+
+In this scenario you will learn how to expose Kubernetes applications outside the cluster using the kubectl expose command. You will also learn how to view and apply labels to objects with the kubectl label command.
+
+## Step 1 - Create a new service
+
+Let's verify that our application is running. We'll use the `kubectl get` command and look for existing Pods:
+
+```shell
+kubectl get pods
+```
+
+Next, let's list the current Services from our cluster:
+
+```shell
+kubectl get services
+```
+
+We have a Service called Kubernetes that is created by default when minikube starts the cluster. To create a new service and expose it to external traffic we'll use the expose command with NodePort as parameter.
+
+```shell
+kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080
+```
+
+Let's run again the `get services` command:
+
+```shell
+kubectl get services
+```
+
+**Note for Docker Desktop users:** Due to Docker Desktop networking limitations, by default you're unable to access pods directly from the host. Run `minikube service kubernetes-bootcamp`, this will create a SSH tunnel from the pod to your host and open a window in your default browser that's connected to the service. The tunnel can be terminated by pressing control-C, then continue on to Step 2.
+
+We have now a running Service called kubernetes-bootcamp. Here we see that the Service received a unique cluster-IP, an internal port and an external-IP (the IP of the Node).
+
+To find out what port was opened externally (by the NodePort option) we'll run the `describe service` command:
+
+```shell
+kubectl describe services/kubernetes-bootcamp
+```
+
+Create an environment variable called NODE_PORT that has the value of the Node port assigned:
+
+```shell
+export NODE_PORT=$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')
+echo NODE_PORT=$NODE_PORT
+```
+
+Now we can test that the app is exposed outside of the cluster using `curl`, the IP of the Node and the externally exposed port:
+
+```shell
+curl $(minikube ip):$NODE_PORT
+```
+
+And we get a response from the server. The Service is exposed.
+
+## Step 2 - Using labels
+
+The Deployment created automatically a label for our Pod. With `describe deployment` command you can see the name of the label:
+
+```shell
+kubectl describe deployment
+```
+
+Let's use this label to query our list of Pods. We'll use the `kubectl get pods` command with `-l` as a parameter, followed by the label values:
+
+```shell
+kubectl get pods -l app=kubernetes-bootcamp
+```
+
+You can do the same to list the existing services:
+
+```shell
+kubectl get services -l app=kubernetes-bootcamp
+```
+
+Get the name of the Pod and store it in the POD_NAME environment variable:
+
+```shell
+export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')
+echo Name of the Pod: $POD_NAME
+```
+
+To apply a new label we use the label command followed by the object type, object name and the new label:
+
+```shell
+kubectl label pods $POD_NAME version=v1
+```
+
+This will apply a new label to our Pod (we pinned the application version to the Pod), and we can check it with the describe pod command:
+
+```shell
+kubectl describe pods $POD_NAME
+```
+
+We see here that the label is attached new to our Pod. And we can query now the list of pods using the new label:
+
+```shell
+kubectl get pods -l version=v1
+```
+
+And we see the Pod.
+
+## Step 3 - Deleting a service
+
+To delete Services you can use the `delete service` command. Labels can be used also here:
+
+```shell
+kubectl delete service -l app=kubernetes-bootcamp
+```
+
+Confirm that the service is gone:
+
+```shell
+kubectl get services
+```
+
+This confirms that our Service was removed. To confirm that route is not exposed anymore you can `curl` the previously exposed IP and port:
+
+```shell
+curl $(minikube ip):$NODE_PORT
+```
+
+This proces that the app is not reachable anymore from outside of the cluster. You can confirm that the app is still running with a curl inside the pod:
+
+```shell
+kubectl exec -ti $POD_NAME -- curl localhost:8080
+```
+
+We see here that the application is up. This is because the Deployment is managing the application. To shut down the application, you would need to delete the Deployment as well.
+
+{{% button link="/docs/tutorials/kubernetes_101/module5" %}}

site/content/en/docs/tutorials/kubernetes_101/module5.md

@@ -0,0 +1,126 @@
+---
+title: "Module 5 - Scale up your app"
+weight: 5
+---
+
+**Difficulty**: Beginner
+**Estimated Time:** 10 minutes
+
+The goal of this scenario is to scale a deployment with kubectl scale and to see the load balancing in action
+
+## Step 1 - Scaling a deployment
+
+First, let's recreate the Deployment we deleted in the previous module:
+
+```shell
+kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080
+```
+
+To list your deployments use the `get deployment` command:
+
+```shell
+kubectl get deployments
+```
+
+The output should be similar to:
+
+```shell
+NAME                  READY   UP-TO_DATE   AVAILABLE   AGE
+kubernetes-bootcamp   1/1     1            1           11m
+```
+
+We should have 1 Pod. If not, run the command again. This shows:
+
+- *NAME* lists the names of the Deployments in the cluster.
+- *READY* shows the ratio of CURRENT/DESIRED replicas
+- *UP-TO-DATE* displays the number of replicas that have been updated to achieve the desired state.
+- *AVAILABLE* displays how many replicas of the application are available to your users.
+- *AGE* displays the amount of time that the application has been running.
+
+To see the ReplicaSet created by the Deployment, run:
+
+```shell
+kubectl get rs
+```
+
+Notice that the name of the ReplicaSet is always formatted as `[DEPLOYMENT-NAME]-[RANDOM-STRING]`. The random string is randomly generated and uses the pod-template-hash as a seed.
+
+Two important columns of this command are:
+
+- *DESIRED* displays the desired number of replicas of the application, which you define when you create the Deployment. This is the desired state.
+- *CURRENT* displays how many replicas are currently running.
+
+Next, let's scan the Deployment to 4 replicas. We'll use the `kubectl scale` command, following by the deployment type, name and desired number of instances:
+
+```shell
+kubectl scale deployments/kubernetes-bootcamp --replicas=4
+```
+
+To list your Deployments once again, use `get deployments`:
+
+```shell
+kubectl get deployments
+```
+
+The change was applied, and we have 4 instances of the application available. Next, let's check if the number of Pods changed:
+
+```shell
+kubectl get pods -o wide
+```
+
+There are 4 Pods now, with different IP addresses. The change was registered in the Deployment events log. The check that, use the describe command:
+
+```shell
+kubectl describe deployments/kubernetes-bootcamp
+```
+
+You can also view in the output of this command that there are 4 replicas now.
+
+## Step 2 - Load Balancing
+
+Let's check that the Service is load-balancing the traffic. To find out the exposed IP and Port we can use the describe service as we learned in the previous Module:
+
+```shell
+kubectl describe services/kubernetes-bootcamp
+```
+
+**Note for Docker Desktop users:** Due to Docker Desktop networking limitations, by default you're unable to access pods directly from the host. Run `minikube service kubernetes-bootcamp`, this will create a SSH tunnel from the pod to your host and open a window in your default browser that's connected to the service. Refresh the browser page to see the load-balancing working. The tunnel can be terminated by pressing control-C, then continue on to Step 3.
+
+Create an environment variable called NODE_PORT that has a value as the Node port:
+
+```shell
+export NODE_PORT=$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')
+echo NODE_PORT=$NODE_PORT
+```
+
+Next, we'll do a `curl` to the exposed IP and port. Execute the command mulitple times:
+
+```shell
+curl $(minikube ip):$NODE_PORT
+```
+
+We hit a different Pod with every request. This demonstrates that the load-balancing is working.
+
+## Step 3 - Scale Down
+
+To scale down the Service to 2 replicas, run again the `scale` command:
+
+```shell
+kubectl scale deployments/kubernetes-bootcamp --replicas=2
+```
+
+List the Deployments to check if the change was applied with the `get deployments` command:
+
+```shell
+kubectl get deployments
+```
+
+The number of replicas decreased to 2. List the number of Pods, with `get pods`:
+
+```shell
+kubectl get pods -o wide
+```
+
+This confirms that 2 Pods were terminated.
+
+{{% button link="/docs/tutorials/kubernetes_101/module6" %}}

site/content/en/docs/tutorials/kubernetes_101/module6.md

@@ -0,0 +1,133 @@
+---
+title: "Module 6 - Update your app"
+weight: 6
+---
+
+**Difficulty:** Beginner
+**Estimated Time:** 10 minutes
+
+The goal of this scenario is to update a deployed application with kubectl set image and to rollback with the rollout undo command.
+
+## Step 1 - Update the version of the app
+
+To list your deployments, run the `get deployments` command:
+
+```shell
+kubectl get deployments
+```
+
+To list the running Pods, run the `get pods` command:
+
+```shell
+kubectl get pods
+```
+
+To view the current image version of the app, run the `describe pods` command and look for the `Image` field:
+
+```shell
+kubectl describe pods
+```
+
+To update the image of the application to version 2, use the `set image` command, followed by the deployment name and the new image version:
+
+```shell
+kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=jocatalin/kubernetes-bootcamp:v2
+```
+
+The command notified the Deployment to use a different image for your app and initiated a rolling update. Check the status of the new Pods, and view the old one terminating with the `get pods` command:
+
+```shell
+kubectl get pods
+```
+
+## Step 2 - Verify an update
+
+First, check that the app is running. To find the exposed IP and Port, run the `describe service` command:
+
+```shell
+kubectl describe services/kubernetes-bootcamp
+```
+
+**Note for Docker Desktop users:** Due to Docker Desktop networking limitations, by default you're unable to access pods directly from the host. Run `minikube service kubernetes-bootcamp`, this will create a SSH tunnel from the pod to your host and open a window in your default browser that's connected to the service. The tunnel can be terminated by pressing control-C, then continue the tutorial after the `curl $(minikube ip):$NODE_PORT` command.
+
+Create an environment variable called `NODE_PORT` that has the value of the Node port assigned:
+
+```shell
+export NODE_PORT=$(kubectl get services/kubernetes-bootcamp -o go-template='{{(index .spec.ports 0).nodePort}}')
+echo NODE_PORT=$NODE_PORT
+```
+
+Next, do a `curl` to the exposed IP and port:
+
+```shell
+curl $(minikube ip):$NODE_PORT
+```
+
+Every time you run the `curl` command, you will hit a different Pod. Notice that all Pods are running the latest version (v2).
+
+You can also confirm the update by running the `rollout status` command:
+
+```shell
+kubectl rollout status deployments/kubernetes-bootcamp
+```
+
+To view the current image version of the app, run the `describe pods` command:
+
+```shell
+kubectl describe pods
+```
+
+In the `Image` field of the output, verify that you are running the latest image version (v2).
+
+
+## Step 3 - Rollback an update
+
+Let's perform another update, and deploy an image tagged with `v10`:
+
+```shell
+kubectl set image deployments/kubernetes-bootcamp kubernetes-bootcamp=gcr.io/google-samples/kubernetes-bootcamp:v10
+```
+
+Use `get deployments` to see the status of the deployment:
+
+```shell
+kubectl get deployments
+```
+
+Notice that the output doesn't list the desired number of available Pods. Run the `get pods` command to list all Pods:
+
+```shell
+kubectl get pods
+```
+
+Notice that some of the Pods have a status of `ImagePullBackOff`.
+
+To get more insight into the problem, run the `describe pods` command:
+
+```shell
+kubectl describe pods
+```
+
+In the `Events` section of the output for the affected Pods, notice that the `v10` image version did not exist in the repository.
+
+To roll back the deployment to your last working version, use the `rollout undo` command:
+
+```shell
+kubectl rollout undo deployments/kubernetes-bootcamp
+```
+
+The `rollout undo` command reverts the deployment to the previous known state (v2 of the image). Updates are versioned and you can revert to any previously known state of a deployment.
+
+Use the `get pods` commands to list the Pods again:
+
+```shell
+kubectl get pods
+```
+
+Four Pods are running. To check the image deployed on these Pods, use the `describe pods` command:
+
+```shell
+kubectl describe pods
+```
+
+The deployment is once again using a stable version of the app (v2). The rollback was successful.

site/layouts/partials/hooks/head-end.html

@@ -1,6 +1,7 @@
 <!-- start: minikube override head-end partial -->
 <link href="https://fonts.googleapis.com/css2?family=Lora:wght@400;500;600;700&family=Open+Sans:wght@600;700&display=swap" rel="stylesheet">
 <link href="/css/tabs.css" rel="stylesheet">
+<link href="/css/button.css" rel="stylesheet">
 <script src="/js/tabs.js"></script>
 <script src="/js/quiz.js"></script>
 <!-- end: minikube override head-end partial -->

site/layouts/shortcodes/button.html

@@ -0,0 +1 @@
+<a href="{{ .Get "link" }}"><button type="button" class="module-button">Next Module ➔</button></a>

site/static/css/button.css

@@ -0,0 +1,13 @@
+.module-button {
+  color: #fff;
+  background: #306EE5;
+  border-radius: 0.5rem;
+  font-size: 2rem;
+  border: none;
+  padding: 0.5rem 1rem;
+  margin: 2rem 0;
+}
+
+.module-button:hover {
+  background: #164cb2;
+}