Setup is a noun; set up is a verb. Fix some more typos.

docs/concepts-k8s.md

@@ -92,7 +92,7 @@ class: pic
 
   (Courtesy of [Yongbok Kim](https://www.yongbok.net/blog/))
 
-- The second one is an good simplified representation of a Kubernetes cluster
+- The second one is a simplified representation of a Kubernetes cluster
 
   (Courtesy of [Imesh Gunaratne](https://medium.com/containermind/a-reference-architecture-for-deploying-wso2-middleware-on-kubernetes-d4dee7601e8e))
 

docs/daemonset.md

@@ -164,7 +164,7 @@ We have both `deploy/rng` and `ds/rng` now!
 
 --
 
-And one too many pod ...
+And one too many pods...
 
 ---
 
@@ -215,9 +215,9 @@ It appears that *all the pods* are serving requests at the moment.
 
 ## The magic of selectors
 
-- The `rng` *service* is load balancing requests to a set of pod
+- The `rng` *service* is load balancing requests to a set of pods
 
-- This set of pod is defined as "pods having the label `run=rng`"
+- This set of pods is defined as "pods having the label `run=rng`"
 
 .exercise[
 

docs/firstservice.md

@@ -316,7 +316,7 @@ class: btw-labels
 
 - If you want to place multiple HTTP services on port 80, you need something more
 
-- You can setup NGINX or HAProxy on port 80 to do the virtual host switching
+- You can set up NGINX or HAProxy on port 80 to do the virtual host switching
 
 - Docker Universal Control Plane provides its own [HTTP routing mesh](
   https://docs.docker.com/datacenter/ucp/2.1/guides/admin/configure/use-domain-names-to-access-services/)

docs/kubectlrun.md

@@ -29,7 +29,7 @@
 
 --
 
-OK, what did just happen?
+OK, what just happened?
 
 ---
 
@@ -196,7 +196,7 @@ We could! But the *deployment* would notice it right away, and scale back to the
 
 ## What if we wanted something different?
 
-- What if we wanted to start a "one-shot" container, that *does not* get restarted?
+- What if we wanted to start a "one-shot" container that *doesn't* get restarted?
 
 - We could use `kubectl run --restart=OnFailure` or `kubectl run --restart=Never`
 

docs/kubenet.md

@@ -63,7 +63,7 @@
 
 ## Kubernetes network model: in practice
 
-- The nodes that we are using have been setup to use Weave
+- The nodes that we are using have been set up to use Weave
 
 - We don't endorse Weave in a particular way, it just Works For Us
 

docs/metrics.md

@@ -902,7 +902,7 @@ class: snap, prom
 
 - Leave that tab open!
 
-- We are going to setup *another* metrics system
+- We are going to set up *another* metrics system
 
 - ... And then compare both graphs side by side
 
@@ -1495,9 +1495,9 @@ class: prom, snap
 
 ## Comparing Snap and Prometheus data
 
-- If you haven't setup Snap, InfluxDB, and Grafana, skip this section
+- If you haven't set up Snap, InfluxDB, and Grafana, skip this section
 
-- If you have closed the Grafana tab, you might have to re-setup a new dashboard
+- If you have closed the Grafana tab, you might have to re-set up a new dashboard
 
   (Unless you saved it before navigating it away)
 

docs/operatingswarm.md

@@ -20,7 +20,7 @@ The following exercises assume that you have a 5-nodes Swarm cluster.
 
 If you come here from a previous tutorial and still have your cluster: great!
 
-Otherwise: check [part 1](#part-1) to learn how to setup your own cluster.
+Otherwise: check [part 1](#part-1) to learn how to set up your own cluster.
 
 We pick up exactly where we left you, so we assume that you have:
 

docs/setup-k8s.md

@@ -1,6 +1,6 @@
 # Setting up Kubernetes
 
-- How did we setup these Kubernetes clusters that we're using?
+- How did we set up these Kubernetes clusters that we're using?
 
 --
 
@@ -12,7 +12,7 @@
 
     3. Run `kubeadm init` on the master node
 
-    4. Setup Weave (the overlay network)
+    4. Set up Weave (the overlay network)
        <br/>
        (that step is just one `kubectl apply` command; discussed later)
 
@@ -24,19 +24,19 @@
 
 ## `kubeadm` drawbacks
 
-- Doesn't setup Docker or any other container engine
+- Doesn't set up Docker or any other container engine
 
-- Doesn't setup the overlay network
+- Doesn't set up the overlay network
 
 - Scripting is complex
   <br/>
   (because extracting the token requires advanced `kubectl` commands)
 
-- Doesn't setup multi-master (no high availability)
+- Doesn't set up multi-master (no high availability)
 
 --
 
-- It's still twice as much steps as setting up a Swarm cluster 😕
+- It's still twice as many steps as setting up a Swarm cluster 😕
 
 ---
 

docs/whatsnext.md

@@ -11,9 +11,9 @@ Suggested containerization checklist:
 - write Dockerfiles for the other (buildable) services
 - write a Compose file for that whole app
 - make sure that devs are empowered to run the app in containers
-- setup automated builds of container images from the code repo
-- setup a CI pipeline using these container images
-- setup a CD pipeline (for staging/QA) using these images 
+- set up automated builds of container images from the code repo
+- set up a CI pipeline using these container images
+- set up a CD pipeline (for staging/QA) using these images
 ]
 
 And *then* it is time to look at orchestration!