Merge pull request #33471 from YuPengZTE/devVS

Automatic merge from submit-queue

The VS and dot is seprated

docs/design/access.md

@@ -254,7 +254,7 @@ In the Enterprise Profile:
 In the Simple Profile:
    - There is a single `namespace` used by the single user.
 
-Namespaces versus userAccount vs Labels:
+Namespaces versus userAccount vs. Labels:
 - `userAccount`s are intended for audit logging (both name and UID should be
 logged), and to define who has access to `namespace`s.
 - `labels` (see [docs/user-guide/labels.md](../../docs/user-guide/labels.md))

docs/design/admission_control_resource_quota.md

@@ -121,7 +121,7 @@ If a third-party wants to track additional resources, it must follow the
 resource naming conventions prescribed by Kubernetes. This means the resource
 must have a fully-qualified name (i.e. mycompany.org/shinynewresource)
 
-## Resource Requirements: Requests vs Limits
+## Resource Requirements: Requests vs. Limits
 
 If a resource supports the ability to distinguish between a request and a limit
 for a resource, the quota tracking system will only cost the request value

docs/design/service_accounts.md

@@ -113,9 +113,9 @@ system external to Kubernetes.
 
 Kubernetes does not dictate how to divide up the space of user identifier
 strings. User names can be simple Unix-style short usernames, (e.g. `alice`), or
-may be qualified to allow for federated identity (`alice@example.com` vs
+may be qualified to allow for federated identity (`alice@example.com` vs.
 `alice@example.org`.) Naming convention may distinguish service accounts from
-user accounts (e.g. `alice@example.com` vs
+user accounts (e.g. `alice@example.com` vs.
 `build-service-account-a3b7f0@foo-namespace.service-accounts.example.com`), but
 Kubernetes does not require this.