Fix cspell linter issue on rfd 185 (#51990)

rfd/0185-k8s-access-non-cert-routing.md

@@ -28,11 +28,11 @@ client certificate must be issued for each Kubernetes cluster that you wish to
 connect to. This is because an attribute is encoded within the certificate to
 assist with routing.
 
-The need to issue a certificate per cluster becomes a problem when wishing to 
+The need to issue a certificate per cluster becomes a problem when wishing to
 connect to a large number of clusters for the following reasons:
 
 - Increased pressure on the Auth Server. Certificate signing is an expensive
-  operation and requesting the signing of hundreds of certificates within a 
+  operation and requesting the signing of hundreds of certificates within a
   short period of time threatens to overwhelm the Auth Server.
 - Less flexibility. If a short-lived Kubernetes cluster is spun up, then a new
   certificate must be issued for that cluster. This means that `tbot` must be
@@ -48,9 +48,9 @@ We're currently talking to a user who has the need to connect to 100s of
 Kubernetes clusters from a single-host to enable the Kubernetes platform team
 to manage and monitor clusters across the organization.
 
-For users who do not leverage Machine ID, there are still some benefits of 
+For users who do not leverage Machine ID, there are still some benefits of
 undertaking this work. For example, using `tsh` to generate a Kubeconfig will
-be faster as it will not need to request the signing of a new certificate as 
+be faster as it will not need to request the signing of a new certificate as
 part of the process.
 
 Additionally, from an idealistic design perspective, the current approach
@@ -63,14 +63,14 @@ connect to is not an attribute of identity!
 ### Today
 
 Today, we encode the intended target cluster within the user X.509 certificate
-within the `KubernetesCluster` attribute (OID 1.9999.1.3).  
+within the `KubernetesCluster` attribute (OID 1.9999.1.3).
 
 This attribute is primarily used by the Proxy and Kubernetes Agent to determine
 where to route requests intended for the Kubernetes cluster.
 
-When the KubernetesCluster attribute is requested by a client using the 
+When the KubernetesCluster attribute is requested by a client using the
 `GenerateUserCerts` RPC, the certificate request is considered "Kubernetes"
-for analytics purposes. If we were to replace this attribute, we would need to 
+for analytics purposes. If we were to replace this attribute, we would need to
 find an alternative way to determine if a certificate request is intended for
 Kubernetes.
 
@@ -107,7 +107,7 @@ take higher precedence than attributes contained within the certificate.
 
 Teleport clients would no longer need to call `GenerateUserCerts` with a
 `KubernetesCluster` to produce a certificate explicitly for access to
-Kubernetes. When producing a kubeconfig, the client should use the user's 
+Kubernetes. When producing a kubeconfig, the client should use the user's
 standard identity.
 
 To configure Kubernetes clients to work with this, the Kubeconfig generated by
@@ -148,11 +148,11 @@ older clients using a kubeconfig and certificate generated with the
 - V(X+2).0.0:
   - It is now "safe" to remove the old attribute based routing from the Kube
     Forwarder. We may wish to delay this further if we have concerns about
-    older client compatability.
+    older client compatibility.
 
-#### Client Compatability
+#### Client Compatibility
 
-Kubernetes API clients have been known to vary greatly in their support for 
+Kubernetes API clients have been known to vary greatly in their support for
 more unusual configuration. We have witnessed this in the past when it came to
 supporting the ability to explicitly provide the SNI to use when making
 requests.
@@ -223,13 +223,13 @@ This has the following limitations:
 
 #### Custom Protocol
 
-Rather than encoding the target Kubernetes cluster into the URL, we could 
+Rather than encoding the target Kubernetes cluster into the URL, we could
 leverage HTTP headers, or, a custom header protocol which we inject prior to the
 request.
 
 This has the following limitations:
 
-- Limited support for customisation across the various Kubernetes SDKs.
+- Limited support for customization across the various Kubernetes SDKs.
 - Injecting a custom protocol header would require the use of a local proxy,
   which is unwieldy to manage.
 
@@ -244,4 +244,4 @@ TODO
 No new audit log events would be introduced as the result of this change.
 
 Users would no longer expect to see the `cert.create` audit event in correlation
-with Kubernetes Access occurring. This should be noted in the release notes.
+with Kubernetes Access occurring. This should be noted in the release notes.