Fix pages that reference removed API groups

Quite some resources have been moved out of the `extensions` API group
since 1.18; the `apps/v1beta1` and `apps/v1beta2` group versions are
also dropped. This PR updates the pages which still reference such API
groups or group versions.

content/en/docs/reference/access-authn-authz/admission-controllers.md

@@ -677,9 +677,6 @@ for more information.
 This admission controller acts on creation and modification of the pod and determines if it should be admitted
 based on the requested security context and the available Pod Security Policies.
 
-For Kubernetes < 1.6.0, the API Server must enable the extensions/v1beta1/podsecuritypolicy API
-extensions group (`--runtime-config=extensions/v1beta1/podsecuritypolicy=true`).
-
 See also [Pod Security Policy documentation](/docs/concepts/policy/pod-security-policy/)
 for more information.
 
@@ -793,4 +790,4 @@ phase, and therefore is the last admission controller to run.
 in the mutating phase.
 
     For earlier versions, there was no concept of validating versus mutating and the
-admission controllers ran in the exact order specified.
+admission controllers ran in the exact order specified.

content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md

@@ -949,7 +949,7 @@ See https://kubernetes.io/docs/concepts/overview/working-with-objects/labels for
 ### Matching requests: matchPolicy
 
 API servers can make objects available via multiple API groups or versions.
-For example, the Kubernetes API server allows creating and modifying `Deployment` objects
+For example, the Kubernetes API server may allow creating and modifying `Deployment` objects
 via `extensions/v1beta1`, `apps/v1beta1`, `apps/v1beta2`, and `apps/v1` APIs.
 
 For example, if a webhook only specified a rule for some API groups/versions (like `apiGroups:["apps"], apiVersions:["v1","v1beta1"]`),