Fix typos

Signed-off-by: Billy Tat <btat@suse.com>

Author: btat

docs/add-ons/helm.md

@@ -58,7 +58,7 @@ Chart values are used in the following order, from least to greatest precedence:
 4. HelmChartConfig `spec.valuesSecrets` in listed order of secret name and keys
 5. HelmChart `spec.set`
 
-Here's an example of how you might deploy Apache from the Bitnami chart repository, overriding some of the default chart values. Note that the HelmChart resource itself is in the `kube-system` namespace, but the chart's resources will be deployed to the `web` namespace, which is created in the same manifest. This can be useful if you want to keep your HelmChart resources separated from the the resources they deploy.
+Here's an example of how you might deploy Apache from the Bitnami chart repository, overriding some of the default chart values. Note that the HelmChart resource itself is in the `kube-system` namespace, but the chart's resources will be deployed to the `web` namespace, which is created in the same manifest. This can be useful if you want to keep your HelmChart resources separated from the resources they deploy.
 
 ```yaml
 apiVersion: v1

docs/cli/etcd-snapshot.md

@@ -148,7 +148,7 @@ The S3 config Secret cannot be used when restoring a snapshot, as the apiserver
 S3 configuration must be passed via the CLI when restoring a snapshot stored on S3.
 
 :::note
-Pass only the the `--etcd-s3` and `--etcd-s3-config-secret` flags to enable the Secret.  
+Pass only the `--etcd-s3` and `--etcd-s3-config-secret` flags to enable the Secret.  
 If any other S3 configuration flags are set, the Secret will be ignored.
 :::
 

docs/installation/private-registry.md

@@ -255,7 +255,7 @@ In order for the registry changes to take effect, you need to restart K3s on eac
 When Kubernetes experiences problems pulling an image, the error displayed by the kubelet may only reflect the terminal error returned
 by the pull attempt made against the default endpoint, making it appear that the configured endpoints are not being used.
 
-Check the containerd log on the node at `/var/lib/rancher/k3s/agent/containerd/containerd.log` for detailed information on the root cause of the failure. Note that you must look at the logs on the node where the pod was scheduled. You can check which node your pod was scheduled to by issuing `kubectl get pod -o wide -n NAMESPACE POD` and checking the the NODE column.
+Check the containerd log on the node at `/var/lib/rancher/k3s/agent/containerd/containerd.log` for detailed information on the root cause of the failure. Note that you must look at the logs on the node where the pod was scheduled. You can check which node your pod was scheduled to by issuing `kubectl get pod -o wide -n NAMESPACE POD` and checking the NODE column.
 
 ## Adding Images to the Private Registry