Merge pull request #26474 from shahincsejnu/master

fixed some typos and grammatical mistakes

Author: k8s-ci-robot

content/en/docs/concepts/security/controlling-access.md

@@ -28,7 +28,7 @@ a private certificate authority (CA), or based on a public key infrastructure li
 to a generally recognized CA.
 
 If your cluster uses a private certificate authority, you need a copy of that CA
-certifcate configured into your `~/.kube/config` on the client, so that you can
+certificate configured into your `~/.kube/config` on the client, so that you can
 trust the connection and be confident it was not intercepted.
 
 Your client can present a TLS client certificate at this stage.
@@ -135,7 +135,7 @@ for the corresponding API object, and then written to the object store (shown as
 The previous discussion applies to requests sent to the secure port of the API server
 (the typical case).  The API server can actually serve on 2 ports:
 
-By default the Kubernetes API server serves HTTP on 2 ports:
+By default, the Kubernetes API server serves HTTP on 2 ports:
 
   1. `localhost` port:
 

content/en/docs/reference/access-authn-authz/authentication.md

@@ -205,8 +205,10 @@ spec:
 ```
 
 Service account bearer tokens are perfectly valid to use outside the cluster and
+
 can be used to create identities for long standing jobs that wish to talk to the
-Kubernetes API. To manually create a service account, use the `kubectl
+Kubernetes API. To manually create a service account, simply use the `kubectl`
+
 create serviceaccount (NAME)` command. This creates a service account in the
 current namespace and an associated secret.
 
@@ -320,6 +322,7 @@ sequenceDiagram
 8.  Once authorized the API server returns a response to `kubectl`
 9.  `kubectl` provides feedback to the user
 
+
 Since all of the data needed to validate who you are is in the `id_token`, Kubernetes doesn't need to
 "phone home" to the identity provider.  In a model where every request is stateless this provides a very scalable solution for authentication.  It does offer a few challenges:
 
@@ -731,7 +734,7 @@ to the impersonated user info.
 The following HTTP headers can be used to performing an impersonation request:
 
 * `Impersonate-User`: The username to act as.
-* `Impersonate-Group`: A group name to act as. Can be provided multiple times to set multiple groups. Optional. Requires "Impersonate-User"
+* `Impersonate-Group`: A group name to act as. Can be provided multiple times to set multiple groups. Optional. Requires "Impersonate-User".
 * `Impersonate-Extra-( extra name )`: A dynamic header used to associate extra fields with the user. Optional. Requires "Impersonate-User". In order to be preserved consistently, `( extra name )` should be lower-case, and any characters which aren't [legal in HTTP header labels](https://tools.ietf.org/html/rfc7230#section-3.2.6) MUST be utf8 and [percent-encoded](https://tools.ietf.org/html/rfc3986#section-2.1).
 
 {{< note >}}

content/en/docs/reference/using-api/api-concepts.md

@@ -258,7 +258,7 @@ Accept: application/json;as=Table;g=meta.k8s.io;v=v1beta1, application/json
 
 ## Alternate representations of resources
 
-By default Kubernetes returns objects serialized to JSON with content type `application/json`. This is the default serialization format for the API. However, clients may request the more efficient Protobuf representation of these objects for better performance at scale. The Kubernetes API implements standard HTTP content type negotiation: passing an `Accept` header with a `GET` call will request that the server return objects in the provided content type, while sending an object in Protobuf to the server for a `PUT` or `POST` call takes the `Content-Type` header. The server will return a `Content-Type` header if the requested format is supported, or the `406 Not acceptable` error if an invalid content type is provided.
+By default, Kubernetes returns objects serialized to JSON with content type `application/json`. This is the default serialization format for the API. However, clients may request the more efficient Protobuf representation of these objects for better performance at scale. The Kubernetes API implements standard HTTP content type negotiation: passing an `Accept` header with a `GET` call will request that the server return objects in the provided content type, while sending an object in Protobuf to the server for a `PUT` or `POST` call takes the `Content-Type` header. The server will return a `Content-Type` header if the requested format is supported, or the `406 Not acceptable` error if an invalid content type is provided.
 
 See the API documentation for a list of supported content types for each API.
 
@@ -560,4 +560,4 @@ If you request a a resourceVersion outside the applicable limit then, depending
 
 ### Unavailable resource versions
 
-Servers are not required to serve unrecognized resource versions. List and Get requests for unrecognized resource versions may wait briefly for the resource version to become available, should timeout with a `504 (Gateway Timeout)` if the provided resource versions does not become available in a resonable amount of time, and may respond with a `Retry-After` response header indicating how many seconds a client should wait before retrying the request. Currently the kube-apiserver also identifies these responses with a "Too large resource version" message. Watch requests for a unrecognized resource version may wait indefinitely (until the request timeout) for the resource version to become available.
+Servers are not required to serve unrecognized resource versions. List and Get requests for unrecognized resource versions may wait briefly for the resource version to become available, should timeout with a `504 (Gateway Timeout)` if the provided resource versions does not become available in a reasonable amount of time, and may respond with a `Retry-After` response header indicating how many seconds a client should wait before retrying the request. Currently, the kube-apiserver also identifies these responses with a "Too large resource version" message. Watch requests for an unrecognized resource version may wait indefinitely (until the request timeout) for the resource version to become available.