Fix a few grammar issues and typos (#28332)

* Fix few grammar issues and typos in the blog page

> see the API documentation more information
Should be corrected to "documentation for more information" as the sentence is incorrect.

> may only compare two resource version for equality
Everywhere else in the paragraph "resource versions" are used, I believe this is just a typo.

> The get, list and watch
Missing comma after list to separate the elements

* Fix typos in blog post

> On rare occurences, a 
"occurrences" is misspelled

>  whole list, map or struct
3 elements are missing a comma seperator after map
 
>  there are no way 
are is a plural form while "no way" is a singular subject

> `MergePatch`, `StrategicMergePatch`, `JSONPatch` or `Update`
Missing comma after JSONPatch

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

@@ -49,7 +49,7 @@ Some resource types will have one or more sub-resources, represented as sub path
 * Cluster-scoped subresource: `GET /apis/GROUP/VERSION/RESOURCETYPE/NAME/SUBRESOURCE`
 * Namespace-scoped subresource: `GET /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME/SUBRESOURCE`
 
-The verbs supported for each subresource will differ depending on the object - see the API documentation more information. It is not possible to access sub-resources across multiple resources - generally a new virtual resource type would be used if that becomes necessary.
+The verbs supported for each subresource will differ depending on the object - see the API documentation for more information. It is not possible to access sub-resources across multiple resources - generally a new virtual resource type would be used if that becomes necessary.
 
 
 ## Efficient detection of changes
@@ -442,7 +442,7 @@ feature, see the section on
 
 ## Resource Versions
 
-Resource versions are strings that identify the server's internal version of an object. Resource versions can be used by clients to determine when objects have changed, or to express data consistency requirements when getting, listing and watching resources. Resource versions must be treated as opaque by clients and passed unmodified back to the server. For example, clients must not assume resource versions are numeric, and may only compare two resource version for equality (i.e. must not compare resource versions for greater-than or less-than relationships).
+Resource versions are strings that identify the server's internal version of an object. Resource versions can be used by clients to determine when objects have changed, or to express data consistency requirements when getting, listing and watching resources. Resource versions must be treated as opaque by clients and passed unmodified back to the server. For example, clients must not assume resource versions are numeric, and may only compare two resource versions for equality (i.e. must not compare resource versions for greater-than or less-than relationships).
 
 ### ResourceVersion in metadata
 
@@ -454,7 +454,7 @@ Clients find resource versions in resources, including the resources in watch ev
 
 ### The ResourceVersion Parameter
 
-The get, list and watch operations support the `resourceVersion` parameter.
+The get, list, and watch operations support the `resourceVersion` parameter.
 
 The exact meaning of this parameter differs depending on the operation and the value of `resourceVersion`.
 

content/en/docs/reference/using-api/server-side-apply.md

@@ -245,15 +245,15 @@ field tags.
 
 ### Compatibility across topology changes
 
-On rare occurences, a CRD or built-in type author may want to change the
+On rare occurrences, a CRD or built-in type author may want to change the
 specific topology of a field in their resource without incrementing its
 version. Changing the topology of types, by upgrading the cluster or
 updating the CRD, has different consequences when updating existing
 objects. There are two categories of changes: when a field goes from
 `map`/`set`/`granular` to `atomic` and the other way around.
 
 When the `listType`, `mapType`, or `structType` changes from
-`map`/`set`/`granular` to `atomic`, the whole list, map or struct of
+`map`/`set`/`granular` to `atomic`, the whole list, map, or struct of
 existing objects will end-up being owned by actors who owned an element
 of these types. This means that any further change to these objects
 would cause a conflict.
@@ -310,7 +310,7 @@ simplify the update logic of your controller. The main differences with a
 read-modify-write and/or patch are the following:
 
 * the applied object must contain all the fields that the controller cares about.
-* there are no way to remove fields that haven't been applied by the controller
+* there is no way to remove fields that haven't been applied by the controller
   before (controller can still send a PATCH/UPDATE for these use-cases).
 * the object doesn't have to be read beforehand, `resourceVersion` doesn't have
   to be specified.
@@ -473,7 +473,7 @@ have an opinion about.
 ## Clearing ManagedFields
 
 It is possible to strip all managedFields from an object by overwriting them
-using `MergePatch`, `StrategicMergePatch`, `JSONPatch` or `Update`, so every
+using `MergePatch`, `StrategicMergePatch`, `JSONPatch`, or `Update`, so every
 non-apply operation. This can be done by overwriting the managedFields field
 with an empty entry. Two examples are: