Implement review comments from Michael

Co-authored-by: Michael Ingeman-Nielsen <[email protected]>

Author: jbrejner

accessing-your-application.md

@@ -35,11 +35,13 @@ You can then access the pod on `localhost:8080`.
 Port forwarding is a network address translation that redirects Internet packets from one IP address
 to another with a specified port number to another `IP:PORT` set.
 
-In Kubernetes `port-forward` creates a tunnel between your local machine and the Kubernetes cluster on
-the specified `IP:PORT` pairs to establish a connection to the cluster.
-`kubectl port-forward` allows you to forward not only pods but also services, deployments, and others.
+The `port-forward` command in Kubernetes forwards incoming traffic to the machine, the command is
+executed on, to the specified `IP:PORT` pairs inside the Kubernetes cluster. This effectively
+lets traffic from outside the cluster reach applications running inside the cluster.
+`kubectl port-forward` allows you to forward traffic to pods, services, deployments, and others.
 
-More information can be found from [Use Port Forwarding to Access Applications in a Cluster](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
+More information can be found in the Kubernetes docs at
+[Use Port Forwarding to Access Applications in a Cluster](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
 
 </details>
 
@@ -78,7 +80,7 @@ The pod is defined in the `frontend-pod.yaml` file.
 
 </details>
 
-- Check that the pod is running with the `kubectl get pods` command.
+- Use the `kubectl get pods` command to verify that the pod is running.
 
 You should see something like this:
 
@@ -87,7 +89,7 @@ NAME       READY   STATUS    RESTARTS   AGE
 frontend   1/1     Running   0          2m
 ```
 
-- Expose the frontend with port-forward
+- Expose the frontend with `port-forward`
 
 Port forwarding can be achieved with:
 

persistent-storage.md

@@ -277,7 +277,7 @@ Fill in the values:
 - `mountPath` is the path in the container to mount the volume to. For postgres, the database state is
   stored to the path `/var/lib/postgresql/data`
 - `subPath` should be `postgres`, and specifies a directory to be created within the volume. We need
-  this because of a quirk with combining `AWS EBS` with Postgres. (If you are curious, why:
+  this because of a quirk with combining `AWS EBS` with Postgres. (If you are curious why:
   <https://stackoverflow.com/a/51174380>)
 
 <details>

rolling-updates.md

@@ -118,7 +118,7 @@ spec:
       name: backend
 ```
 
-What happened - does the frontend still work? And are you able to see the backend version in the browser?
+What happened? Does the frontend still work? Are you able to see the backend version in the browser?
 
 - Investigate the running pods with: `kubectl get pods`
 

services.md

@@ -13,7 +13,7 @@ between them.
 
 ## Service Discovery & Services
 
-One of the features of Kubernetes is that we do not have to care which machine our pods are
+One of the features of Kubernetes is that we do not have to know which machine our pods are
 running on. This does create an interesting problem for us - if we don't know where (the IP address)
 the pod is, how can we route traffic to it? This is solved by what is called **service discovery**,
 as the words imply, Kubernetes will look for your pods and dynamically route traffic to them.
@@ -32,9 +32,9 @@ the rest!
 The `service` then routes traffic to the pods that it selects. You can think of `service` as a kind of
 proxy - you route traffic to the service, and the service routes the traffic to your pods.
 
-While the `service` gets a static IP address, we prefer not to use it, because Kubernetes
-runs its own DNS server in the cluster network, and every time we create a `service`, a DNS record is
-created that points to the `service` IP address.
+While the `service` gets a static IP address, we prefer not to use it. Kubernetes
+runs its own DNS server in the cluster network, and every time we create a `service`,
+a DNS record that points to the `service` IP address is automatically created.
 The DNS record is always the `name` of the service, and can be referenced either from the same
 namespace by using the name or from a different namespace by using the long form:
 `<name>.<namespace>.svc.cluster.local`.
@@ -161,7 +161,7 @@ internet, but we can still access it from within the cluster using its `CLUSTER-
 - No matter what type of service you choose while _exposing_ your pod, Cluster-IP is always
   assigned to that particular service.
 
-- Every service has endpoints, which point to the actual pod serving as the backend of a particular
+- Every service has end-points, which point to the actual pod serving as the backend of a particular
   service.
 
 - As soon as a service is created and is assigned a Cluster-IP, an entry is made in Kubernetes'
@@ -186,7 +186,8 @@ service from the internet.
 
 There are other types of services, like `LoadBalancer`, but we won't cover them in this exercise.
 
-If you want to know more about Services, you can read more about them [Service types](https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types).
+If you want to know more about Services, you can read more about them in the Kubernetes docs for
+[Service types](https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types).
 
 > :bulb: Hint: You can use the `kubectl explain` command to get more information about the fields
 > in the YAML file. For example, `kubectl explain service.spec` will give you more information