Handle the case where container resource and request set to minimum values #120791

Karthik-K-N · 2023-09-21T06:40:56Z

What type of PR is this?

/kind bug

What this PR does / why we need it:

This PR contains the changes to handle the case in which the container resource request and limit set to minimum value.

Which issue(s) this PR fixes:

Fixes #114123

Special notes for your reviewer:

Does this PR introduce a user-facing change?

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

NONE

Alpha feature code isse in KEP: kubernetes/enhancements#1287
Previous code review discussion: #102884 (comment)

pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: cpu1
spec:
  containers:
  - name: ubunutu
    image: ppc64le/ubuntu:latest
    command: [ "tail", "-f", "/dev/null" ]
    resizePolicy:
    - resourceName: "memory"
      restartPolicy: "RestartContainer"
    resources:
      limits:
        cpu: "1m"
      requests:
        cpu: "1m"

Current behavior

spec:
  containers:
  - command:
    - tail
    - -f
    - /dev/null
    image: ppc64le/ubuntu:latest
    imagePullPolicy: Always
    name: ubunutu
    resizePolicy:
    - resourceName: memory
      restartPolicy: RestartContainer
    - resourceName: cpu
      restartPolicy: NotRequired
    resources:
      limits:
        cpu: 1m
      requests:
        cpu: 1m
status:
  .
  .
  .
  containerStatuses:
  - allocatedResources:
      cpu: 1m
    containerID: containerd://43baca32c3f20362057917d8ae22d8e6f820ae5320849a08304ec5891ef9215a
    image: docker.io/ppc64le/ubuntu:latest
    imageID: docker.io/ppc64le/ubuntu@sha256:de1fcbe2d7e928d0be9476e3079df8e69072dfb140be94f5d34091f09f6917dd
    lastState: {}
    name: ubunutu
    ready: true
    resources:
      limits:
        cpu: 10m
      requests:
        cpu: 2m
    restartCount: 0

With this PR changes

spec:
  containers:
  - command:
    - tail
    - -f
    - /dev/null
    image: ppc64le/ubuntu:latest
    imagePullPolicy: Always
    name: ubunutu
    resizePolicy:
    - resourceName: memory
      restartPolicy: RestartContainer
    - resourceName: cpu
      restartPolicy: NotRequired
    resources:
      limits:
        cpu: 1m
      requests:
        cpu: 1m
status:
  .
  .
  .
  containerStatuses:
  - allocatedResources:
      cpu: 1m
    containerID: containerd://20d925e79d30da8daebe343babe11b8a63bfbb5e7d864d3fa455636496790083
    image: docker.io/ppc64le/ubuntu:latest
    imageID: docker.io/ppc64le/ubuntu@sha256:de1fcbe2d7e928d0be9476e3079df8e69072dfb140be94f5d34091f09f6917dd
    lastState: {}
    name: ubunutu
    ready: true
    resources:
      limits:
        cpu: 1m
      requests:
        cpu: 1m
    restartCount: 0
    started: true

k8s-ci-robot · 2023-09-21T06:41:39Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Karthik-K-N
Once this PR has been reviewed and has the lgtm label, please assign klueska for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

pkg/kubelet/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Karthik-K-N · 2023-09-21T08:33:30Z

/cc @Jeffwan

bart0sh · 2023-09-21T09:48:04Z

/cc @vinaykul

bart0sh · 2023-09-21T09:52:58Z

/triage accepted
/priority important-soon

@Karthik-K-N Thank you for the PR! Please, provide release note and cover this use case with unit or e2e test cases, thanks.

Karthik-K-N · 2023-09-22T04:29:59Z

/cc @mkumatag @dharaneeshvrd

pkg/kubelet/kubelet_pods.go

Jeffwan · 2023-10-17T17:07:53Z

A quick question on the current status. If the current status fall back to inconsistent values, does it introduce endless reconcile issues commented here #102884 (comment)

    resources:
      limits:
        cpu: 10m
      requests:
        cpu: 2m

Karthik-K-N · 2023-10-18T04:26:58Z

A quick question on the current status. If the current status fall back to inconsistent values, does it introduce endless reconcile issues commented here #102884 (comment)
    resources:
      limits:
        cpu: 10m
      requests:
        cpu: 2m

Yeah, https://github.com/kubernetes/kubernetes/pull/120791/files#diff-0e1a8d22b0f1dc42d412749c6a916b4c76394ead739d4bfbf26564faedd74a2fR623-R630

tuibeovince · 2023-10-24T08:39:16Z

A quick question on the current status. If the current status fall back to inconsistent values, does it introduce endless reconcile issues commented here #102884 (comment)
    resources:
      limits:
        cpu: 10m
      requests:
        cpu: 2m

May I ask what you mean by "fall back to inconsistent values"?

Karthik-K-N · 2023-10-30T04:44:49Z

A quick question on the current status. If the current status fall back to inconsistent values, does it introduce endless reconcile issues commented here #102884 (comment)
    resources:
      limits:
        cpu: 10m
      requests:
        cpu: 2m
May I ask what you mean by "fall back to inconsistent values"?

I believe its user setting 2m limit vs runtime setting 10m as the values.

k8s-triage-robot · 2024-01-28T04:50:41Z

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

Mark this PR as fresh with /remove-lifecycle stale
Close this PR with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot · 2024-02-27T04:55:26Z

The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

After 90d of inactivity, lifecycle/stale is applied
After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

Mark this PR as fresh with /remove-lifecycle rotten
Close this PR with /close
Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

Karthik-K-N · 2024-02-27T06:02:48Z

/remove-lifecycle rotten

tallclair

Does window's have the same minimum behavior here?

We can't break existing pods with tightening validation, but since resource updates aren't currently allowed outside of this alpha feature, we can apply stricter minimum values on update (only if the value changed). I think that would be worth doing, aside from the above windows question.

I'm also not sure about the desired end state. I feel like it would be better to have the Kubelet interpret all values below the minimum as the minimum, and report the actual used values in the pod status. So from your example, the outcome would be:

spec:
  containers:
  - command:
    - tail
    - -f
    - /dev/null
    image: ppc64le/ubuntu:latest
    imagePullPolicy: Always
    name: ubunutu
    resizePolicy:
    - resourceName: memory
      restartPolicy: RestartContainer
    - resourceName: cpu
      restartPolicy: NotRequired
    resources:
      limits:
        cpu: 1m
      requests:
        cpu: 1m
status:
  .
  .
  .
  containerStatuses:
  - allocatedResources:
      cpu: 2m
    containerID: containerd://43baca32c3f20362057917d8ae22d8e6f820ae5320849a08304ec5891ef9215a
    image: docker.io/ppc64le/ubuntu:latest
    imageID: docker.io/ppc64le/ubuntu@sha256:de1fcbe2d7e928d0be9476e3079df8e69072dfb140be94f5d34091f09f6917dd
    lastState: {}
    name: ubunutu
    ready: true
    resources:
      limits:
        cpu: 10m
      requests:
        cpu: 2m
    restartCount: 0

tallclair · 2024-04-01T21:20:28Z

pkg/kubelet/kuberuntime/kuberuntime_manager.go

@@ -580,10 +580,20 @@ func (m *kubeGenericRuntimeManager) computePodResizeAction(pod *v1.Pod, containe
 			currentMemoryLimit = kubeContainerStatus.Resources.MemoryLimit.Value()
 		}
 		if kubeContainerStatus.Resources.CPULimit != nil {
-			currentCPULimit = kubeContainerStatus.Resources.CPULimit.MilliValue()
+			kubeCurrentCPULimit := kubeContainerStatus.Resources.CPULimit.MilliValue()


this code is a bit confusing, and could benefit from a comment & better variable names.

Suggested change

kubeCurrentCPULimit := kubeContainerStatus.Resources.CPULimit.MilliValue()

runtimeReportedCPULimit := kubeContainerStatus.Resources.CPULimit.MilliValue()

Updated as suggested.

tallclair · 2024-04-01T21:20:48Z

pkg/kubelet/kuberuntime/kuberuntime_manager.go

 		}
 		if kubeContainerStatus.Resources.CPURequest != nil {
-			currentCPURequest = kubeContainerStatus.Resources.CPURequest.MilliValue()
+			kubeCurrentRequest := kubeContainerStatus.Resources.CPURequest.MilliValue()


Suggested change

kubeCurrentRequest := kubeContainerStatus.Resources.CPURequest.MilliValue()

runtimeRecordedCPURequest := kubeContainerStatus.Resources.CPURequest.MilliValue()

Updated as suggested.

tallclair · 2024-04-01T21:23:59Z

pkg/kubelet/kuberuntime/kuberuntime_manager.go

@@ -580,10 +580,20 @@ func (m *kubeGenericRuntimeManager) computePodResizeAction(pod *v1.Pod, containe
 			currentMemoryLimit = kubeContainerStatus.Resources.MemoryLimit.Value()
 		}
 		if kubeContainerStatus.Resources.CPULimit != nil {
-			currentCPULimit = kubeContainerStatus.Resources.CPULimit.MilliValue()
+			kubeCurrentCPULimit := kubeContainerStatus.Resources.CPULimit.MilliValue()
+			if desiredCPULimit <= 10 && kubeCurrentCPULimit <= 10 {


Declare constants for this value. Same for the minimum request below.

Updated as suggested.

tallclair · 2024-04-01T21:59:25Z

/assign

Karthik-K-N · 2024-04-02T10:40:59Z

Does window's have the same minimum behavior here?

I haven't got a chance to check on windoes, May need some help.

I'm also not sure about the desired end state. I feel like it would be better to have the Kubelet interpret all values below the minimum as the minimum, and report the actual used values in the pod status. So from your example, the outcome would be:

I think this is the current behavior, runtime translates the minimum values(1m->2m for requests) and those values are displayed back. If we want to continue with this behavior, we can just fix the endless reconcilation.

tallclair · 2024-04-02T23:16:02Z

I'm also not sure about the desired end state. I feel like it would be better to have the Kubelet interpret all values below the minimum as the minimum, and report the actual used values in the pod status. So from your example, the outcome would be:

I think this is the current behavior, runtime translates the minimum values(1m->2m for requests) and those values are displayed back. If we want to continue with this behavior, we can just fix the endless reconcilation.

It's slightly different, because I'm proposing the Kubelet resolves the minimum for the allocation in the status, so that the allocation represents the real desired state. But yes, I am proposing to fix the reconciliation.

Karthik-K-N · 2024-04-03T02:46:19Z

I'm also not sure about the desired end state. I feel like it would be better to have the Kubelet interpret all values below the minimum as the minimum, and report the actual used values in the pod status. So from your example, the outcome would be:

I think this is the current behavior, runtime translates the minimum values(1m->2m for requests) and those values are displayed back. If we want to continue with this behavior, we can just fix the endless reconcilation.

It's slightly different, because I'm proposing the Kubelet resolves the minimum for the allocation in the status, so that the allocation represents the real desired state. But yes, I am proposing to fix the reconciliation.

I think If I understand correctly what you meant is, instead of runtime setting the minimum value , we need to make kubelet do the calculation to get the convert the actual values to runtime acceptable minimum values. If so how does it make difference.

Currently the values in status are fetched and displayed from runtime. also as per previous discussion we cannot block the user to set values less than the runtime acceptable min values so the user desired state never become actual state. More info can be found here #102884 (comment)

tallclair · 2024-04-03T20:43:57Z

Either way the Kubelet needs to know what the minimum values are, whether that's to prevent the continuous reconcile or to translate the values. The reason I'd prefer the approach I suggested is that the status should reflect the real state, even if it doesn't match the requested state set by the user. I don't think the Kubelet should be translating the value reported by the runtime just so it matches the user's requested state.

Karthik-K-N · 2024-04-04T08:03:37Z

Either way the Kubelet needs to know what the minimum values are, whether that's to prevent the continuous reconcile or to translate the values. The reason I'd prefer the approach I suggested is that the status should reflect the real state, even if it doesn't match the requested state set by the user. I don't think the Kubelet should be translating the value reported by the runtime just so it matches the user's requested state.

I got your point, based on the previous discussion I moved with this approach, may be I will do the necessary changes as suggested and update.

…minimum values

Karthik-K-N · 2024-04-17T12:06:32Z

Made changes only to avoid infinite reconciliation and also now the pod status displays the actual resources used by runtime when the resources are set to minimum.

k8s-ci-robot · 2024-04-17T14:29:25Z

@Karthik-K-N: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-kubernetes-integration	`747b7ff`	link	true	`/test pull-kubernetes-integration`

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

vinaykul · 2024-04-21T01:14:08Z

Either way the Kubelet needs to know what the minimum values are, whether that's to prevent the continuous reconcile or to translate the values. The reason I'd prefer the approach I suggested is that the status should reflect the real state, even if it doesn't match the requested state set by the user. I don't think the Kubelet should be translating the value reported by the runtime just so it matches the user's requested state.

Let me provide another perspective. Today we have o11y tools looking solely at c.Spec.Resources because that’s the only thing available to determine resource config for pods. With this feature, that is no longer true, the assumption is broken, and o11y tools need to adapt to this change. While I really want to avoid contextually interpreting runtime provided resource config when converting to values in the pod status, it may make sense to do so in this case, imho.

I fired up a local cluster and tried out the below pod spec:

apiVersion: v1
kind: Pod
metadata:
  name: orca
spec:
  containers:
  - name: c1
    image: skiibum/testpod:qos
    resources:
      requests:
        "cpu": "1m"
        "memory": "100Mi"
      limits:
        "cpu": "1m"
        "memory": "200Mi"
  - name: c2
    image: skiibum/testpod:qos
    resources:
      requests:
        "cpu": "2m"
      limits:
        "cpu": "2m"
  - name: c3
    image: skiibum/testpod:qos
    resources:
      requests:
        "memory": "100Mi"
  - name: c4
    image: skiibum/testpod:qos
    resources:
      limits:
        "memory": "100Mi"
  - name: c5
    image: skiibum/testpod:qos
    resources:
      requests:
        "cpu": "3m"
      limits:
        "cpu": "3m"
  - name: c6
    image: skiibum/testpod:qos
    resources:
      requests:
        "cpu": "5m"
      limits:
        "cpu": "10m"
  - name: c7
    image: skiibum/testpod:qos
    resources:
      requests:
        "cpu": "8m"
      limits:
        "cpu": "11m"

Consider the resource config reported in the status for the above spec:

...
    type: PodScheduled
  containerStatuses:
  - allocatedResources:
      cpu: 1m
      memory: 100Mi
    containerID: containerd://dbb27617dbcb5dbf33eac916ce4a1012029395ba395c6fd2883656362ac89ebe
    image: docker.io/skiibum/testpod:qos
    imageID: docker.io/skiibum/testpod@sha256:b002bd3862e83d939ae676a909390ff57f662f3e139e0dd1297ffa5b85938250
    lastState: {}
    name: c1
    ready: true
    resources:
      limits:
        cpu: 10m
        memory: 200Mi
      requests:
        cpu: 2m
        memory: 100Mi
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2024-04-21T01:02:26Z"
  - allocatedResources:
      cpu: 2m
    containerID: containerd://c3293b8c124f68fcb8a0319ff78e21ac6106881d109901a3060aa23e1bd28494
    image: docker.io/skiibum/testpod:qos
    imageID: docker.io/skiibum/testpod@sha256:b002bd3862e83d939ae676a909390ff57f662f3e139e0dd1297ffa5b85938250
    lastState: {}
    name: c2
    ready: true
    resources:
      limits:
        cpu: 10m
      requests:
        cpu: 2m
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2024-04-21T01:02:27Z"
  - allocatedResources:
      memory: 100Mi
    containerID: containerd://27c9874c7db64e9760541052792cde9c0663d4f03bfa665b7bfbbe1c0ef2d3ae
    image: docker.io/skiibum/testpod:qos
    imageID: docker.io/skiibum/testpod@sha256:b002bd3862e83d939ae676a909390ff57f662f3e139e0dd1297ffa5b85938250
    lastState: {}
    name: c3
    ready: true
    resources:
      requests:
        cpu: 2m
        memory: 100Mi
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2024-04-21T01:02:27Z"
  - allocatedResources:
      memory: 100Mi
    containerID: containerd://0471105627ba4731d5ce1f975a06b2c23468e80a08b508e80a7a6b7dbb93c711
    image: docker.io/skiibum/testpod:qos
    imageID: docker.io/skiibum/testpod@sha256:b002bd3862e83d939ae676a909390ff57f662f3e139e0dd1297ffa5b85938250
    lastState: {}
    name: c4
    ready: true
    resources:
      limits:
        memory: 100Mi
      requests:
        cpu: 2m
        memory: 100Mi
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2024-04-21T01:02:27Z"
  - allocatedResources:
      cpu: 3m
    containerID: containerd://71d4aa23a4dc61b6261be8544b729b230f58336c4af71e2dd1a632a0290a38d7
    image: docker.io/skiibum/testpod:qos
    imageID: docker.io/skiibum/testpod@sha256:b002bd3862e83d939ae676a909390ff57f662f3e139e0dd1297ffa5b85938250
    lastState: {}
    name: c5
    ready: true
    resources:
      limits:
        cpu: 10m
      requests:
        cpu: 3m
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2024-04-21T01:02:27Z"
  - allocatedResources:
      cpu: 5m
    containerID: containerd://c17d75fab3b40227254c5dbe6429be02c99b8ee1888b6d9e1caf52f0f3c2c9a2
    image: docker.io/skiibum/testpod:qos
    imageID: docker.io/skiibum/testpod@sha256:b002bd3862e83d939ae676a909390ff57f662f3e139e0dd1297ffa5b85938250
    lastState: {}
    name: c6
    ready: true
    resources:
      limits:
        cpu: 10m
      requests:
        cpu: 5m
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2024-04-21T01:02:27Z"
  - allocatedResources:
      cpu: 8m
    containerID: containerd://272cddd35ca16008285f4602f7c74c485301c1e4950a6792b47fb6d2ab291070
    image: docker.io/skiibum/testpod:qos
    imageID: docker.io/skiibum/testpod@sha256:b002bd3862e83d939ae676a909390ff57f662f3e139e0dd1297ffa5b85938250
    lastState: {}
    name: c7
    ready: true
    resources:
      limits:
        cpu: 11m
      requests:
        cpu: 8m
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2024-04-21T01:02:28Z"
  hostIP: 127.0.0.1
  hostIPs:
  - ip: 127.0.0.1
  phase: Running
...

Besides the CPU requests/limits not matching what was requested, it really looks inconsistent and "off" that user sees CPU requests in the status when none was specified in the spec, however the same is not true for memory even though there has to be some minimum RSS allocated just to start the container process.

If any o11y tools have alerts setup such as “trigger pager if pod-obj-resources != pod-spec-resources”, we risk breaking them. By not interpreting the value as above, I suspect we inadvertently pass on the Linux kernel CFS nuances to the user, and shift the burden of interpreting this special case to the users. Hypothetically, if tomorrow we discover windows has some other nuance, then all consuming o11y tools would need to do something like “switch node-os { case linux: interpret_linux(); case windows: interpret_windows(); … }

Any other time, I’d vote to display unfiltered observed values in the status. But given the ambiguity of this situation, I’m leaning towards a solution that makes the end user’s life easier.

k8s-ci-robot added area/kubelet sig/node Categorizes an issue or PR as relevant to SIG Node. and removed do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Sep 21, 2023

k8s-ci-robot requested review from bobbypage and mrunalp September 21, 2023 06:42

k8s-ci-robot requested a review from Jeffwan September 21, 2023 08:33

bart0sh added this to Triage in SIG Node PR Triage Sep 21, 2023

k8s-ci-robot requested a review from vinaykul September 21, 2023 09:48

bart0sh moved this from Triage to Needs Reviewer in SIG Node PR Triage Sep 21, 2023

k8s-ci-robot added release-note-none Denotes a PR that doesn't merit a release note. and removed do-not-merge/release-note-label-needed Indicates that a PR should not merge because it's missing one of the release note labels. labels Sep 21, 2023

k8s-ci-robot requested review from dharaneeshvrd and mkumatag September 22, 2023 04:30

Karthik-K-N force-pushed the fix-request branch from a1b2cca to 3d0689e Compare September 26, 2023 14:53

Karthik-K-N force-pushed the fix-request branch from 5f5d17a to c86ed2e Compare October 5, 2023 11:03

tuibeovince reviewed Oct 12, 2023

View reviewed changes

pkg/kubelet/kubelet_pods.go Outdated Show resolved Hide resolved

Karthik-K-N force-pushed the fix-request branch from c86ed2e to 1dc3916 Compare October 12, 2023 11:48

tuibeovince reviewed Oct 16, 2023

View reviewed changes

pkg/kubelet/kubelet_pods.go Outdated Show resolved Hide resolved

k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 28, 2024

k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Feb 27, 2024

k8s-ci-robot removed the lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. label Feb 27, 2024

tallclair reviewed Apr 1, 2024

View reviewed changes

k8s-ci-robot assigned tallclair Apr 1, 2024

Karthik-K-N force-pushed the fix-request branch from 1dc3916 to aa6c4a9 Compare April 2, 2024 10:30

Karthik-K-N force-pushed the fix-request branch from aa6c4a9 to 34b1527 Compare April 17, 2024 09:03

Avoid infinite reconciliation whe cpu request and limit are set with …

747b7ff

…minimum values

Karthik-K-N force-pushed the fix-request branch from 34b1527 to 747b7ff Compare April 17, 2024 12:05

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Handle the case where container resource and request set to minimum values #120791

Handle the case where container resource and request set to minimum values #120791

Karthik-K-N commented Sep 21, 2023 •

edited

k8s-ci-robot commented Sep 21, 2023

Karthik-K-N commented Sep 21, 2023

bart0sh commented Sep 21, 2023

bart0sh commented Sep 21, 2023

Karthik-K-N commented Sep 22, 2023

Jeffwan commented Oct 17, 2023

Karthik-K-N commented Oct 18, 2023

tuibeovince commented Oct 24, 2023

Karthik-K-N commented Oct 30, 2023

k8s-triage-robot commented Jan 28, 2024

k8s-triage-robot commented Feb 27, 2024

Karthik-K-N commented Feb 27, 2024

tallclair left a comment

tallclair Apr 1, 2024

Karthik-K-N Apr 2, 2024

tallclair Apr 1, 2024

Karthik-K-N Apr 2, 2024

tallclair Apr 1, 2024

Karthik-K-N Apr 2, 2024

tallclair commented Apr 1, 2024

Karthik-K-N commented Apr 2, 2024

tallclair commented Apr 2, 2024

Karthik-K-N commented Apr 3, 2024

tallclair commented Apr 3, 2024

Karthik-K-N commented Apr 4, 2024

Karthik-K-N commented Apr 17, 2024

k8s-ci-robot commented Apr 17, 2024

vinaykul commented Apr 21, 2024

	kubeCurrentCPULimit := kubeContainerStatus.Resources.CPULimit.MilliValue()
	runtimeReportedCPULimit := kubeContainerStatus.Resources.CPULimit.MilliValue()

	kubeCurrentRequest := kubeContainerStatus.Resources.CPURequest.MilliValue()
	runtimeRecordedCPURequest := kubeContainerStatus.Resources.CPURequest.MilliValue()

Handle the case where container resource and request set to minimum values #120791

Are you sure you want to change the base?

Handle the case where container resource and request set to minimum values #120791

Conversation

Karthik-K-N commented Sep 21, 2023 • edited

What type of PR is this?

What this PR does / why we need it:

Which issue(s) this PR fixes:

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

k8s-ci-robot commented Sep 21, 2023

Karthik-K-N commented Sep 21, 2023

bart0sh commented Sep 21, 2023

bart0sh commented Sep 21, 2023

Karthik-K-N commented Sep 22, 2023

Jeffwan commented Oct 17, 2023

Karthik-K-N commented Oct 18, 2023

tuibeovince commented Oct 24, 2023

Karthik-K-N commented Oct 30, 2023

k8s-triage-robot commented Jan 28, 2024

k8s-triage-robot commented Feb 27, 2024

Karthik-K-N commented Feb 27, 2024

tallclair left a comment

Choose a reason for hiding this comment

tallclair Apr 1, 2024

Choose a reason for hiding this comment

Karthik-K-N Apr 2, 2024

Choose a reason for hiding this comment

tallclair Apr 1, 2024

Choose a reason for hiding this comment

Karthik-K-N Apr 2, 2024

Choose a reason for hiding this comment

tallclair Apr 1, 2024

Choose a reason for hiding this comment

Karthik-K-N Apr 2, 2024

Choose a reason for hiding this comment

tallclair commented Apr 1, 2024

Karthik-K-N commented Apr 2, 2024

tallclair commented Apr 2, 2024

Karthik-K-N commented Apr 3, 2024

tallclair commented Apr 3, 2024

Karthik-K-N commented Apr 4, 2024

Karthik-K-N commented Apr 17, 2024

k8s-ci-robot commented Apr 17, 2024

vinaykul commented Apr 21, 2024

Karthik-K-N commented Sep 21, 2023 •

edited