Merge pull request #150 from Eelinki/fix-typos

Fix typos

data/faq.md

@@ -17,7 +17,7 @@ As this course was written by a developer it offers an introduction into Kuberne
 
 Eeveryone starting with Google Cloud has \$300 worth of free credits.
 
-If ypu have used all \$300 credits there is nothing we can do. You can complete parts 1-2 and most likely 4-5, but part 3 is required to complete the course with higher grades
+If you have used all \$300 credits there is nothing we can do. You can complete parts 1-2 and most likely 4-5, but part 3 is required to complete the course with higher grades
 You may also use another cloud provider but we can not provide any help in that case.
 
 ### CKAD or CKA

data/part-1/4-introduction-to-storage.md

@@ -145,9 +145,9 @@ Let us now create a claim for our app:
 apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
-  name: image-claim # name of ther volume claim, this will be used in the deployment
+  name: image-claim # name of the volume claim, this will be used in the deployment
 spec:
-  storageClassName: my-example-pv # this is the name of the persisten volume we are claiming
+  storageClassName: my-example-pv # this is the name of the persistent volume we are claiming
   accessModes:
     - ReadWriteOnce
   resources:

data/part-2/1-networking-between-pods.md

@@ -16,7 +16,7 @@ After this section
 
 In part 1 we managed to setup networking configuration to enable routing traffic from outside of the cluster to a container inside a pod. In Part 2 we'll focus on communication between pods.
 
-Kubernetes includes a DNS service so communication between pods and containers in Kubernetes is pretty simillar as it was with containers in Docker compose. Containers in a pod share the network. As such every other container inside a pod is accessible from `localhost`. For communication between Pods a _Service_ is used as they expose the Pods as a network service.
+Kubernetes includes a DNS service so communication between pods and containers in Kubernetes is pretty similar as it was with containers in Docker compose. Containers in a pod share the network. As such every other container inside a pod is accessible from `localhost`. For communication between Pods a _Service_ is used as they expose the Pods as a network service.
 
 The following service, taken from an exercise in last part, creates a cluster-internal IP which will enable other pods in the cluster to access the port 3000 of _todo-backend_ application in http://todo-backend-svc:2345.
 

data/part-3/2-deployment-pipeline.md

@@ -142,7 +142,7 @@ $ kubectl kustomize .
 
 Kustomize has a few additional tools you can test out if you want to install it - but we'll see the usage in the next section.
 
-The documentation of Kustomize in propably not the best one around. You will find more or less usefull stuff by Google. One that you might want to check out is [Kustomize Cheat Sheet](https://itnext.io/kubernetes-kustomize-cheat-sheet-8e2d31b74d8f).
+The documentation of Kustomize in probably not the best one around. You will find more or less useful stuff by Google. One that you might want to check out is [Kustomize Cheat Sheet](https://itnext.io/kubernetes-kustomize-cheat-sheet-8e2d31b74d8f).
 
 ### Github Actions
 
@@ -191,7 +191,7 @@ jobs:
 
 This sets the environment for the job and triggers the [checkout action](https://github.com/actions/checkout) as the first step.
 
-Next we'll use some additional actions, mainly from [google-github-actions](https://github.com/google-github-actions) that are designed to help on deployments to Google Cloud. We'll start with [authenticaton](https://github.com/google-github-actions/auth), followed by [setup](https://github.com/google-github-actions/setup-gcloud):
+Next we'll use some additional actions, mainly from [google-github-actions](https://github.com/google-github-actions) that are designed to help on deployments to Google Cloud. We'll start with [authentication](https://github.com/google-github-actions/auth), followed by [setup](https://github.com/google-github-actions/setup-gcloud):
 
 ```yaml
 # ...
@@ -261,7 +261,7 @@ And finally let's write out the desired image with a tag. The image will be `gcr
 
 We use the project name (from the env _$IMAGE_) as the image name and the tag is formed by concatenating the branch name, that comes from the env that we defined and the GitHub commit _sha_ that is taken from env *$GITHUB_SHA*, that is automatically provided by the workflow.
 
-Publish similarily:
+Publish similarly:
 
 ```yaml
 # ...

data/part-5/3-service-mesh.md

@@ -32,7 +32,7 @@ Let's install a service mesh and test the features. Our choice will be [Linkerd]
 Linkerd has a CLI tool to help us, follow now the [getting started](https://linkerd.io/2/getting-started/) guide until Step 4.
 
 <text-box name="Alternate sources" variant="hint">
- We are actually simply following through the whole gettings started guide, so you can read through it if you wish.
+ We are actually simply following through the whole getting started guide, so you can read through it if you wish.
 </text-box>
 
 Let's look at our application, this time we'll use this microservice application for voting emojis: [https://github.com/BuoyantIO/emojivoto](https://github.com/BuoyantIO/emojivoto).