Starting again to fix the issues (#2625)

- edit all lab files
- All files
  + replace passive voice with active
  + replace contractions with words
  + replace we with you

docs/labs/kubernetes-the-hard-way/lab0-README.md

@@ -4,11 +4,10 @@ author: Wale Soyinka
 contributors: Steven Spencer
 ---
 
-This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower).
-Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture.
-
 # Kubernetes The Hard Way (Rocky Linux)
 
+> This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture.
+
 This tutorial walks you through setting up Kubernetes the hard way. This guide is not for someone looking for a fully automated tool to bring up a Kubernetes cluster. Kubernetes The Hard Way, designed for learning, means taking the long route to ensure you understand each task required to bootstrap a Kubernetes cluster.
 
 Do not view the results of this tutorial as production ready, and it might not receive support from the community, but do not let that stop you from learning!

docs/labs/kubernetes-the-hard-way/lab1-prerequisites.md

@@ -7,11 +7,10 @@ tags:
   - lab exercise
 ---
 
-This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower).
-Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture.
-
 # Lab 1: Prerequisites
 
+> This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture.
+
 In this lab you will review the machine requirements necessary to follow this tutorial.
 
 ## Virtual or Physical Machines

docs/labs/kubernetes-the-hard-way/lab10-configuring-kubectl.md

@@ -11,11 +11,9 @@ tags:
   - kubectl
 ---
 
-This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower).
-Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture.
+# Lab 10: Configuring `kubectl` for Remote Access
 
-
-# Lab 10: Configuring kubectl for Remote Access
+> This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture.
 
 In this lab you will generate a kubeconfig file for the `kubectl` command line utility based on the `admin` user credentials.
 
@@ -25,7 +23,7 @@ In this lab you will generate a kubeconfig file for the `kubectl` command line u
 
 Each kubeconfig requires a Kubernetes API Server to connect to.
 
-You should be able to ping `server.kubernetes.local` based on the `/etc/hosts` DNS entry from a previous lap.
+You should be able to ping `server.kubernetes.local` based on the `/etc/hosts` DNS entry from an earlier lab.
 
 ```bash
 curl -k --cacert ca.crt \
@@ -64,8 +62,8 @@ Generate a kubeconfig file suitable for authenticating as the `admin` user:
 
   kubectl config use-context kubernetes-the-hard-way
 ```
-The results of running the command above should create a kubeconfig file in the default location `~/.kube/config` used by the  `kubectl` commandline tool. This also means you can run the `kubectl` command without specifying a config.
 
+The results of running the command above should create a kubeconfig file in the default location `~/.kube/config` used by the  `kubectl` command line tool. This also means you can run the `kubectl` command without specifying a config.
 
 ## Verification
 
@@ -87,7 +85,7 @@ List the nodes in the remote Kubernetes cluster:
 kubectl get nodes
 ```
 
-```
+```text
 NAME     STATUS   ROLES    AGE   VERSION
 node-0   Ready    <none>   30m   v1.31.2
 node-1   Ready    <none>   35m   v1.31.2

docs/labs/kubernetes-the-hard-way/lab11-pod-network-routes.md

@@ -11,12 +11,11 @@ tags:
   - kubectl
 ---
 
-This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower).
-Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture.
-
 # Lab 11: Provisioning Pod Network Routes
 
-Pods scheduled to a node receive an IP address from the node's Pod CIDR range. At this point pods can not communicate with other pods running on different nodes due to missing network [routes](https://cloud.google.com/compute/docs/vpc/routes).
+> This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture.
+
+Pods scheduled to a node receive an IP address from the node's Pod CIDR range. At this point pods cannot communicate with other pods running on different nodes due to missing network [routes](https://cloud.google.com/compute/docs/vpc/routes).
 
 In this lab you will create a route for each worker node that maps the node's Pod CIDR range to the node's internal IP address.
 
@@ -57,7 +56,7 @@ ssh root@node-1 <<EOF
 EOF
 ```
 
-## Verification 
+## Verification
 
 ```bash
 ssh root@server ip route
@@ -90,5 +89,4 @@ default via XXX.XXX.XXX.XXX dev ens160
 XXX.XXX.XXX.0/24 dev ens160 proto kernel scope link src XXX.XXX.XXX.XXX 
 ```
 
-
 Next: [Smoke Test](lab12-smoke-test.md)

docs/labs/kubernetes-the-hard-way/lab12-smoke-test.md

@@ -11,11 +11,10 @@ tags:
   - kubectl
 ---
 
-This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower).
-Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture.
-
 # Lab 12: Smoke Test
 
+> This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture.
+
 In this lab you will complete a series of tasks to ensure your Kubernetes cluster is functioning correctly.
 
 ## Data Encryption
@@ -29,7 +28,7 @@ kubectl create secret generic kubernetes-the-hard-way \
   --from-literal="mykey=mydata"
 ```
 
-Print a hexdump of the `kubernetes-the-hard-way` secret stored in etcd:
+Print a hexdump of the `kubernetes-the-hard-way` secret stored in `etcd`:
 
 ```bash
 ssh root@server \
@@ -62,7 +61,7 @@ ssh root@server \
 0000015a
 ```
 
-The etcd key should be prefixed with `k8s:enc:aescbc:v1:key1`, which indicates the `aescbc` provider was used to encrypt the data with the `key1` encryption key.
+You need to prefix the `etcd` key with `k8s:enc:aescbc:v1:key1`, which indicates using the `aescbc` provider to encrypt the data with the `key1` encryption key.
 
 ## Deployments
 
@@ -108,7 +107,7 @@ Forwarding from 127.0.0.1:8080 -> 80
 Forwarding from [::1]:8080 -> 80
 ```
 
-In a new terminal make an HTTP request using the forwarding address:
+In a new terminal make an HTTP request with the forwarding address:
 
 ```bash
 curl --head http://127.0.0.1:8080
@@ -126,7 +125,7 @@ ETag: "67a34638-267"
 Accept-Ranges: bytes
 ```
 
-Switch back to the previous terminal and stop the port forwarding to the `nginx` pod by typing `[CTRL]` + `[C]`:
+Switch back to the previous terminal and stop the port forwarding to the `nginx` pod by typing ++ctrl+c++:
 
 ```text
 Forwarding from 127.0.0.1:8080 -> 80
@@ -154,7 +153,7 @@ kubectl logs $POD_NAME
 
 In this section you will verify the ability to [execute commands in a container](https://kubernetes.io/docs/tasks/debug-application-cluster/get-shell-running-container/#running-individual-commands-in-a-container).
 
-Print the nginx version by executing the `nginx -v` command in the `nginx` container:
+Print the `nginx` version by executing the `nginx -v` command in the `nginx` container:
 
 ```bash
 kubectl exec -ti $POD_NAME -- nginx -v
@@ -166,7 +165,7 @@ nginx version: nginx/1.27.4
 
 ## Services
 
-In this section you will verify the ability to expose applications using a [Service](https://kubernetes.io/docs/concepts/services-networking/service/).
+In this section you will verify the ability to expose applications with a [Service](https://kubernetes.io/docs/concepts/services-networking/service/).
 
 Expose the `nginx` deployment using a [NodePort](https://kubernetes.io/docs/concepts/services-networking/service/#type-nodeport) service:
 
@@ -175,7 +174,7 @@ kubectl expose deployment nginx \
   --port 80 --type NodePort
 ```
 
-> The LoadBalancer service type can not be used because your cluster is not configured with [cloud provider integration](https://kubernetes.io/docs/getting-started-guides/scratch/#cloud-provider). Setting up cloud provider integration is out of scope for this tutorial.
+> You cannot use the LoadBalancer service type because your cluster is not configured with [cloud provider integration](https://kubernetes.io/docs/getting-started-guides/scratch/#cloud-provider). Setting up cloud provider integration is out of scope for this tutorial.
 
 Retrieve the node port assigned to the `nginx` service:
 
@@ -184,9 +183,7 @@ NODE_PORT=$(kubectl get svc nginx \
   --output=jsonpath='{range .spec.ports[0]}{.nodePort}')
 ```
 
-
-
-Make an HTTP request using the IP address and the `nginx` node port:
+Make an HTTP request with the IP address and the `nginx` node port:
 
 ```bash
 curl -I http://node-0:${NODE_PORT}

docs/labs/kubernetes-the-hard-way/lab13-cleanup.md

@@ -7,17 +7,15 @@ tags:
   - lab exercise
 ---
 
-This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower).
-Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture.
-
-
 # Lab 13: Cleaning Up
 
+> This is a fork of the original ["Kubernetes the hard way"](https://github.com/kelseyhightower/kubernetes-the-hard-way) originally written by Kelsey Hightower (GitHub: kelseyhightower). Unlike the original that bases itself on Debian like distributions for the ARM64 architecture, this fork targets Enterprise Linux distributions such as Rocky Linux running on x86_64 architecture.
+
 In this lab you will delete the compute resources created during this tutorial.
 
 ## Compute Instances
 
-Previous versions of this guide made use of GCP resources for various aspects of compute and networking. The current version is agnostic, and all configuration is performed on the `jumpbox`, `server`, or nodes.
+Previous versions of this guide made use of GCP resources for various aspects of compute and networking. The current version is agnostic, and you perform all configurations on the `jumpbox`, `server`, or nodes.
 
 Clean up is as simple as deleting all virtual machines you created for this exercise.
 

docs/labs/kubernetes-the-hard-way/lab2-jumpbox.md

@@ -1,12 +1,12 @@
 ---
 author: Wale Soyinka 
+contributors: Steven Spencer
 tags:
   - kubernetes
   - k8s
   - lab exercise
 ---
 
-
 # Lab 2: Set Up The Jumpbox
 
 In this lab you will set up one of the four machines to be a `jumpbox`. You will use this machine to run commands in this tutorial. While the use of a dedicated machine is to ensure consistency, you can run these commands from just about any machine, including your personal workstation running macOS or Linux.
@@ -56,7 +56,7 @@ pwd
 
 ## Download Binaries
 
-Here you will download the binaries for the various Kubernetes components. Store these binaries in the `Downloads` directory on the `jumpbox`. This will reduce the amount of internet bandwidth required to complete this tutorial as you avoid downloading the binaries multiple times for each machine in our Kubernetes cluster.
+Here you will download the binaries for the various Kubernetes components. Store these binaries in the `Downloads` directory on the `jumpbox`. This will reduce the amount of internet bandwidth required to complete this tutorial as you avoid downloading the binaries many times for each machine in our Kubernetes cluster.
 
 The `download.txt` file lists the binaries you will download, which you can review using the `cat` command:
 
@@ -95,7 +95,7 @@ total 557M
 -rw-r--r--. 1 root 11M Feb 13 20:19 runc.amd64
 ```
 
-## Install kubectl
+## Install `kubectl`
 
 In this section you will install the `kubectl`, the official Kubernetes client command line tool, on the `jumpbox` machine. You will use `kubectl` to interact with the Kubernetes control plane after provisioning of your cluster completes later in this tutorial.
 

docs/labs/kubernetes-the-hard-way/lab3-compute-resources.md

@@ -1,5 +1,6 @@
 ---
 author: Wale Soyinka 
+contributors: Steven Spencer
 tags:
   - kubernetes
   - k8s
@@ -42,7 +43,7 @@ You will use SSH to configure the machines in the cluster. Verify that you have
 
 If you have `root` SSH access for each of your machines you can skip this section.
 
-By default, a new `Rocky Linux` install disables SSH access for the `root` user. This is for security reasons, as the `root` user has total administrative control of unix-like systems. Weak passwords are very bad for internet connected machines. As mentioned earlier, you are going to enable `root` access over SSH to streamline the steps in this tutorial. Security is a trade-off, and in this case, you are optimizing for convenience. 
+By default, a new `Rocky Linux` install disables SSH access for the `root` user. This is for security reasons, as the `root` user has total administrative control of unix-like systems. Weak passwords are very bad for internet connected machines. As mentioned earlier, you are going to enable `root` access over SSH to streamline the steps in this tutorial. Security is a trade-off, and in this case, you are optimizing for convenience.
 
 Log on to each machine using SSH and your user account, then switch to the `root` user with the `su` command:
 

docs/labs/kubernetes-the-hard-way/lab4-certificate-authority.md

@@ -1,29 +1,37 @@
 ---
 author: Wale Soyinka 
+contributors: Steven Spencer
 tags:
   - kubernetes
   - k8s
   - lab exercise
 ---
 
-
 # Lab 4: Provisioning a CA and Generating TLS Certificates
 
-In this lab you will provision a [PKI Infrastructure](https://en.wikipedia.org/wiki/Public_key_infrastructure) using openssl to bootstrap a Certificate Authority, and generate TLS certificates for the following components: kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, and kube-proxy. The commands in this section should be run from the `jumpbox`.
+In this lab you will provision a [PKI Infrastructure](https://en.wikipedia.org/wiki/Public_key_infrastructure) using openssl to bootstrap a Certificate Authority, and generate TLS certificates for the following components:
+
+* kube-apiserver
+* kube-controller-manager
+* kube-scheduler
+* kubelet
+* kube-proxy
+
+Run commands in this section from the `jumpbox`.
 
 ## Certificate Authority
 
-In this section you will provision a Certificate Authority that can be used to generate additional TLS certificates for the other Kubernetes components. Setting up CA and generating certificates using `openssl` can be time-consuming, especially when doing it for the first time. To streamline this lab, I've included an openssl configuration file `ca.conf`, which defines all the details needed to generate certificates for each Kubernetes component. 
+In this section you will provision a Certificate Authority that you will use to generate additional TLS certificates for the other Kubernetes components. Setting up CA and generating certificates with `openssl` can be time-consuming, especially when doing it for the first time. To streamline this lab,  the inclusion of an `openssl` configuration file, `ca.conf`, defines all the details needed to generate certificates for each Kubernetes component.
 
 Take a moment to review the `ca.conf` configuration file:
 
 ```bash
 cat ca.conf
 ```
 
-You don't need to understand everything in the `ca.conf` file to complete this tutorial, but you should consider it a starting point for learning `openssl` and the configuration that goes into managing certificates at a high level.
+You do not need to understand everything in the `ca.conf` file to complete this tutorial, but you should consider it a starting point for learning `openssl` and the configuration that goes into managing certificates at a high level.
 
-Every certificate authority starts with a private key and root certificate. In this section we are going to create a self-signed certificate authority, and while that's all we need for this tutorial, this shouldn't be considered something you would do in a real-world production environment.
+Every certificate authority starts with a private key and root certificate. In this section you are going to create a self-signed certificate authority, and while that is all you need for this tutorial, this is something you should not consider in a real-world production environment.
 
 Generate the CA configuration file, certificate, and private key:
 
@@ -41,7 +49,8 @@ Results:
 ca.crt ca.key
 ```
 
-!!! Tip:
+!!! Tip
+
     To view the details encoded in the generated certificate file (ca.crt), you can use this openssl command `openssl x509 -in ca.crt -text -noout | less`.  
 
 ## Create Client and Server Certificates
@@ -85,7 +94,7 @@ ls -1 *.crt *.key *.csr
 
 ## Distribute the Client and Server Certificates
 
-In this section you will copy the various certificates to every machine at a path where each Kubernetes component will search for its certificate pair. In a real-world environment these certificates should be treated like a set of sensitive secrets as they are used as credentials by the Kubernetes components to authenticate to each other.
+In this section you will copy the various certificates to every machine at a path where each Kubernetes component will search for its certificate pair. In a real-world environment, you would treat these certificates as a set of sensitive secrets, because Kubernetes uses these components as credentials to authenticate to each other.
 
 Copy the appropriate certificates and private keys to the `node-0` and `node-1` machines:
 
@@ -113,6 +122,6 @@ scp \
   root@server:~/
 ```
 
-> The `kube-proxy`, `kube-controller-manager`, `kube-scheduler`, and `kubelet` client certificates will be used to generate client authentication configuration files in the next lab.
+> You will use the `kube-proxy`, `kube-controller-manager`, `kube-scheduler`, and `kubelet` client certificates to generate client authentication configuration files in the next lab.
 
 Next: [Generating Kubernetes Configuration Files for Authentication](lab5-kubernetes-configuration-files.md)