diff --git a/content/en/docs/concepts/cluster-administration/manage-deployment.md b/content/en/docs/concepts/cluster-administration/manage-deployment.md index b052dd3a15..d0485a4342 100644 --- a/content/en/docs/concepts/cluster-administration/manage-deployment.md +++ b/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. diff --git a/content/en/docs/concepts/overview/kubernetes-api.md b/content/en/docs/concepts/overview/kubernetes-api.md index b3b6960358..42d12425b7 100644 --- a/content/en/docs/concepts/overview/kubernetes-api.md +++ b/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/). - - ## 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 diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md index 6b117cdc44..e58095517b 100644 --- a/content/en/docs/concepts/workloads/controllers/deployment.md +++ b/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. diff --git a/content/en/docs/concepts/workloads/controllers/garbage-collection.md b/content/en/docs/concepts/workloads/controllers/garbage-collection.md index a20951a35e..79cc905f58 100644 --- a/content/en/docs/concepts/workloads/controllers/garbage-collection.md +++ b/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 diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md index 874bcbeb1c..18e525ac35 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/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. \ No newline at end of file +admission controllers ran in the exact order specified. diff --git a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md index 718c9d1147..8b0794a6b7 100644 --- a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md +++ b/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"]`), diff --git a/content/en/docs/reference/using-api/api-overview.md b/content/en/docs/reference/using-api/api-overview.md index 25b7d46af9..c0adee3bdb 100644 --- a/content/en/docs/reference/using-api/api-overview.md +++ b/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 >}} diff --git a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md index 9288ec3064..a0c68ff682 100644 --- a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md +++ b/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 diff --git a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md b/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md index 6fd887bd8f..f333b215a2 100644 --- a/content/en/docs/tasks/administer-cluster/dns-horizontal-autoscaling.md +++ b/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: