From 8337eddf5ae1cf354a48eaa3b079ec86a3b73397 Mon Sep 17 00:00:00 2001 From: andrewsykim Date: Wed, 7 Jun 2023 22:51:57 -0400 Subject: [PATCH 1/2] KEP-1965: add GA criterias APIServerIdentity Signed-off-by: andrewsykim --- keps/prod-readiness/sig-api-machinery/1965.yaml | 2 ++ .../sig-api-machinery/1965-kube-apiserver-identity/README.md | 2 +- keps/sig-api-machinery/1965-kube-apiserver-identity/kep.yaml | 5 +++-- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/keps/prod-readiness/sig-api-machinery/1965.yaml b/keps/prod-readiness/sig-api-machinery/1965.yaml index 25f0678b699..082aa671b8d 100644 --- a/keps/prod-readiness/sig-api-machinery/1965.yaml +++ b/keps/prod-readiness/sig-api-machinery/1965.yaml @@ -1,3 +1,5 @@ kep-number: 1965 beta: approver: "@deads2k" # and @wojtek-t +stable: + approver: "@deads2k" # and @wojtek-t diff --git a/keps/sig-api-machinery/1965-kube-apiserver-identity/README.md b/keps/sig-api-machinery/1965-kube-apiserver-identity/README.md index f727a8d2db9..dc801f608de 100644 --- a/keps/sig-api-machinery/1965-kube-apiserver-identity/README.md +++ b/keps/sig-api-machinery/1965-kube-apiserver-identity/README.md @@ -179,7 +179,7 @@ Alpha should provide basic functionality covered with tests described above. #### Beta -> GA Graduation -==TODO== + - support for aggregated apiservers **For non-optional features moving to GA, the graduation criteria must include [conformance tests].** diff --git a/keps/sig-api-machinery/1965-kube-apiserver-identity/kep.yaml b/keps/sig-api-machinery/1965-kube-apiserver-identity/kep.yaml index 2c60f15d4a6..a11cb1f0ef9 100644 --- a/keps/sig-api-machinery/1965-kube-apiserver-identity/kep.yaml +++ b/keps/sig-api-machinery/1965-kube-apiserver-identity/kep.yaml @@ -19,17 +19,18 @@ see-also: - "https://docs.google.com/document/d/1ed7miqlFY7-9lZxE7gzoyx_MFQCtFEDqtcKMpaAmHys/edit?usp=sharing" # The target maturity stage in the current dev cycle for this KEP. -stage: beta +stage: stable # The most recent milestone for which work toward delivery of this KEP has been # done. This can be the current (upcoming) milestone, if it is being actively # worked on. -latest-milestone: "v1.26" +latest-milestone: "v1.28" # The milestone at which this feature was, or is targeted to be, at each stage. milestone: alpha: "v1.20" beta: "v1.26" + stable: "v1.28" # The following PRR answers are required at alpha release # List the feature gate name and the components for which it must be enabled From 272487b372b3d71b121b5f8a7a2d51e6a8f70067 Mon Sep 17 00:00:00 2001 From: andrewsykim Date: Wed, 7 Jun 2023 23:13:09 -0400 Subject: [PATCH 2/2] KEP-1965: update KEP to reflect changes made for beta Signed-off-by: andrewsykim --- .../1965-kube-apiserver-identity/README.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/keps/sig-api-machinery/1965-kube-apiserver-identity/README.md b/keps/sig-api-machinery/1965-kube-apiserver-identity/README.md index dc801f608de..1e7aaac5dee 100644 --- a/keps/sig-api-machinery/1965-kube-apiserver-identity/README.md +++ b/keps/sig-api-machinery/1965-kube-apiserver-identity/README.md @@ -127,18 +127,15 @@ post-start-hook and expired leases will be garbage collected by the `start-kube- post-start-hook in kube-apiserver. The refresh rate, lease duration will be configurable through kube-apiserver flags -The format of the lease will be `kube-apiserver-`. A hash based on the hostname is used for two reasons: +The format of the lease will be `apiserver-`. A hash based on the hostname is used for two reasons: 1. To ensure that a `kube-apiserver` that is restarting will attempt to obtain its previous lease, avoiding system churn when a kube-apiserver Lease is garbage collected. 2. Avoiding the need to truncate the lease name when using longer hostnames that exceed the 64 character limit for object names, which can lead to naming conflicts. Each lease will have a `kubernetes.io/hostname` label with the actual hostname seen by kube-apiserver which cluster admins can use to determine which kube-apiserver owns a Lease object. However, the holder identity of the lease (`lease.spec.holderIdentity`) will be uniquely generated per start-up, which can be used as an indicator for -ownership churn of the lease. All kube-apiserver leases will also have a component label `k8s.io/component=kube-apiserver`. - -In the future, we may consider providing a flag in `kube-apiserver` to override the lease name, but we don't anticipate -needing this today. - +ownership churn of the lease. All leases will also have a `apiserver.kubernetes.io/identity` label, to uniquely distinguish +leases between kube-apiserver or extension apiservers. ### Test Plan @@ -167,6 +164,8 @@ Proposed e2e tests: - an e2e test that restarts a kube-apiserver and validates that a new Lease is created with a newly generated ID and the old lease is garbage collected +See [apiserver_identity.go](https://github.com/kubernetes/kubernetes/blob/master/test/e2e/apimachinery/apiserver_identity.go) for currently implemented e2e tests. + ### Graduation Criteria Alpha should provide basic functionality covered with tests described above. @@ -179,7 +178,7 @@ Alpha should provide basic functionality covered with tests described above. #### Beta -> GA Graduation - - support for aggregated apiservers + - support for aggregated apiservers (with sufficient integration/e2e test coverage) **For non-optional features moving to GA, the graduation criteria must include [conformance tests].**