Typos and links fixed. Minor rephrasing work done

courses/level102/containerization_and_orchestration/conclusion.md

@@ -1,5 +1,5 @@
 # Conclusion
 
-In this sub-module we have toured the world of containers starting from why we use containers, how containers evolved from the virtual machine past (though they are, in no means, obsolete) and how are different from virtual machines. We then saw how containers are implemented with emphasis on cgroups and namespaces along with some hands-on exercises. Finally we concluded our journey with container orchestration where we learnt a bit of Kubernetes with some practical examples.
+In this sub-module we have toured the world of containers starting from why we use containers, how containers evolved from the virtual machine past (though they are, in no means, obsolete) and how they are different from virtual machines. We then saw how containers are implemented with emphasis on cgroups and namespaces along with some hands-on exercises. Finally we concluded our journey with container orchestration where we learnt a bit of Kubernetes with some practical examples.
 
 Hope this module gives you enough knowledge and interest to continue learning and applying these technologies in greater depth!

courses/level102/containerization_and_orchestration/containerization_with_docker.md

@@ -1,6 +1,6 @@
 ## Introduction
 
-Docker has gained huge popularity among other container engines since it was released to the public in 2013. Here are some of the reasons why Docker so darn popular:
+Docker has gained huge popularity among other container engines since it was released to the public in 2013. Here are some of the reasons why Docker so popular:
 
 - _Improved portability_
 
@@ -19,7 +19,7 @@ Since Docker images are in the form of layers, one image can be used as base on
 
 - _Community support_
 
-Docker hub is a container registry where anyone logged in can upload or download a container image. Docker images versions of popular OS distros are regularly updated in docker hub and receive large community support.
+Docker hub is a container registry where anyone logged in can upload or download a container image. Docker images of popular OS distros are regularly updated in docker hub and receive large community support.
 
 Let’s look at some terms which come up during our discussion of Docker.
 
@@ -91,7 +91,7 @@ While we have covered the basics of containerization and how a standalone applic
 
 **Docker networks**
 
-Docker networks facilitate the interaction between containers running on the same hosts or even different hosts. There are several options provided through docker network command which specifies how the container interacts with the host and with other containers. The host option allows sharing of network stack with the host, bridge allows communication between containers running on the same host but not to external to the host, overlay facilitates interaction between containers across hosts attached to the same network and macvlan which assigns a separate MAC address to a container for legacy containers are some important types of networks supported by Docker.  This however is outside the scope of this module. The official documentation on [docker networks](https://docs.docker.com/network/) itself is a good place to start.
+Docker networks facilitate the interaction between containers running on the same hosts or even different hosts. There are several options provided through docker network command which specifies how the container interacts with the host and with other containers. The `host` option allows sharing of network stack with the host, `bridge` allows communication between containers running on the same host but not external to the host, `overlay` facilitates interaction between containers across hosts attached to the same network and `macvlan` which assigns a separate MAC address to a container for legacy containers are some important types of networks supported by Docker.  This however is outside the scope of this module. The official documentation on [docker networks](https://docs.docker.com/network/) itself is a good place to start.
 
 **Volumes**
 

courses/level102/containerization_and_orchestration/intro.md

@@ -9,7 +9,7 @@ In this module we talk about the ins and outs of containers: the internals and u
 ### Prerequisites
 - Basic knowledge of linux will be helpful understanding the internals of containers
 - Basic knowledge of shell commands (will come handy when we're containerizing applications)
-- Knowledge of running a basic web application. You can go through our [Python And Web module](https://linkedin.github.io/school-of-sre/python_web/intro/) to gain familiarity with this.
+- Knowledge of running a basic web application. You can go through our [Python And Web module](https://linkedin.github.io/school-of-sre/level101/python_web/intro/) to gain familiarity with this.
 
 
 ## What to expect from this course

courses/level102/containerization_and_orchestration/intro_to_containers.md

@@ -177,7 +177,7 @@ This limit is too low and hence most of the processes attached to mem_group shou
 
 The process is OOM killed as expected. You can confirm the same with dmesg logs (mm_fault_error).
 
-We highly recommend trying out the more in depth block IO [cgroup tutorial in GeeksForGeeks](geeksforgeeks.org/linux-virtualization-resource-throttling-using-cgroups/).
+If you want to try out a more in-depth exercise on cgroups, check out [this tutorial from Geeks for Geeks](geeksforgeeks.org/linux-virtualization-resource-throttling-using-cgroups/).
 
 
 Let’s come back to containers again. Containers share the same kernel as the underlying host operating system and provide an isolated environment of the application within. Cgroups help in managing resources used by processes within a container and namespaces help isolate network stack, pids, users, group ids and mount points in a container from another container running on the same host.
@@ -195,4 +195,4 @@ Container engines ease the process of creating and managing containers in a host
 * The files in the container image are then mounted to the isolated environment to get the  application up and running within the container.
 
 There are several container engines available like Docker, RKT, LXC (one of the first container engines) which require different image formats (Docker, LXD). OCI (Open Container Initiative) is a collaborative project started by Docker that aims to standardize container runtime specifications and image formats across vendors. OCI [FAQ section](https://opencontainers.org/faq/) is a good place to start if you’re curious about this project.
-We will focus on Docker in the [next section](https://linkedin.github.io/school-of-sre/containerization_and_orchestration/containerization_with_docker/).
+We will focus on Docker in the [next section](https://linkedin.github.io/school-of-sre/level102/containerization_and_orchestration/containerization_with_docker/).

courses/level102/containerization_and_orchestration/orchestration_with_kubernetes.md

@@ -42,7 +42,7 @@ Kubernetes components can be divided into two parts: [control plane components](
 
 A Kubernetes cluster consists of 1 or more host machines (called nodes) where the containers managed by Kubernetes are run. This constitutes the data plane (or node plane). 
 
-The brain of Kuberentes which responds to events from the node plane (e.g create a pod, replicas mismatch) and does the main orchestration is called the control plane. All control plan components are typically installed in a master node. This master node does not run any user containers.
+The brain of Kuberentes which responds to events from the node plane (e.g create a pod, replicas mismatch) and does the main orchestration is called the control plane. All control plane components are typically installed in a master node. This master node does not run any user containers.
 
 The Kubernetes components themselves are run as containers wrapped in Pods (which is the most basic kubernetes resource object).
 
@@ -57,7 +57,7 @@ The Kubernetes components themselves are run as containers wrapped in Pods (whic
 
 This workflow might help you understand the working on components better:
 
-- An SRE installs `kubectl` in their local machine. This is the client which interacts with the Kubernetes control plan (and hence the cluster).
+- An SRE installs `kubectl` in their local machine. This is the client which interacts with the Kubernetes control plane (and hence the cluster).
 
 - They create a YAML file, called manifest which specifies the desired state of the resource (e.g a deployment names “frontend” needs 3 pods to always be running)
 
@@ -197,7 +197,7 @@ Verify that 3 pods are indeed created.
 
 If you’re curious, check the output of `kubectl get deploy` and `kubectl describe deploy nginx-deployment`.
 
-* Delete one of the 3 pods using `kubectl delete po <pod name>`. After a few seconds again do `kubectl get po`.
+* Delete one of the 3 pods using `kubectl delete pod <pod name>`. After a few seconds again do `kubectl get pod`.
 
 ![](images/kube7.png)