fix spelling errors

Signed-off-by: gdha <[email protected]>

.codespellignore

@@ -1,4 +1,4 @@
 shouldnot
 ro
 rw
-upgrade-ux
+NotIn

docs/pi-stories11.md

@@ -105,7 +105,7 @@ metadata:
 EOD
 ```
 
-According the procedure to [generate a new CRD resourse file](https://metallb.universe.tf/configuration/migration_to_crds/) we got:
+According the procedure to [generate a new CRD resource file](https://metallb.universe.tf/configuration/migration_to_crds/) we got:
 
 ```bash
 $ docker run -d -v $(pwd):/var/input quay.io/metallb/configmaptocrs

docs/pi-stories13.md

@@ -255,7 +255,7 @@ Alright, now we can move on the grafana.
 
 ### Install grafana
 
-Our grafana pod will alos use a longhorn device as defined under file:
+Our grafana pod will also use a longhorn device as defined under file:
 
 ```bash
  cat grafana-pvc.yaml

docs/pi-stories14.md

@@ -172,7 +172,7 @@ In our case it is `http://10.43.220.29:3100`. Thereafter, it is kust a matter of
 
 In the side bar of Grafana click on the "Explore" button and select "Loki" in the upper left corner (of the service to use).
 
-Use Loki's "Log Lables" to select what you want to see - just play with it...
+Use Loki's "Log Labels" to select what you want to see - just play with it...
 
 ![](img/loki-log-labels.png) 
 

docs/pi-stories15.md

@@ -119,7 +119,7 @@ logging           loki-stack-promtail-nh2m7                             1/1
 graphite          graphite-0                                            1/1     Running   
 ```
 
-Repeat these steps for the remining pods which are stuck:
+Repeat these steps for the remaining pods which are stuck:
 
 ```bash
 gdha@n1:~$ kubectl delete pod grafana-544f695579-g246k --grace-period=0 --force --namespace monitoring
@@ -267,7 +267,7 @@ NAME                      READY   STATUS             RESTARTS   AGE
 ntopng-6586866d8b-w668c   0/1     ImagePullBackOff   0          69m
 ```
 
-The first thing we think of is a missmatch of our GitHub Container Registry (ghrc) Personal Access Token (PAT). How can we verify that the PAT our kubernetes cluster knows is still the same as the one listed in our `~/.ghcr-token` file?
+The first thing we think of is a mismatch of our GitHub Container Registry (ghrc) Personal Access Token (PAT). How can we verify that the PAT our kubernetes cluster knows is still the same as the one listed in our `~/.ghcr-token` file?
 
 As we know in which namespace to look (in our case ntopng) we can start digging as follow:
 

docs/pi-stories17.md

@@ -4,15 +4,15 @@
 
 ### Download the GitHub sources of ntopng
 
-We liked the [ntopng application](https://github.com/ntop/ntopng) [1] so we thought why not integrate it with our kubernetes cluster. However, the original project did not have the required code to integrate it with our kubernetes cluster, but we did find another [project](https://github.com/MySocialApp/kubernetes-helm-chart-ntopng.git) that provides a helm chart for ntopng. Yet another chalenge was building an image for arm64.
+We liked the [ntopng application](https://github.com/ntop/ntopng) [1] so we thought why not integrate it with our kubernetes cluster. However, the original project did not have the required code to integrate it with our kubernetes cluster, but we did find another [project](https://github.com/MySocialApp/kubernetes-helm-chart-ntopng.git) that provides a helm chart for ntopng. Yet another challenge was building an image for arm64.
 
 Therefore, we cloned these 2 projects into our [pi4-ntopng github project](https://github.com/gdha/pi4-ntopng) [2].
 
 We have 2 ways to build a pi4_ntopng container. One with the `build.sh` script which uses the ntopng package which available in ubuntu 20.04 repository (currently version 3.8.190813 or v1.5). The second way is building from scratch (from the sources of https://github.com/ntop/ntopng dev branch) with the script `builder.sh` which uses the development version (beginning of October 2023 it is version 5.7.0 or v1.9).
 
 ### Build pi4-ntopng with build.sh script (arm64)
 
-We builded the pi4_ntopng with the `build.sh` script that uses the ntopng executable provided by the operating system used by the container (in our case ubuntu 20). To test the image (version 3.8.190813) with docker (before trying to integrate it within kubernetes) we can do the following:
+We built the pi4_ntopng with the `build.sh` script that uses the ntopng executable provided by the operating system used by the container (in our case ubuntu 20). To test the image (version 3.8.190813) with docker (before trying to integrate it within kubernetes) we can do the following:
 
 ```bash
 $ docker run --net=host -t -p 3000:3000 ghcr.io/gdha/pi4-ntopng:v1.5

docs/pi-stories3.md

@@ -326,7 +326,7 @@ k3s version v1.26.0+k3s2 (f0ec6a4c)
 go version go1.19.4
 
 gdha@n5:~/projects/k3s-ansible$ k3s kubectl cluster-info
-ubernetes control plane is running at https://127.0.0.1:6443
+kubernetes control plane is running at https://127.0.0.1:6443
 CoreDNS is running at https://127.0.0.1:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
 Metrics-server is running at https://127.0.0.1:6443/api/v1/namespaces/kube-system/services/https:metrics-server:https/proxy
 

docs/pi-stories5.md

@@ -4,9 +4,9 @@
 
 As certificates are crucial in a kuberbetes cluster one of the first pods that one should install is [cert-manager](https://cert-manager.io/docs/installation/).
 
-### Installling cert-manager
+### Installing cert-manager
 
-Installaion is extremelt easy with the following command:
+Installation is extremelt easy with the following command:
 ```bash
 kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v1.11.0/cert-manager.yaml
 ```

docs/pi-stories6.md

@@ -2,7 +2,7 @@
 
 ## Raspberry Pi 4 cluster Series - Upgrading k3s software on your cluster
 
-It is advisable to track the security vulnarabilities published by Rancher Labs around k3s. For example, in November 2020 a critical bug was detected in k3s (see [1]). Therefore, it is quite important to be able to update k3s without interupting the k3s cluster, hence this procedure from Rancher Labs.
+It is advisable to track the security vulnerabilities published by Rancher Labs around k3s. For example, in November 2020 a critical bug was detected in k3s (see [1]). Therefore, it is quite important to be able to update k3s without interrupting the k3s cluster, hence this procedure from Rancher Labs.
 
 ```bash
 $ kubectl get nodes

docs/pi-stories7.md

@@ -8,7 +8,7 @@ Writing YAML code from scratch is not a real pleasure, therefore, having a linte
 
 Therefore, we decided to build it ourselves from the sources.
 
-### Installling the Go Language binaries
+### Installing the Go Language binaries
 
 On our node *n1* we installed the Go Language with the commands:
 
@@ -76,7 +76,7 @@ $ kube-linter lint ../k3s-upgrade-controller/
 Error: found 6 lint errors
 ```
 
-The recommendations are perhaps not really perfect for this example as we do need a writable file system to be able to perform an update and `root` permissions will be required as well. However, the test itself was successful as it produces a meaningfull output.
+The recommendations are perhaps not really perfect for this example as we do need a writable file system to be able to perform an update and `root` permissions will be required as well. However, the test itself was successful as it produces a meaningful output.
 
 For a more profound usage of `kube-linter` see the "[KubeLinter documentation](https://docs.kubelinter.io/#/)" [4].
 
@@ -88,4 +88,4 @@ For a more profound usage of `kube-linter` see the "[KubeLinter documentation](h
 
 [3] [CRD system-upgrade-controller](https://github.com/gdha/k3s-upgrade-controller/blob/main/system-upgrade-controller.yaml)
 
-[4] [KubeLinter Documenation](https://docs.kubelinter.io/#/)
+[4] [KubeLinter Documentation](https://docs.kubelinter.io/#/)