From 278b29887995738c22e6723cd138a7aa3fa0cdbd Mon Sep 17 00:00:00 2001 From: Tim Bannister Date: Wed, 1 Jan 2020 23:38:58 +0000 Subject: [PATCH] Clean up admission controller deprecation example --- .../access-authn-authz/extensible-admission-controllers.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) 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 b23f52f456ff6..f22ff7075bd0f 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 @@ -968,9 +968,10 @@ Specifying `Equivalent` is recommended, and ensures that webhooks continue to in resources they expect when upgrades enable new versions of the resource in the API server. When a resource stops being served by the API server, it is no longer considered equivalent to other versions of that resource that are still served. -For example, deprecated `extensions/v1beta1` deployments are scheduled to stop being served by default in v1.16. -Once that occurs, a webhook with a `apiGroups:["extensions"], apiVersions:["v1beta1"], resources:["deployments"]` rule -would no longer intercept deployments created via `apps/v1` APIs. For that reason, webhooks should prefer registering +For example, `extensions/v1beta1` deployments were first deprecated and then removed (in Kubernetes v1.16). + +Since that removal, a webhook with a `apiGroups:["extensions"], apiVersions:["v1beta1"], resources:["deployments"]` rule +does not intercept deployments created via `apps/v1` APIs. For that reason, webhooks should prefer registering for stable versions of resources. This example shows a validating webhook that intercepts modifications to deployments (no matter the API group or version),