whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix pages that reference removed API groups

Browse Source 
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.
This commit is contained in:
Qiming Teng
2020-07-04 13:23:26 +08:00
parent c452e65a62
commit e097b93c8e
9 changed files with 8 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/reference/access-authn-authz/admission-controllers.md
+1 -4
View File
@@ -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
+1 -1
View File
@@ -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
+1 -8
View File
@@ -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 >}}