The VS and dot is seprated

Signed-off-by: YuPengZTE <[email protected]>

Author: yu8833

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 (`[email protected]` vs
+may be qualified to allow for federated identity (`[email protected]` vs.
 `[email protected]`.) Naming convention may distinguish service accounts from
-user accounts (e.g. `[email protected]` vs
+user accounts (e.g. `[email protected]` vs.
 `build-service-account-a3b7f0@foo-namespace.service-accounts.example.com`), but
 Kubernetes does not require this.
 

docs/devel/api-conventions.md

@@ -63,7 +63,7 @@ resources](../user-guide/working-with-resources.md).*
     - [List Operations](#list-operations)
     - [Map Operations](#map-operations)
   - [Idempotency](#idempotency)
-  - [Optional vs Required](#optional-vs-required)
+  - [Optional vs. Required](#optional-vs-required)
   - [Defaulting](#defaulting)
   - [Late Initialization](#late-initialization)
   - [Concurrency Control and Consistency](#concurrency-control-and-consistency)
@@ -658,7 +658,7 @@ exists - instead, it will either return 201 Created or 504 with Reason
 allotted, and the client should retry (optionally after the time indicated in
 the Retry-After header).
 
-## Optional vs Required
+## Optional vs. Required
 
 Fields must be either optional or required.
 

docs/devel/faster_reviews.md

@@ -109,7 +109,7 @@ fast-moving codebase - lock in your changes ASAP, and make merges be someone
 else's problem.
 
 Obviously, we want every PR to be useful on its own, so you'll have to use
-common sense in deciding what can be a PR vs what should be a commit in a larger
+common sense in deciding what can be a PR vs. what should be a commit in a larger
 PR. Rule of thumb - if this commit or set of commits is directly related to
 Feature-X and nothing else, it should probably be part of the Feature-X PR. If
 you can plausibly imagine someone finding value in this commit outside of

docs/proposals/federation.md

@@ -444,7 +444,7 @@ including discussion of:
 
 1. admission control
 1. initial placement of instances of a new
-service vs scheduling new instances of an existing service in response
+service vs. scheduling new instances of an existing service in response
 to auto-scaling
 1. rescheduling pods due to failure (response might be
 different depending on if it's failure of a node, rack, or whole AZ)

docs/proposals/multi-platform.md

@@ -227,7 +227,7 @@ These addons should also be converted to multiple platforms:
 
 ### Conflicts
 
-What should we do if there's a conflict between keeping e.g. `linux/ppc64le` builds vs merging a release blocker?
+What should we do if there's a conflict between keeping e.g. `linux/ppc64le` builds vs. merging a release blocker?
 
 In fact, we faced this problem while this proposal was being written; in [#25243](https://github.com/kubernetes/kubernetes/pull/25243). It is quite obvious that the release blocker is of higher priority.
 

docs/proposals/protobuf.md

@@ -117,7 +117,7 @@ resembles:
   reduce the amount of memory garbage created during serialization and
   deserialization.
 * More efficient formats like Msgpack were considered, but they only offer
-  2x speed up vs the 10x observed for Protobuf
+  2x speed up vs. the 10x observed for Protobuf
 * gRPC was considered, but is a larger change that requires more core
   refactoring. This approach does not eliminate the possibility of switching
   to gRPC in the future.
@@ -356,7 +356,7 @@ deserialization of the remaining bytes into the `runtime.Unknown` type.
 ## Streaming wire format
 
 While the majority of Kubernetes APIs return single objects that can vary
-in type (Pod vs Status, PodList vs Status), the watch APIs return a stream
+in type (Pod vs. Status, PodList vs. Status), the watch APIs return a stream
 of identical objects (Events). At the time of this writing, this is the only
 current or anticipated streaming RESTful protocol (logging, port-forwarding,
 and exec protocols use a binary protocol over Websockets or SPDY).

docs/proposals/resource-quota-scoping.md

@@ -79,10 +79,10 @@ max number of active best-effort pods.  In addition, the cluster-admin
 requires the ability to scope a quota that limits compute resources to
 exclude best-effort pods.
 
-### Ability to quota long-running vs bounded-duration compute resources
+### Ability to quota long-running vs. bounded-duration compute resources
 
 The cluster-admin may want to quota end-users separately
-based on long-running vs bounded-duration compute resources.
+based on long-running vs. bounded-duration compute resources.
 
 For example, a cluster-admin may offer more compute resources
 for long running pods that are expected to have a more permanent residence
@@ -94,7 +94,7 @@ request if there is no active traffic.  An operator that wants to control
 density will offer lower quota limits for batch workloads than web applications.
 
 A classic example is a PaaS deployment where the cluster-admin may
-allow a separate budget for pods that run their web application vs pods that
+allow a separate budget for pods that run their web application vs. pods that
 build web applications.
 
 Another example is providing more quota to a database pod than a
@@ -105,8 +105,8 @@ pod that performs a database migration.
 * As a cluster-admin, I want the ability to quota
  * compute resource requests
  * compute resource limits
- * compute resources for terminating vs non-terminating workloads
- * compute resources for best-effort vs non-best-effort pods
+ * compute resources for terminating vs. non-terminating workloads
+ * compute resources for best-effort vs. non-best-effort pods
 
 ## Proposed Change
 

docs/proposals/runtimeconfig.md

@@ -82,7 +82,7 @@ feature's owner(s). The following are suggested conventions:
   in each component to toggle on/off.
 - Alpha features should be disabled by default. Beta features may
   be enabled by default. Refer to docs/devel/api_changes.md#alpha-beta-and-stable-versions
-  for more detailed guidance on alpha vs beta.
+  for more detailed guidance on alpha vs. beta.
 
 ## Upgrade support