Skip to content

In-Place Update of Pod Resources #1287

Closed

Description

@vinaykul

Enhancement Description

Please to keep this description up to date. This will help the Enhancement Team track efficiently the evolution of the enhancement

  1. Identify CRI changes needed for UpdateContainerResources API, define response message for UpdateContainerResources

    • Extend UpdateContainerResources API to return info such as ‘not supported’, ‘not enough memory’, ‘successful’, ‘pending page evictions’ etc.
    • Define expected behavior for runtime when UpdateContainerResources is invoked. Define timeout duration of the CRI call.
      • Resolution: Separate KEP for CRI changes.
        • Discussed draft CRI changes with SIG-Node on Oct 22, and we agreed to do this as an incremental change outside the scope of this KEP, in a new mini-KEP. It does not block implementation of this KEP.
  2. Define behavior when multiple containers are being resized, and UpdateContainerResources fails for one or more containers.

    • One Possible solution:
      • Do not update Status.Resources.Limits if UpdateContainerResources API fails, and keep retrying until it succeeds.
  3. Check with API reviewers if we can keep maps instead list of named sub-objects for ResizePolicy.

    • After discussion with @liggitt , we are going to use list of named subobjects for extensibility.
  4. Can we find a more intuitive name for ResizePolicy?

  5. Can we use ResourceVersion to figure out the ordering of Pod resize requests?

  6. Do we need to add back the ‘RestartPod’ resize policy? Is there a strong use-case for it?

    • Resolution: No.
      • Discussed with SIG-Node on Oct 15th, not adding RestartPod policy for simplicity, will revisit if we encounter problems.

Alpha Feature Code Issues:
These are Items and issues discovered during code review that need further discussion and need to be addressed before Beta.

  1. Can we figure out GetPodQOS differently once it is determined on pod create? See In-place Pod Vertical Scaling feature kubernetes#102884 (comment)
  2. How do we deal with a pod that requests 1m/1m cpu requests/limits. See In-place Pod Vertical Scaling feature kubernetes#102884 (comment)
  3. Add internal representation of ContainerStatus.Resources in kubeContainer. Convert it to ContainerStatus.Resources in kubelet_pods generate functions. See In-place Pod Vertical Scaling feature kubernetes#102884 (comment) and In-place Pod Vertical Scaling feature kubernetes#102884 (comment) and In-place Pod Vertical Scaling feature kubernetes#102884 (comment)
  4. Can we get rid of resize mutex? Is there a better way to handle resize retries? See In-place Pod Vertical Scaling feature kubernetes#102884 (comment)
  5. Can we recover from resize checkpoint store failures? See In-place Pod Vertical Scaling feature kubernetes#102884 (comment)
  6. CRI clarification for ContainerStatus.Resources and how to handle runtimes that don't support it. See In-place Pod Vertical Scaling feature kubernetes#102884 (comment)
  7. Add real values to dockershim test for ContainerStatus.Resources In-place Pod Vertical Scaling feature kubernetes#102884 (comment)
    • Resolution: Not required due to dockershim deprecation.
  8. Change PodStatus.Resources from v1.ResourceRequirements to *v1.ResourceRequirements
    • Resolution: Fixed
  9. Address all places in the code that has 'TODO(vinaykul)'
  10. Current implementation does not work with node toploogy manager enabled. This limitation is not capturedi in the KEP. Add this to the release documentation for alpha, we will address this in beta. See In-place Pod Vertical Scaling feature kubernetes#102884 (comment)

Activity

  1. added
    needs-sigIndicates an issue or PR lacks a `sig/foo` label and requires one.
    on Oct 8, 2019
  2. vinaykul commented on Oct 8, 2019

    @vinaykul
    MemberAuthor

    /assign @vinaykul

  3. jeremyrickard commented on Oct 9, 2019

    @jeremyrickard
    Contributor

    👋 Hey there @vinaykul. I'm a shadow on the 1.17 Release Team, working on Enhancements. We're tracking issues for the 1.17 release and I wanted to reach out and ask we should track this (or more specifically I guess the In-Place Update of Pod Resources feature) for 1.17?

    The current release schedule is:

    Monday, September 23 - Release Cycle Begins
    Tuesday, October 15, EOD PST - Enhancements Freeze
    Thursday, November 14, EOD PST - Code Freeze
    Tuesday, November 22 - Docs must be completed and reviewed
    Monday, December 9 - Kubernetes 1.17.0 Released

    We're only 5 days away from the Enhancements Freeze, so if you intend to graduate this capability in the 1.17 release, here are the requirements that you'll need to satisfy:

    • KEP must be merged in implementable state
    • KEP must define graduation criteria
    • KEP must have a test plan defined

    Thanks @vinaykul

  4. vinaykul commented on Oct 10, 2019

    @vinaykul
    MemberAuthor
    • KEP must be merged in implementable state
    • KEP must define graduation criteria
    • KEP must have a test plan defined

    Hi @jeremyrickard I'll do my best to get this KEP to implementable state by next Tuesday, but it looks like a stretch at this point - the major item is to complete API review with @thockin , and that depends on his availability.

    The actual code changes are not that big. Nevertheless, the safe option would be to track this for 1.18.0 release, I'll update you by next Monday.

    CC: @dashpole @derekwaynecarr @dchen1107

  5. added
    sig/autoscalingCategorizes an issue or PR as relevant to SIG Autoscaling.
    sig/nodeCategorizes an issue or PR as relevant to SIG Node.
    on Oct 14, 2019
  6. removed
    needs-sigIndicates an issue or PR lacks a `sig/foo` label and requires one.
    on Oct 14, 2019
  7. added
    tracked/noDenotes an enhancement issue is NOT actively being tracked by the Release Team
    tracked/yesDenotes an enhancement issue is actively being tracked by the Release Team
    and removed
    tracked/noDenotes an enhancement issue is NOT actively being tracked by the Release Team
    on Oct 14, 2019
  8. added this to the v1.17 milestone on Oct 14, 2019
  9. vinaykul commented on Oct 14, 2019

    @vinaykul
    MemberAuthor

    @jeremyrickard @mrbobbytables This KEP will take some more discussion - key thing is API review. It does not look like @thockin or another API reviewer is available soon. Could we please track this KEP for v1.18?
    Thanks,

  10. jeremyrickard commented on Oct 14, 2019

    @jeremyrickard
    Contributor

    /milestone v1.18

  11. 527 remaining items

  12. clovisbernard commented on Dec 29, 2025

    @clovisbernard

    What will happens if the node holding the pod doesn't have enough resource to fit the new pod's resource?

  13. vinaykul commented on Dec 29, 2025

    @vinaykul
    MemberAuthor

    What will happens if the node holding the pod doesn't have enough resource to fit the new pod's resource?

    @clovisbernard The status of requested resize will either show as Deferred or show as Infeasible depending on the gap. Please see https://kubernetes.io/docs/tasks/configure-pod-container/resize-container-resources/#pod-resize-status for details.

  14. vinaykul commented on Dec 29, 2025

    @vinaykul
    MemberAuthor

    @tallclair @natasha41575 Can we finally close this issue now?

  15. natasha41575 commented on Dec 29, 2025

    @natasha41575
    Contributor

    @tallclair @natasha41575 Can we finally close this issue now?

    Yeah, I'll open a PR to mark the KEP as implemented shortly and mark it as fixing this issue

  16. jmickey commented on Jan 15, 2026

    @jmickey
    Member

    Hi @natasha41575 @tallclair 👋, v1.36 Enhancements Lead here,

    Given that this KEP has graduated to stable, if all the work is completed, once #5761 is merged please close the issue, thanks!

    /remove-label lead-opted-in
    /remove-label tracked/yes
    /stage stable

  17. added
    stage/stableDenotes an issue tracking an enhancement targeted for Stable/GA status
    and removed
    stage/betaDenotes an issue tracking an enhancement targeted for Beta status
    lead-opted-inDenotes that an issue has been opted in to a release
    tracked/yesDenotes an enhancement issue is actively being tracked by the Release Team
    on Jan 15, 2026
  18. moved this from In Progress to Closed in SIG Schedulingon Jan 16, 2026
  19. moved this from Done to Not for release in SIG Node 1.36 KEPs planningon May 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

kind/api-changeCategorizes issue or PR as related to adding, removing, or otherwise changing an APIsig/autoscalingCategorizes an issue or PR as relevant to SIG Autoscaling.sig/nodeCategorizes an issue or PR as relevant to SIG Node.sig/schedulingCategorizes an issue or PR as relevant to SIG Scheduling.stage/stableDenotes an issue tracking an enhancement targeted for Stable/GA status

Type

No type

Projects

Relationships

None yet

Development

No branches or pull requests

Issue actions

⌂ Proxy