promote KEP-4742 to beta

Signed-off-by: Andrew Sy Kim <andrewsy@google.com>

Author: andrewsykim

keps/sig-node/4742-node-topology-downward-api/README.md

@@ -12,10 +12,10 @@
   - [Risks and Mitigations](#risks-and-mitigations)
 - [Design Details](#design-details)
   - [Test Plan](#test-plan)
-      - [Prerequisite testing updates](#prerequisite-testing-updates)
-      - [Unit tests](#unit-tests)
-      - [Integration tests](#integration-tests)
-      - [e2e tests](#e2e-tests)
+    - [Prerequisite testing updates](#prerequisite-testing-updates)
+    - [Unit tests](#unit-tests)
+    - [Integration tests](#integration-tests)
+    - [e2e tests](#e2e-tests)
   - [Graduation Criteria](#graduation-criteria)
     - [Alpha](#alpha)
     - [Beta](#beta)
@@ -59,7 +59,6 @@ Items marked with (R) are required *prior to targeting to a milestone / release*
 
 [kubernetes.io]: https://kubernetes.io/
 [kubernetes/enhancements]: https://git.k8s.io/enhancements
-[kubernetes/kubernetes]: https://git.k8s.io/kubernetes
 [kubernetes/website]: https://git.k8s.io/website
 
 ## Summary
@@ -76,7 +75,8 @@ promoting a more secure and consistent solution.
 Topology awareness is crucial for a growing number of applications and workloads on Kubernetes.
 Knowing the Pods's location within the cluster's topology allows for significant performance
 optimizations and improved resilience. End-user feedback has highlighted the following key use cases:
-* High-bandwidth AI/ML workloads, especially those employing distributed training or inference,
+
+- High-bandwidth AI/ML workloads, especially those employing distributed training or inference,
   demonstrate a substantial need for topology awareness. The performance of these workloads is
   highly sensitive to communication latency between GPUs. By preferentially scheduling Pods
   requiring GPU-to-GPU communication within the same zone or rack, training and inference
@@ -85,10 +85,10 @@ optimizations and improved resilience. End-user feedback has highlighted the fol
   within the machine learning framework itself (e.g., Ray, PyTorch Distributed. etc).  Kubernetes provides the
   necessary foundation for these frameworks to operate efficiently, but the frameworks are ultimately responsible
   for leveraging that foundation.
-* CNI plugins can leverage topology information to establish more efficient network paths,
+- CNI plugins can leverage topology information to establish more efficient network paths,
   reducing latency and increasing throughput. For instance, a CNI could prioritize connections
   within the same availability zone or rack.
-* Distributed stateful applications, such as sharded databases, can use topology information to improve fault tolerance.
+- Distributed stateful applications, such as sharded databases, can use topology information to improve fault tolerance.
   By spreading replicas and traffic across different failure domains (e.g., zones, racks), these applications can achieve
   higher availability and resilience to failures in any one topology.
 
@@ -98,16 +98,16 @@ we aim to simplify access to this information for Pods via the Downward API.
 
 ### Goals
 
-* Values from Node labels `topology.k8s.io/zone`, `topology.k8s.io/region` and `kubernetes.io/hostname` are made
+- Values from Node labels `topology.kubernetes.io/zone`, `topology.kubernetes.io/region` and `kubernetes.io/hostname` are made
   available via downward API
-* Additional node labels can be made available via downward API using admission webhooks that mutate `pods/binding`.
+- Additional node labels can be made available via downward API using admission webhooks that mutate `pods/binding`.
 
 ### Non-Goals
 
-* Exposing non-standard node labels by default
-* Enhnacements to topology-aware scheduling
-* Changes to standard topology labels in Kubernetes
-* Changes to downward API
+- Exposing non-standard node labels by default
+- Enhnacements to topology-aware scheduling
+- Changes to standard topology labels in Kubernetes
+- Changes to downward API
 
 ## Proposal
 
@@ -117,6 +117,7 @@ adding topology labels that match those of the target Node. The Binding REST imp
 from the `pods/binding` subresource to the assigned Pod's labels.
 
 Using the downward API to retrieve topology information will look similar to the following:
+
 ```
 apiVersion: v1
 kind: Pod
@@ -147,36 +148,35 @@ spec:
 
 ### User Stories
 
-* As an ML engineer, I want to optimize GPU-to-GPU communication during training which requires topology-awareness in my training code.
-* As a database developer, I want to leverage topology information to improve fault tolerance of sharded databases on Kubernetes.
-* As a developer of a Kubernetes CNI plugin, I want to pass topology information down to the CNI plugin to optimize data paths for container networks.
+- As an ML engineer, I want to optimize GPU-to-GPU communication during training which requires topology-awareness in my training code.
+- As a database developer, I want to leverage topology information to improve fault tolerance of sharded databases on Kubernetes.
+- As a developer of a Kubernetes CNI plugin, I want to pass topology information down to the CNI plugin to optimize data paths for container networks.
 
 ### Notes/Constraints/Caveats (Optional)
 
 ### Risks and Mitigations
 
-* Scope creep. Allowing additional node information or node label info could
+- Scope creep. Allowing additional node information or node label info could
 create security issues. This is mitigated by limiting the node labels
 to strictly those that are standardized through KEP-1659.
 
-* Exposing sensitive data as node labels to pods. This is mitigated by ensuring
+- Exposing sensitive data as node labels to pods. This is mitigated by ensuring
 standard topology labels are available to Pods.
 
-* Stale data. Information obtained through node labels is like information
+- Stale data. Information obtained through node labels is like information
 attained through a configmap or secret mounted to a pod, being passed on
 creation but not guaranteed to be immutable and thus should be treated as so.
 
-
 ## Design Details
 
-* A built-in Kubernetes admission plugin, `PodTopologyLabels` will be introduced in kube-apiserver
-* The `PodTopologyLabels` admission plugin is responsible for mutating `pods/binding` subresource, adding topology labels matching the target Node.
-* `PodTopologyLabels` admission will overwrite `topology.k8s.io/*` labels on Pods.
-* A feature gate, `PodTopologyLabelsAdmission` will be introduced in v1.33. Alpha and disabled by default.
+- A built-in Kubernetes admission plugin, `PodTopologyLabels` will be introduced in kube-apiserver
+- The `PodTopologyLabels` admission plugin is responsible for mutating `pods/binding` subresource, adding topology labels matching the target Node.
+- `PodTopologyLabels` admission will overwrite `topology.kubernetes.io/*` labels on Pods.
+- A feature gate, `PodTopologyLabelsAdmission` will be introduced in v1.33. Alpha and disabled by default.
 The `PodTopologyLabels` admission plugin can only be set when this feature gate is enabled.
-* The Binding REST implementation will be updated to copy all labels from `pods/binding` subresource into Pods.
+- The Binding REST implementation will be updated to copy all labels from `pods/binding` subresource into Pods.
 At this point we will overwrite Pod labels in Binding that are allowed to be exposed via Downward API.
-* For exposing additional node labels, at the discretion of the cluster admin, a mutating admission webhook can be used to mutate labels of the `pods/binding` subresource.
+- For exposing additional node labels, at the discretion of the cluster admin, a mutating admission webhook can be used to mutate labels of the `pods/binding` subresource.
 
 ### Test Plan
 
@@ -189,29 +189,32 @@ to implement this enhancement.
 ##### Unit tests
 
 Unit tests will be added for:
-* New `PodTopologyLabels` admission plugin
-* Binding REST implementation
+
+- New `PodTopologyLabels` admission plugin
+- Binding REST implementation
 
 Unit tests will also ensure behavior is exercised when the feature gate is enabled.
 
 ##### Integration tests
 
 Integration tests will be added to test the following behavior:
-* Pods contain topology labels when `PodTopologyLabels` admission plugin is enabled.
-* Topology labels can be expressed in Pod Downward API
-* Node labels outside standard topology labels are disallowed
-* Topology labels are empty if underlying Node does not specify a topology
+
+- Pods contain topology labels when `PodTopologyLabels` admission plugin is enabled.
+- Topology labels can be expressed in Pod Downward API
+- Node labels outside standard topology labels are disallowed
+- Topology labels are empty if underlying Node does not specify a topology
 
 Integration tests will also ensure behavior is exercised when the feature gate is enabled.
 
 ##### e2e tests
 
 E2E tests will be added to test the following scenarios:
-* Pods contain topology labels when `PodTopologyLabels` admission plugin is enabled.
-* A Pod using downward API to retrieve the underlying topology information about the Node
-* A Pod attempting to use downward API to retrieve Node labels that are not the standard topology labels
-* A Pod using downward API on a Node that does not contain any topology information.
-* Use MutatingAdmissionPolicy to add a custom node label that can be used via downward API.
+
+- Pods contain topology labels when `PodTopologyLabels` admission plugin is enabled.
+- A Pod using downward API to retrieve the underlying topology information about the Node
+- A Pod attempting to use downward API to retrieve Node labels that are not the standard topology labels
+- A Pod using downward API on a Node that does not contain any topology information.
+- Use MutatingAdmissionPolicy to add a custom node label that can be used via downward API.
 
 E2E tests will also ensure behavior is exercised when the feature gate is enabled.
 
@@ -225,7 +228,8 @@ E2E tests will also ensure behavior is exercised when the feature gate is enable
 
 #### Beta
 
-TODO after Alpha.
+- Fix standard topology label used in PodTopologyLabels admission controller (topology.k8s.io -> topology.kubernetes.io)
+- Unit, integration and e2e tests
 
 #### GA
 
@@ -290,7 +294,9 @@ Tests will be added to ensure feature gate works as expected.
 
 ### Rollout, Upgrade and Rollback Planning
 
-TODO for Beta.
+Manual testing will be exercised to ensure that PodTopologyLabelsAdmission can be enabled and then disabled.
+When disabled, existing Pods with topology labels will continue to run with those labels and new Pods will no longer
+container topology labels.
 
 ###### How can a rollout or rollback fail? Can it impact already running workloads?
 
@@ -333,7 +339,6 @@ N/A
 
 ###### What are the SLIs (Service Level Indicators) an operator can use to determine the health of the service?
 
-
 - [X] Metrics
   - Metric name: `pod_scheduling_attempts`
   - [Optional] Aggregation method:
@@ -402,6 +407,7 @@ Revert feature gate and stop consuming downward API.
 ## Implementation History
 
 - `v1.33`: initial KEP is accepeted and alpha implementation is complete
+- `v1.34`: fix topology labels from topology.k8s.io to topology.kubernetes.io
 
 ## Drawbacks
 

keps/sig-node/4742-node-topology-downward-api/kep.yaml

@@ -21,17 +21,17 @@ see-also:
 replaces:
 
 # The target maturity stage in the current dev cycle for this KEP.
-stage: alpha
+stage: beta
 
 # 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.33"
+latest-milestone: "v1.34"
 
 # The milestone at which this feature was, or is targeted to be, at each stage.
 milestone:
   alpha: "v1.33"
-  # beta: "v1.34"
+  beta: "v1.34"
   # stable: "v1.35"
 
 # The following PRR answers are required at alpha release