review feedback

Author: natasha41575

keps/sig-node/1287-in-place-update-pod-resources/README.md

@@ -38,7 +38,6 @@
   - [Resource Quota](#resource-quota)
   - [Affected Components](#affected-components)
   - [Instrumentation](#instrumentation)
-    - [<code>kubelet_pod_resize_requests_total</code>](#kubelet_pod_resize_requests_total)
     - [<code>kubelet_container_resize_requests_total</code>](#kubelet_container_resize_requests_total)
     - [<code>kubelet_pod_resize_sli_duration_seconds</code>](#kubelet_pod_resize_sli_duration_seconds)
     - [<code>kubelet_pod_infeasible_resize_total</code>](#kubelet_pod_infeasible_resize_total)
@@ -891,20 +890,6 @@ Other components:
 
 The kubelet will record the following metrics:
 
-#### `kubelet_pod_resize_requests_total` 
-
-This metric tracks the total number of resize requests observed by the Kubelet, counted at the pod level.
-A single pod update changing multiple containers will be considered a single resize request.
-
-Labels: 
-- `resource_type` - what type of resource is being resized. Possible values: `cpu_limits`, `cpu_requests` `memory_limits`, or `memory_requests`. If more than one of these resource types is changing in the resize request, 
-we increment the counter multiple times, once for each. This means that a single pod update changing multiple
-resource types will be considered multiple requests for this metric. 
-- `operation_type` -  whether the resize is a net increase or a decrease (taken as an aggregate across
-all containers in the pod). Possible values: `increase`, `decrease`, `add`, or `remove`.
-
-This metric is recorded as a counter.
-
 #### `kubelet_container_resize_requests_total` 
 
 This metric tracks the total number of resize requests observed by the Kubelet, counted at the container level.
@@ -924,11 +909,6 @@ This metric tracks the latency between when the kubelet accepts a resize request
 the request. More precisely, this metric tracks the total amount of time that the `PodResizeInProgress` condition
 is present on a pod.
 
-Labels: 
-- `resource_type` - what type of resource is being resized. Possible values: `cpu_limits`, `cpu_requests` `memory_limits`, or `memory_requests`. If more than one of these resource types is changing in the resize request, 
-we increment the counter multiple times, once for each.
-- `operation_type` -  whether the resize is an increase or a decrease. Possible values: `increase`, `decrease`, `add`, or `remove`.
-
 This metric is recorded as a gauge.
 
 #### `kubelet_pod_infeasible_resize_total`
@@ -952,12 +932,11 @@ This metric is recorded as a counter.
 #### `kubelet_pod_deferred_resize_accepted_total`
 
 This metric tracks the total number of resize requests that the Kubelet originally marked as deferred but 
-later accepted. This metric primarily exists because if a deferred resize is accepted through the timed retry as
-opposed to being explicitly signaled, it indicates an issue in the Kubelet's logic for handling deferred
-resizes that we should fix.
+later accepted. This metric primarily exists because if a deferred resize is accepted through the timed retry (as
+opposed to being triggered by an event such as another pod being deleted or sized down), it indicates an issue in the Kubelet's logic for handling deferred resizes that we should fix.
 
 Labels:
-  - `retry_reason` - whether the resize was accepted through the timed retry or explicitly signaled. Possible values: `timed`, `signaled`.
+  - `accepted_reason` - whether the resize was accepted through the timed retry or due to another pod event. Possible values: `periodic_retry`, `event_based`.
 
 This metric is recorded as a counter.