Merge pull request kubernetes#3810 from dgrisonnet/kep-1748

KEP-1748: update to stable

Author: k8s-ci-robot

keps/prod-readiness/sig-instrumentation/1748.yaml

@@ -1,3 +1,5 @@
 kep-number: 1748
 beta:
   approver: "@johnbelamaric"
+stable:
+  approver: "@johnbelamaric"

keps/sig-instrumentation/1748-pod-resource-metrics/README.md

@@ -513,6 +513,16 @@ collector.
 Administrators and visualization tools are the primary target of these metrics and
 so polling and canvassing of Kube distributions is one source of feedback.
 
+* **How can someone using this feature know that it is working for their instance?**
+
+- [ ] Events
+  - Event Reason:
+- [ ] API .status
+  - Condition name:
+  - Other field:
+- [x] Other (treat as last resort)
+  - Details: By scraping the /metrics/resources endpoint of the scheduler and getting metrics about pods resource requests and limits.
+
 * **What are the SLIs (Service Level Indicators) an operator can use to determine
 the health of the service?**
   - [ ] Metrics
@@ -581,6 +591,10 @@ resource usage (CPU, RAM, disk, IO, ...) in any components?**
 Negligible CPU use is expected and some increase in network transmit when the scheduler
 is scraped.
 
+* **Can enabling / using this feature result in resource exhaustion of some node resources (PIDs, sockets, inodes, etc.)?**
+
+No.
+
 ### Troubleshooting
 
 The Troubleshooting section currently serves the `Playbook` role. We may consider

keps/sig-instrumentation/1748-pod-resource-metrics/kep.yaml

@@ -18,9 +18,9 @@ approvers:
   - "@ahg-g"
 see-also:
 replaces:
-latest-milestone: "v1.21"
+latest-milestone: "v1.27"
 milestone:
   alpha: "v1.20"
   beta: "v1.21"
-  stable: "v1.22"
-stage: "beta"
+  stable: "v1.27"
+stage: "stable"