Fix typos and rephrase some things

Author: dragetd

README.md

@@ -1,6 +1,6 @@
 # Preface
 
-In a perfect world every written service will work smooth, your test coverage is on top and there are no bugs in your API. But we all know, that we can't achieve this world, sadly. It's not unusual that there's a bug in an API and you have to debug this problem in a production environment. We have faced this problem with our go services in our Kubernetes cluster and we want to show you how it's possible to remote debug a go service in a Kubernetes cluster.
+In a perfect world every written service will work smooth, your test coverage is on top and there are no bugs in your API. But we all know, that we can't achieve this world, sadly. It's not unusual that there's a bug in an API and you have to debug this problem in a production environment. We have faced this problem with our go services in our Kubernetes cluster, and we want to show you how it's possible to remote debug a go service in a Kubernetes cluster.
 
 ## Software Prerequisites
 
@@ -11,18 +11,16 @@ For this scenario we need some software:
 * [Kubectl](https://kubernetes.io/de/docs/tasks/tools/install-kubectl) (used version: 1.17.2)
 * [Visual Studio Code](https://code.visualstudio.com/download) (used version: 1.32.3)
 
-We decided to use `kind` instead of `minikube`, since it's a very good tool for testing Kubernetes locally and we can use our docker images without a docker registry.
+We decided to use `kind` instead of `minikube`, since it's a very good tool for testing Kubernetes locally, and we can use our docker images without a docker registry.
 
 ## Big Picture
 
-First we will briefly explain how it works:
+First we will briefly explain how it works. We start by creating a new Kubernetes cluster `local-debug-k8s` on our local system.
 
-1. We create a new Kubernetes cluster `local-debug-k8s` on our local system
-
-* you need a docker container with [delve](https://github.com/go-delve/delve) (the go debugger) as the main process
-* delve needs access to the path with the project data. This is done by mounting `$GOPATH/src` on the pod which is running in the Kubernetes cluster
-* we start the delve container on port 30123 and bind this port to localhost, so that only our local debugger can communicate with delve
-* to debug an API with delve, it's necessary to set up an ingress network. For this we use port 8090.
+* You need a docker container with [delve](https://github.com/go-delve/delve) (the go debugger) as the main process.
+* The debugger delve needs access to the path with the project data. This is done by mounting `$GOPATH/src` on the pod which is running in the Kubernetes cluster.
+* We start the delve container on port 30123 and bind this port to localhost, so that only our local debugger can communicate with delve.
+* To debug an API with delve, it's necessary to set up an ingress network. For this we use port 8090.
 
 A picture serves to illustrate the communication:
 
@@ -69,7 +67,7 @@ nodes:
       containerPath: /go/src # path to the project folder inside the worker node
 ```
 
-Desired result:
+Expected result:
 
 ```sh
 Creating cluster "local-debug-k8s" ...
@@ -97,23 +95,23 @@ Activate the kube-context for `kubectl` to communicate with the new cluster:
 
 #### Install nginx-ingress
 
-For both ports (8090 and 30123) to work it's necessary to deploy a nginx controller:
+For both ports (8090 and 30123) to work, it is necessary to deploy an nginx controller:
 
 ```sh
 kubectl create -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/master/deploy/static/provider/kind/deploy.yaml
 ```
 
 Source: [kind documentation](https://kind.sigs.k8s.io/docs/user/ingress/#ingress-nginx>)
 
-...and wait until nginx-controller runs:
+And wait until the nginx-controller runs:
 
 ```sh
 kubectl wait --namespace ingress-nginx --for=condition=ready pod --selector=app.kubernetes.io/component=controller --timeout=120s
 ```
 
 #### Labelling the worker node
 
-We would suggest to label a worker node where the pod is going to be deployed: by default, a pod is deployed on one of several worker nodes you might have in the kind cluster. To make it work the docker image must be populated on all worker nodes in the cluster (it takes time). Otherwise, you can get into a situation, in which the pod is started on a node where the docker image is missing. Let's work with a dedicated node and safe the time.
+We suggest labelling a worker node where the pod is going to be deployed. By default, a pod is deployed on one of several worker nodes you might have in the kind cluster. To make it work, the docker image must be populated on all worker nodes in the cluster (which takes time). Otherwise, you can get into a situation, in which the pod has started on a node where the docker image is missing. Let's work with a dedicated node and safe the time.
 
 So, we label a worker node with _debug=true_:
 
@@ -144,15 +142,15 @@ RUN apk update && apk add git && \
 ENTRYPOINT ["/go/bin/dlv", "debug", ".", "--listen=:30123", "--accept-multiclient", "--headless=true", "--api-version=2"]
 ```
 
-Build the docker image locally, first:
+First, build the docker image locally:
 
 `docker build -t setlog/debug-k8s .`
 
-Load the docker image into the node _local-debug-k8s-worker_
+Load the docker image into the node _local-debug-k8s-worker_:
 
 `kind load docker-image setlog/debug-k8s:latest --name=local-debug-k8s --nodes=local-debug-k8s-worker`
 
-This message will be shown and it is just saying that the image was not there:
+This message will be shown, and it is just saying that the image was not there:
 
     Image: "setlog/debug-k8s:latest" with ID "sha256:944baa03d49698b9ca1f22e1ce87b801a20ce5aa52ccfc648a6c82cf8708a783" not present on node "local-debug-k8s-worker"
 
@@ -169,7 +167,7 @@ The interesting part here is:
     path: /go/src
 ```
 
-Lets take a look at the full chain of mounting the local project path into the pod, since you want probably to adjust them to your environment:
+Let's take a look at the full chain of mounting the local project path into the pod, since you want probably to adjust them to your environment:
 
 ![Mounting](images/mounting.png "How to mount the project folder")
 
@@ -180,13 +178,13 @@ Check, if your persistent volume claim has been successfully created (STATUS mus
     NAME     STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
     go-pvc   Bound    go-pv    256Mi      RWO            hostpath       51s
 
-You are ready to start the service in the debug mode:
+You are ready to start the service in debug mode:
 
 `kubectl create -f cluster/deploy-service.yaml`
 
 Let's go through the deployment.
 
-* Image name is what we loaded into the kind cluster with the command `kind load image...`. _imagePullPolicy_ must be set to _IfNotPresent_, because it is already loaded there and we don't want Kubernetes to try doing it once more.
+* Image name is what we loaded into the kind cluster with the command `kind load image...`. _imagePullPolicy_ must be set to _IfNotPresent_, because it is already loaded, we don't want Kubernetes to try loading it again.
 
           image: setlog/debug-k8s:latest
           imagePullPolicy: IfNotPresent
@@ -209,7 +207,7 @@ Let's go through the deployment.
       nodeSelector:
         debug: "true"
 
-* Service _service-debug_ has the type _NodePort_ and is mounted into the worker node. This port 30123 is equal to the parameter _--listen=:30123_ in the Dockerfile, what makes possible to send debug commands to the delve server.
+* Service _service-debug_ has the type _NodePort_ and is mounted into the worker node. This port 30123 is equal to the parameter _--listen=:30123_ in the Dockerfile, which makes it possible to send debug commands to the delve server.
 
 * Service _debug-k8s_ will be connected to the ingress server in the final step. It serves for exposing the API endpoints we are going to debug.
 
@@ -225,18 +223,17 @@ service/kubernetes      ClusterIP   10.96.0.1      <none>        443/TCP
 service/service-debug   NodePort    10.96.219.86   <none>        30123:30123/TCP   1h
 ```
 
-_Hint: create a new variable to store the pod name. It can be helpful, if you repeatedly debug the pod_
-        `PODNAME=$(kubectl get pod -o jsonpath='{.items[0].metadata.name}')`
+_Hint: create a new variable to store the pod name using `PODNAME=$(kubectl get pod -o jsonpath='{.items[0].metadata.name}')`. It can be helpful, if you repeatedly debug the pod._
 
-Usualy it takes a couple of seconds to start the debugging process with delve. If your paths are mounted in the proper way, you will find the file `__debug_bin` in the project path on your computer. That is an executable which has been created by delve.
+Usually it takes a couple of seconds to start the debugging process with delve. If your paths are mounted in the proper way, you will find the file `__debug_bin` in the project path on your computer. That is an executable which has been created by delve.
 
-Also, you can output logs of the pod by performing `kubectl logs $PODNAME` in order to make sure that the delve API server is listening at 30123.
+Also, you can output logs of the pod by performing `kubectl logs $PODNAME` in order to make sure the delve API server is listening at 30123.
 
 Output:
 
         API server listening at: [::]:30123
 
-_Hint: always wait until this log message is shown for this pod before you start the debugging process. Otherwise the delve server is not up yet and cannot answer to the debugger_
+_Hint: always wait until this log message is shown for this pod before you start the debugging process. Otherwise, the delve server is not up yet and cannot answer to the debugger._
 
 ### Starting the debug process via launch.json
 
@@ -272,11 +269,11 @@ We are ready to debug, but we have to trigger the API functions through the ingr
 
 `kubectl create -f cluster/ingress.yaml`
 
-...and try it now:
+And try accessing it now:
 
 `curl http://localhost:8090/hello`
 
-Here you go:
+Which should trigger the debugger:
 
 ![Breakpoint](images/debug-screen.png "Breakpoint in Visual Code")