Fixed typos

Author: ewoutp

docs/Manual/Deployment/Kubernetes/DriverConfiguration.md

@@ -103,7 +103,7 @@ Note that even a simple `Service` of type `ClusterIP` already behaves as a load-
 The exception to this is cursor related requests made to an ArangoDB `Cluster` deployment.
 The coordinator that handles an initial query request (that results in a `Cursor`)
 will save some in-memory state in that coordinator, if the result of the query
-is to big to be transfer back in the response of the initial request.
+is too big to be transfer back in the response of the initial request.
 
 Follow-up requests have to be made to fetch the remaining data.
 These follow-up requests must be handled by the same coordinator to which the initial
@@ -116,7 +116,7 @@ To resolve this uncertainty, make sure to run your client application in the sam
 Kubernetes cluster and synchronize your endpoints before making the
 initial query request.
 This will result in the use (by the driver) of internal DNS names of all coordinators.
-A follow-up request can then be send to exaclty the same coordinator.
+A follow-up request can then be sent to exactly the same coordinator.
 
 If your client application is running outside the Kubernetes cluster this is much harder
 to solve.

docs/Manual/Deployment/Kubernetes/Storage.md

@@ -11,7 +11,7 @@ used by groups of servers using the `spec.<group>.storageClassName`
 setting.
 
 This is an example of a `Cluster` deployment that stores its agent & dbserver
-data on `PersistentVolumes` that using the `my-local-ssd` `StorageClass`
+data on `PersistentVolumes` that use the `my-local-ssd` `StorageClass`
 
 ```yaml
 apiVersion: "database.arangodb.com/v1alpha"

docs/Manual/Deployment/Kubernetes/Troubleshooting.md

@@ -44,11 +44,11 @@ Another invaluable source of information is the log of containers being run
 in Kubernetes.
 These logs are accessible through the `Pods` that group these containers.
 
-The fetch the logs of the default container running in a `Pod`, run:
+To fetch the logs of the default container running in a `Pod`, run:
 
 ```bash
 kubectl logs <pod-name> -n <namespace>
-# or with follow option to keep inspecting logs while their are written
+# or with follow option to keep inspecting logs while they are written
 kubectl logs <pod-name> -n <namespace> -f
 ```
 
@@ -67,7 +67,7 @@ those replicas.
 
 There are two common causes for this.
 
-1) The `Pods` cannot be scheduled because there are no enough nodes available.
+1) The `Pods` cannot be scheduled because there are not enough nodes available.
    This is usally only the case with a `spec.environment` setting that has a value of `Production`.
 
    Solution: Add more nodes.
@@ -101,7 +101,7 @@ those `PersistentVolumes`, it depends on the type of server that was using the v
 
 - If an `Agent` was using the volume, it can be repaired as long as 2 other agents are still     healthy.
 - If a `DBServer` was using the volume, and the replication factor of all database
-  collections is 2 of higher, and the remaining dbservers are still healthy,
+  collections is 2 or higher, and the remaining dbservers are still healthy,
   the cluster will duplicate the remaining replicas to
   bring the number of replicases back to the original number.
 - If a `DBServer` was using the volume, and the replication factor of a database