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.

Author: tengqm

content/en/docs/concepts/cluster-administration/manage-deployment.md

@@ -323,7 +323,7 @@ When load on your application grows or shrinks, it's easy to scale with `kubectl
 kubectl scale deployment/my-nginx --replicas=1
 ```
 ```shell
-deployment.extensions/my-nginx scaled
+deployment.apps/my-nginx scaled
 ```
 
 Now you only have one pod managed by the deployment.

content/en/docs/concepts/overview/kubernetes-api.md

@@ -25,8 +25,6 @@ The Kubernetes API lets you query and manipulate the state of objects in the Kub
 API endpoints, resource types and samples are described in the [API Reference](/docs/reference/kubernetes-api/).
 
 
-
-
 <!-- body -->
 
 ## API changes
@@ -87,7 +85,7 @@ Kubernetes implements an alternative Protobuf based serialization format for the
 
 To make it easier to eliminate fields or restructure resource representations, Kubernetes supports
 multiple API versions, each at a different API path, such as `/api/v1` or
-`/apis/extensions/v1beta1`.
+`/apis/rbac.authorization.k8s.io/v1alpha1`.
 
 Versioning is done at the API level rather than at the resource or field level to ensure that the
 API presents a clear, consistent view of system resources and behavior, and to enable controlling
@@ -157,14 +155,6 @@ The flag accepts comma separated set of key=value pairs describing runtime confi
 {{< note >}}Enabling or disabling groups or resources requires restarting the kube-apiserver and the
 kube-controller-manager to pick up the `--runtime-config` changes.{{< /note >}}
 
-## Enabling specific resources in the extensions/v1beta1 group
-
-DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default.
-For example: to enable deployments and daemonsets, set
-`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`.
-
-{{< note >}}Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons.{{< /note >}}
-
 ## Persistence
 
 Kubernetes stores its serialized state in terms of the API resources by writing them into

content/en/docs/concepts/workloads/controllers/deployment.md

@@ -1155,10 +1155,6 @@ created Pod should be ready without any of its containers crashing, for it to be
 This defaults to 0 (the Pod will be considered available as soon as it is ready). To learn more about when
 a Pod is considered ready, see [Container Probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes).
 
-### Rollback To
-
-Field `.spec.rollbackTo` has been deprecated in API versions `extensions/v1beta1` and `apps/v1beta1`, and is no longer supported in API versions starting `apps/v1beta2`. Instead, `kubectl rollout undo` as introduced in [Rolling Back to a Previous Revision](#rolling-back-to-a-previous-revision) should be used.
-
 ### Revision History Limit
 
 A Deployment's revision history is stored in the ReplicaSets it controls.

content/en/docs/concepts/workloads/controllers/garbage-collection.md

@@ -111,12 +111,6 @@ To control the cascading deletion policy, set the `propagationPolicy`
 field on the `deleteOptions` argument when deleting an Object. Possible values include "Orphan",
 "Foreground", or "Background".
 
-Prior to Kubernetes 1.9, the default garbage collection policy for many controller resources was `orphan`.
-This included ReplicationController, ReplicaSet, StatefulSet, DaemonSet, and
-Deployment. For kinds in the `extensions/v1beta1`, `apps/v1beta1`, and `apps/v1beta2` group versions, unless you 
-specify otherwise, dependent objects are orphaned by default. In Kubernetes 1.9, for all kinds in the `apps/v1` 
-group version, dependent objects are deleted by default.
-
 Here's an example that deletes dependents in background:
 
 ```shell

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"]`),

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

@@ -33,7 +33,7 @@ if you are writing an application using the Kubernetes API.
 
 To eliminate fields or restructure resource representations, Kubernetes supports
 multiple API versions, each at a different API path. For example: `/api/v1` or
-`/apis/extensions/v1beta1`.
+`/apis/rbac.authorization.k8s.io/v1alpha1`.
 
 The version is set at the API level rather than at the resource or field level to:
 
@@ -106,10 +106,3 @@ When you enable or disable groups or resources, you need to restart the apiserve
 to pick up the `--runtime-config` changes.
 {{< /note >}}
 
-## Enabling specific resources in the extensions/v1beta1 group
-
-DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies and ReplicaSets in the `extensions/v1beta1` API group are disabled by default.
-For example: to enable deployments and daemonsets, set
-`--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`.
-
-{{< note >}}Individual resource enablement/disablement is only supported in the `extensions/v1beta1` API group for legacy reasons.{{< /note >}}

content/en/docs/tasks/access-application-cluster/ingress-minikube.md

@@ -132,7 +132,7 @@ The following file is an Ingress resource that sends traffic to your Service via
 
 1. Create `example-ingress.yaml` from the following file:
 
-        apiVersion: networking.k8s.io/v1beta1 # for versions before 1.14 use extensions/v1beta1
+        apiVersion: networking.k8s.io/v1beta1
         kind: Ingress
         metadata:
           name: example-ingress
@@ -243,7 +243,7 @@ The following file is an Ingress resource that sends traffic to your Service via
 
     Output: 
     ```shell
-    ingress.extensions/example-ingress configured
+    ingress.networking/example-ingress configured
     ```
 
 ## Test Your Ingress

content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md

@@ -160,7 +160,7 @@ kubectl scale deployment --replicas=0 dns-autoscaler --namespace=kube-system
 
 The output is:
 
-    deployment.extensions/dns-autoscaler scaled
+    deployment.apps/dns-autoscaler scaled
 
 Verify that the replica count is zero: