promote 4396 to beta

Author: HirazawaUi

keps/sig-node/4369-allow-special-characters-environment-variable/README.md

@@ -55,9 +55,9 @@ checklist items _must_ be updated for the enhancement to be released.
 
 Items marked with (R) are required *prior to targeting to a milestone / release*.
 
-- [ ] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR)
-- [ ] (R) KEP approvers have approved the KEP status as `implementable`
-- [ ] (R) Design details are appropriately documented
+- [x] (R) Enhancement issue in release milestone, which links to KEP dir in [kubernetes/enhancements] (not the initial KEP PR)
+- [x] (R) KEP approvers have approved the KEP status as `implementable`
+- [x] (R) Design details are appropriately documented
 - [ ] (R) Test plan is in place, giving consideration to SIG Architecture and SIG Testing input (including test refactors)
   - [ ] e2e Tests for all Beta API Operations (endpoints)
   - [ ] (R) Ensure GA e2e tests meet requirements for [Conformance Tests](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/conformance-tests.md) 
@@ -211,7 +211,7 @@ No
 
 ###### Can the feature be disabled once it has been enabled (i.e. can we roll back the enablement)?
 
-If close the feature gate, already running workloads will not be affected in any way, 
+If disable the feature gate, already running workloads will not be affected in any way, 
 but cannot create workloads that use special characters as environment variables.
 
 ###### What happens if we reenable the feature if it was previously rolled back?
@@ -226,7 +226,7 @@ Yes.
 
 ###### How can a rollout or rollback fail? Can it impact already running workloads?
 
-When a feature gate is closed, already running workloads are not affected in any way, but update fields for workload will cause the workload to fail.
+When a feature gate is disabled, already running workloads are not affected in any way, but update fields for workload will cause the workload to fail.
 
 ###### What specific metrics should inform a rollback?
 
@@ -242,7 +242,22 @@ No.
 
 ### Monitoring Requirements
 
-- We will investigate in the beta version how to monitor kubelet/CRI implementations could fail on pods using this enhancement.
+###### How can an operator determine if the feature is in use by workloads?
+
+  Yes, operators can use the Kubenetes API to achieve this. They need to get all pods in the cluster and check if any pod has set a field other than `[-._a-zA-Z][-._a-zA-Z0-9]*` as an environment variable name. For example, we can find the namespaces and names of pods using this feature and their environment variable names using the following command:
+
+```
+kubectl get pods --all-namespaces -o json | jq -r '.items[] | select(.spec.containers[].env[]?.name | test("^[a-zA-Z_][a-zA-Z0-9_]*$") | not) | [.metadata.namespace, .metadata.name, .spec.containers[].env[]?.name] | @tsv'
+```
+
+###### What are the SLIs (Service Level Indicators) an operator can use to determine the health of the service?
+
+- [x] Metrics
+  - Metric name: run_podsandbox_errors_total
+  - [Optional] Aggregation method:
+  - Components exposing the metric:  According to the test results in https://github.com/HirazawaUi/verfiy-container-env, the container runtime is very lenient with using special characters as environment variables, and almost no failures will occur. However, if unexpected boundary conditions occur, `run_podsandbox_errors_total` can still help us record some problems.
+- [ ] Other (treat as last resort)
+  - Details:
 
 ### Dependencies
 
@@ -294,6 +309,8 @@ No
 
 \- 2023-12-21: Initial draft KEP
 
+\- 2024-08-26: promote to beta
+
 ## Drawbacks
 
 If the envvar name character set is extended,  all the things currently consuming and using envvar names from the API will have an impact and may break or be unsafe.

keps/sig-node/4369-allow-special-characters-environment-variable/kep.yaml

@@ -18,12 +18,12 @@ 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.30"
+latest-milestone: "v1.32"
 
 # The milestone at which this feature was, or is targeted to be, at each stage.
 milestone: