Language and spelling fixes with Grammarly

Author: jbrejner

accessing-your-application.md

@@ -32,14 +32,14 @@ You can then access the pod on `localhost:8080`.
 <details>
 <summary>:bulb: How does this port-forward work?</summary>
 
-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.
+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.
 
-More information can be found from [port-forward-access-application-cluste](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
+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/)
 
 </details>
 

configmaps-secrets.md

@@ -8,13 +8,13 @@
 ## Introduction
 
 Configmaps and secrets are a way to store information that is used by several deployments and pods
-in your cluster. This makes it easy to update the configuration in one place, when you want to
+in your cluster. This makes it easy to update the configuration in one place when you want to
 change it.
 
 Both configmaps and secrets are generic `key-value` pairs, but secrets are `base64 encoded` and
 configmaps are not.
 
-> :bulb: Secrets are not encrypted, they are encoded. This means that if someone gets access to the
+> :bulb: Secrets are not encrypted; they are encoded. This means that if someone gets access to the
 > cluster, they will be able to read the values.
 
 ## ConfigMaps
@@ -23,10 +23,10 @@ You use a ConfigMap to keep your application code separate from your configurati
 
 It is an important part of creating a [Twelve-Factor Application](https://12factor.net/).
 
-This lets you change easily configuration depending on the environment (development, production,
+This lets you change configuration easily depending on the environment (development, production,
 testing, etc.) and to dynamically change configuration at runtime.
 
-A ConfigMap manifest looks like this in yaml:
+A ConfigMap manifest looks like this in YAML:
 
 ```yaml
 apiVersion: v1
@@ -101,7 +101,7 @@ data:
 
 `secrets` are used for storing configuration that is considered sensitive, and well ... _secret_.
 
-When you create a `secret` Kubernetes will go out of it's way to not print the actual values of
+When you create a `secret`, Kubernetes will go out of its way to not print the actual values of
 secret object, to things like logs or command output.
 
 You should use `secrets` to store things like passwords for databases, API keys, certificates, etc.
@@ -113,19 +113,19 @@ source these values from environment variables.
 actual values are `base64` encoded. `base64` encoded means that the values are obscured, but can be
 trivially decoded. When values from a `secret` are used, Kubernetes handles the decoding for you.
 
-> :bulb: As `secrets` don't actually make their data secret for anyone with access to the cluster,
+> :bulb: As `secrets` don't make their data secret for anyone with access to the cluster,
 > you should think of `secrets` as metadata for humans, to know that the data contained within is
 > considered secret.
 
 ## Using ConfigMaps and Secrets in a deployment
 
-To use a configmap or secret in a deployment, you can either mount it in as a volume, or use it
+To use a configmap or secret in a deployment, you can either mount it as a volume or use it
 directly as an environment variable.
 
 ### Injecting a ConfigMap as environment variables
 
 This will inject all key-value pairs from a configmap as environment variables in a container.
-The keys will be the name of variables, and the values will be values of the variables.
+The keys will be the names of variables, and the values will be the values of the variables.
 
 ```yaml
 apiVersion: apps/v1
@@ -151,10 +151,10 @@ spec:
 
 - Add the database part of the application
 - Change the database user into a configmap and implement that in the backend
-- Change the database password into a secret, and implement that in the backend.
+- Change the database password to a secret, and implement that in the backend.
 - Change database deployment to use the configmap and secret.
 
-### Step by step instructions
+### Step-by-step instructions
 
 <details>
 <summary>
@@ -168,7 +168,7 @@ Step by step:
 We have already created the database part of the application, with a deployment and a service.
 
 - Look at the database deployment file `postgres-deployment.yaml`.
-  Notice the database username and password are injected as hardcoded environment variables.
+  Notice that the database username and password are injected as hardcoded environment variables.
 
 > :bulb: This is not a good practice, as we do not want to store these values in version control.
 > We will fix this in the next steps.
@@ -194,10 +194,10 @@ postgres-6fbd757dd7-ttpqj  1/1     Running   0          4s
 #### Refactor the database user into a configmap and implement that in the backend
 
 We want to change the database user into a configmap, so that we can change it in one place, and
-use it on all deployments that needs it.
+use it on all deployments that need it.
 
 - Create a configmap with the name `postgres-config` and filename `postgres-config.yaml` and the
-  information about database configuration as follows:
+  information about the database configuration as follows:
 
 ```yaml
 data:
@@ -238,7 +238,7 @@ data:
 
 </details>
 
-- apply the configmap with `kubectl apply -f postgres-config.yaml`
+- Apply the configmap with `kubectl apply -f postgres-config.yaml`
 - In the `backend-deployment.yaml`, change the environment variables to use the configmap instead
   of the hardcoded values.
 
@@ -266,14 +266,14 @@ data:
         name: postgres-config
   ```
 
-- re-apply the backend deployment with `kubectl apply -f backend-deployment.yaml`
-- check that the website is still running.
+- Re-apply the backend deployment with `kubectl apply -f backend-deployment.yaml`
+- Check that the website is still running.
 
 #### Change the database password into a secret, and implement that in the backend
 
-We want to change the database password into a secret, so that we can change it in one place, and
-use it on all deployments that needs it.
-In order for this, we need to change the backend deployment to use the secret instead of the
+We want to change the database password to a secret, so that we can change it in one place, and
+use it on all deployments that need it.
+For this, we need to change the backend deployment to use the secret instead of the
 configmap for the password itself.
 
 - create a secret with the name `postgres-secret` and the following data:
@@ -340,12 +340,12 @@ envFrom:
 
 We are going to implement the configmap and secret in the database deployment as well.
 
-The standard Postgres docker image can be configured by setting specific environment variables,
+The standard Postgres Docker image can be configured by setting specific environment variables,
 ([you can see the documentation here](https://hub.docker.com/_/postgres)).
-By populating these specific values we can configure the credentials for root user and the name of
-the database to be created.
+By populating these specific values, we can configure the credentials for the root user and the name
+of the database to be created.
 
-This means that we need to change the way we are injecting the environment variables, in order to
+This means that we need to change the way we are injecting the environment variables, to
 make sure the environment variables have the correct names.
 
 - Open the `postgres-deployment.yaml` file, and change the way the environment variables are
@@ -371,8 +371,8 @@ env:
         key: DB_PASSWORD
 ```
 
-- re-apply the database deployment with `kubectl apply -f postgres-deployment.yaml`
-- check that the website is still running, and that the new database can be reached from the backend.
+- Re-apply the database deployment with `kubectl apply -f postgres-deployment.yaml`
+- Check that the website is still running, and that the new database can be reached from the backend.
 
 Congratulations! You have now created a configmap and a secret, and used them in your application.
 

deployments-ingress.md

@@ -5,7 +5,7 @@
 - Learn how to expose a deployment using Ingress
 - Learn how to use `deployments`
 - Learn how to scale deployments
-- Learn how to use `services` to do loadbalance between the pods of a scaled deployment
+- Learn how to use `services` to do load balancing between the pods of a scaled deployment
 
 ## Introduction
 
@@ -14,7 +14,7 @@ scale it, and how to expose it using an `Ingress` resource with URL routing.
 
 ## Deployments
 
-Deployments are a higher level abstraction than pods, and controls the lifecycle
+Deployments are a higher-level abstraction than pods, and control the lifecycle
 and configuration of a "deployment" of an application. They are used to manage a
 set of pods, and to ensure that a specified number of pods are always running
 with the desired configuration. `deployments` are a Kubernetes `kind` and
@@ -71,13 +71,13 @@ spec:
 
 ### High Availability
 
-In order to make our application stable, we want **high availability**. High availability means that
+To make our application stable, we want **high availability**. High availability means that
 we replicate our applications, such that we have **redundant copies**, which means that _when_ an
 application fails, our users are not impacted, as they will simply use one of the other copies,
 while the failed instance recovers.
 
-In Kubernetes this is done in practice by `scaling` a deployment, e.g. by adding or removing
-`replicas`. `replicas` are **identical** copies of the **the same pod**.
+In Kubernetes, this is done in practice by `scaling` a deployment, e.g., by adding or removing
+`replicas`. `replicas` are **identical** copies of the **same pod**.
 
 To scale a deployment, we change the number of `replicas` in the manifest file, and then apply the
 changes using `kubectl apply -f <manifest-file>`.
@@ -135,11 +135,11 @@ ingress-controller called ALB, and the ALB will route traffic to the service.
 - Scale the deployment by adding a replicas key
 - Turn frontend pod manifests into a deployment manifest
 - Apply the frontend deployment manifest
-- Test service promise of high availability
+- Test the service promise of high availability
 
-> :bulb: If you get stuck somewhere along the way, you can check the solution inthe done directory.
+> :bulb: If you get stuck somewhere along the way, you can check the solution in the **done** directory.
 
-### Step by step instructions
+### Step-by-step instructions
 
 <details>
 <summary>
@@ -148,9 +148,9 @@ Step by step:
 
 - Go into the `deployments-ingress/start` directory.
 
-In the directory we have the pod manifests for the backend and frontend that have created in the
+In the directory, we have the pod manifests for the backend and frontend that were created in the
 previous exercises. We also have two services, one for the backend (type ClusterIP) and one for the
-frontend (type NodePort) as well as an ingress manifest for the frontend.
+frontend (type NodePort), as well as an ingress manifest for the frontend.
 
 #### Add Ingress to frontend service
 
@@ -192,9 +192,8 @@ It will take a while for the ingress to work, so we will continue with the backe
 
 #### Deploy the quotes application
 
-To show how Deployments take the place of Pod manifests we will
-first deploy the quotes application, and then slowly replace the
-Pods with Deployments.
+To show how Deployments take the place of Pod manifests, we will first deploy the quotes application,
+and then slowly replace the Pods with Deployments.
 
 - Deploy the following using the `kubectl apply -f` command
   - `frontend-pod.yaml`
@@ -210,7 +209,7 @@ Pods with Deployments.
 How do I connect to a pod through a NodePort service?
 </summary>
 
-> :bulb: In previous exercises you learned how connect to a pod exposed through a NodePort service,
+> :bulb: In previous exercises, you learned how to connect to a pod exposed through a NodePort service,
 > you need to find the nodePort using `kubectl get service` and the IP address of one of the nodes
 > using `kubectl get nodes -o wide`
 > Then combine the node IP address and nodePort with a colon between them, in a browser or using curl:
@@ -224,12 +223,11 @@ http://<node-ip>:<nodePort>
 #### Turn the backend pod manifests into a deployment manifest
 
 Now we'll replace the Pod manifest with a Deployment manifest. In addition to the regular
-manifest fields, we need to set couple of extra things:
+manifest fields, we need to set a couple of extra things:
 
-1. A Pod `template`. This almost a copy of most of the Pod manifest. This defines the Pods
+1. A Pod `template`. This is almost a copy of most of the Pod manifest. This defines the Pods
    that will be created by the deployment.
-2. A `selectorLabel`. This is used to determine which pods to manage will be managed by the
-   ReplicaSet.
+2. A `selectorLabel`. This is used to determine which pods will be managed by the ReplicaSet.
 3. A number of `replicas`. This specifies how many simultaneous identical copies we want of the Pod
 
 To do this, open both the `backend-deployment.yaml` and the `backend-pod.yaml` files in your editor,
@@ -243,7 +241,7 @@ Now we need to set the `selectorLabel`
 
 - Add a `selector` key under the `spec` key
 - Add a `matchLabels` key under the `selector` key
-- Look up the the `metadata.label` section in `backend-pod.yaml`
+- Look up the `metadata.label` section in `backend-pod.yaml`
   and the labels defined there under `matchLabels`
 
 <details>
@@ -353,20 +351,20 @@ Deployment. We've already deployed the Pod, so let us remove it again before app
 
 - Access the frontend again from the browser.
 
-  Now the Ingress should work and you should be able to access the frontend from the browser using
+  Now the Ingress should work, and you should be able to access the frontend from the browser using
   the hostname you specified in the ingress manifest.
 
-  The url should look something like this:
+  The URL should look something like this:
 
   ```text
   http://quotes-<yourname>.<prefix>.eficode.academy
   ```
 
-- If it still does not work, you can check it through NodePort service instead.
+- If it still does not work, you can check it through the NodePort service instead.
 
 - You should now see the backend.
 
-- If this works, please delete the `backend-pod.yaml` file, as we now have upgraded to a deployment
+- If this works, please delete the `backend-pod.yaml` file, as we have now upgraded to a deployment
   and no longer need it!
 
 #### Scale the deployment by adding a replicas key
@@ -424,12 +422,12 @@ backend-5f4b8b7b4-7x7xg   1/1       Running   0          1m
 
 #### Turn frontend pod manifests into a deployment manifest
 
-You will now do the exact same thing for the frontend, we will walk you through it again, but at a
-higher level, if get stuck you can go back and double check how you did it for the backend.
+You will now do the same thing for the frontend. We will walk you through it again, but at a
+higher level. If you get stuck, you can go back and double-check how you did it for the backend.
 
 - Open both the `frontend-deployment.yaml` and the `frontend-pod.yaml` files in your editor.
-- add the api-version and kind keys to the `frontend-deployment.yaml` file.
-- Give the deployment a name of `frontend` under `metadata.name` key.
+- Add the api-version and kind keys to the `frontend-deployment.yaml` file.
+- Give the deployment a name of `frontend` under the `metadata.name` key.
 - Add a label of `run: frontend` under `metadata.labels` key.
 - Set `spec.replicas` to `3`.
 - Copy the `metadata` and `spec` contents of the `frontend-pod.yaml` file into the
@@ -499,7 +497,7 @@ frontend-47b45fb8b-4x7xg   1/1       Running   0          1m
 - Access the frontend again from the browser.
   Note that both the frontend and backend hostname parts of the website should change periodically.
 
-- If this works, please delete the `frontend-pod.yaml` file, as we now have upgraded to a deployment
+- If this works, please delete the `frontend-pod.yaml` file, as we have now upgraded to a deployment
   and no longer need it!
 
 </details>
@@ -531,7 +529,7 @@ kubectl delete -f frontend-ingress.yaml
 
 ## Extra Exercise
 
-Test Kubernetes promise of resiliency and high availability
+Test the Kubernetes promise of resiliency and high availability
 
 <details>
 <summary>
@@ -541,7 +539,7 @@ An example of using a LoadBalancer service to route traffic to replicated pods
 We can use the `ghcr.io/eficode-academy/network-multitool` image to illustrate both high
 availability and load balancing of `services`. The `network-multitool` pod will serve a tiny
 webpage that dynamically contains the pod hostname and IP address of the pod. This enables us to see
-which of a group of network-multitool pods that served the request.
+which of a group of network-multitool pods served the request.
 
 Create the network-multitool deployment:
 
@@ -558,11 +556,11 @@ We also create a service of type `LoadBalancer`:
 kubectl expose deployment customnginx --port 80 --type LoadBalancer
 ```
 
-> :bulb: It might take a minute to provision the LoadBalancer, if you are using AWS, then
+> :bulb: It might take a minute to provision the LoadBalancer. If you are using AWS, then
 > `kubectl get services` will show you the DNS name of the provisioned LoadBalancer immediately, but
 > it will be a moment before it is ready.
 
-When the LoadBalancer is ready we setup a loop to keep sending requests to the pods:
+When the LoadBalancer is ready, we set up a loop to keep sending requests to the pods:
 
 ```shell
 while true; do  curl --connect-timeout 1 -m 1 -s <loadbalancerIP> ; sleep 0.5; done
@@ -578,8 +576,8 @@ Eficode Academy Network MultiTool (with NGINX) - customnginx-7fcfd947cf-zbvtd -
 Eficode Academy Network MultiTool (with NGINX) - customnginx-7fcfd947cf-zbvtd - 100.96.2.36 <BR></p>
 ```
 
-We see that when we query the LoadBalancer IP, it is giving us result/content from all four pods.
-None of the curl commands time out.
+We see that when we query the LoadBalancer IP, it is giving us results/content from all four pods.
+None of the curl commands times out.
 Now, if we kill three out of four pods, the service should still respond, without timing out.
 We let the loop run in a separate terminal, and kill three pods of this deployment from another terminal.
 
@@ -613,11 +611,11 @@ Eficode Academy Network MultiTool (with NGINX) - customnginx-59db6cff7b-h2dbg -
 Eficode Academy Network MultiTool (with NGINX) - customnginx-59db6cff7b-5xbjc - 10.244.0.22
 ```
 
-We notice that no curl commands failed, and actually we have started seeing new IPs.
+We notice that no curl commands failed, and actually, we have started seeing new IPs.
 
-Why is that? It is because, as soon as the pods are deleted, the deployment sees that it's desired
+Why is that? It is because, as soon as the pods are deleted, the deployment sees that its desired
 state is four pods, and there is only one running, so it immediately starts three more to reach the
-desired state of four pods. And, while the pods are in process of starting, one surviving pod serves
+desired state of four pods. And, while the pods are in the process of starting, one surviving pod serves
 all of the traffic, preventing our application from missing any requests.
 
 ```shell
@@ -637,8 +635,8 @@ customnginx-3557040084-fw1t3   1/1       Running       0          16m
 customnginx-3557040084-xqk1n   1/1       Running       0          15s
 ```
 
-This proves, Kubernetes enables high availability, by using multiple replicas of a pod, and
-loadbalancing between them.
+This proves, Kubernetes enables high availability by using multiple replicas of a pod, and
+load-balancing between them.
 
 Remember to clean up the deployment afterwards with: