Exception Request for KEP-5972: Dynamic Containers

[Tim Allclair]

Enhancement name: Dynamic Containers
Enhancement status: Alpha
SIG: SIG-Node
k/enhancements repo issue #: https://github.com/kubernetes/enhancements/issues/5972
PR #’s: https://github.com/kubernetes/enhancements/pull/6169
Additional time needed (in calendar days, due end of day AoE): 3 days

Reason this enhancement is critical for this milestone: This feature is part of a broader strategy to evolve Kubernetes to meet the new demands brought by AI and agentic workloads. Risks from adding code late: N/A, this is a KEP.
Risks from cutting enhancement: Delaying this KEP will push back the execution by 4 months, which is a very significant delay in the fast development pace of the modern agentic landscape.

The KEP still has very active discussion ongoing, but the design has remained very stable through the discussions. We need a few more days to wrap up the ongoing conversations.

[David Eads]

I do not agree.  I think the timeframe remaining is 2.5 weeks.

I have repeatedly indicated, as had Mo (Microsoft), and Jordan (Google), that this KEP is a change with far reaching implications that was posted only five days before freeze.  It failed to list *any* participating sigs.  It appears to have been a surprise to just about everyone who did not work at Google. The community has not had time to meaningfully review this KEP and the implications that mutation of 10year+ immutable fields bring.

Characterizing the design as stable is not an accurate reflection of its state.  Even with a cursory glance from others considering the problem, even the endpoint being proposed has changed with initial designs not accounting for even basic security expectations.

I recommend rejecting this exception request.

[David Eads]

I do not agree.  I think the timeframe remaining is 2.5 weeks.

I have repeatedly indicated, as had Mo (Microsoft), and Jordan (Google), that this KEP is a change with far reaching implications that was posted only five days before freeze.  It failed to list *any* participating sigs.  It appears to have been a surprise to just about everyone who did not work at Google. The community has not had time to meaningfully review this KEP and the implications that mutation of 10year+ immutable fields bring.

Characterizing the design as stable is not an accurate reflection of its state.  Even with a cursory glance from others considering the problem, even the endpoint being proposed has changed with initial designs not accounting for even basic security expectations.

I recommend rejecting this exception request.

On Tuesday, June 16, 2026 at 7:31:48 PM UTC-4 Tim Allclair wrote:

[Davanum Srinivas]

Some additional context here:

https://groups.google.com/a/kubernetes.io/g/sig-architecture/c/dpsLnuc5Re8/m/8D8SmoSXAwAJ

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-re...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/kubernetes-sig-release/CALXpagya52DxtE-xBJVuyyLM-JhdtF%2BB-h%2Ba7b0OYDrsP-Y%2BEw%40mail.gmail.com.

--

Davanum Srinivas :: https://twitter.com/dims

[Dawn Chen]

While I have reviewed and approved several exception requests representing SIG Node for the 1.37 release, I am formally recusing myself from executing the final SIG approval on this one because of my direct involvement with this KEP. I will defer that final sign-off decision to the other leads:  +Derek Carr +Mrunal Patel +Peter Hunt. 

However, to ensure the Release Team has the accurate context needed to evaluate this request, I want to clarify the factual timeline and the evolution of the design:

1. The Timeline: This KEP was opened 9 days prior to the freeze, not 5. It is the direct output of a comprehensive design specification introduced and reviewed within SIG Node a month and a half ago with active participation from maintainers across multiple companies (including Red Hat, Intel, Nvidia, and Uber etc.). This work represents the logical culmination of a multi-year effort to adapt node primitives for modern AI/HPC infrastructure (including In-Place Pod Resizing, writable cgroups, and DRA CPU drivers) that has been actively socialized across multiple KubeCon cycles. 

2. The Design State: Characterizing the active iteration on the security boundary as 'design instability' misinterprets our collaborative development process. When senior API and Node reviewers raised critical concerns regarding the standard Pod UPDATE boundary, the authors actively collaborated to pivot the design to a dedicated API subresource requiring explicit mutability intent at Pod creation time.

This community-driven pivot fundamentally bounds the blast radius by default, ensuring zero behavioral impact on standard ecosystem controllers. Refining a design to incorporate expert feedback from API machinery and security maintainers is exactly how a healthy KEP is hardened before code is written.

The requested 3-day extension is strictly to allow the team to formally update the KEP with this subresource architecture ahead of the upcoming bi-weekly SIG Arch meeting. I welcome Derek and others' final evaluation of this KEP's readiness for 1.37 alpha.

Thanks,

Dawn

You received this message because you are subscribed to the Google Groups "sig-node" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sig-node+u...@kubernetes.io.
To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/sig-node/CANw6fcHowB_edqR2upmC6Z_T5pgq%3D1Mg4FAmJhAbh__gUZhxVw%40mail.gmail.com.

[Tim Allclair]

Thank you Dawn. I just want to make minor correction: the KEP has already been updated with the new subresource approach (as of yesterday). This is actually very close to the original request design.

To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/sig-node/CAJo%3DGk5rdBqyZhVQWTDWV2EpzXW0jcpsDNaTYaSQJSFkfyzSgQ%40mail.gmail.com.

[Peter Hunt]

I am inclined to approve this exception request. While I hear the concerns about ecosystem awareness, putting on my SIG node hat I have been aware of this proposal and believe it makes sense to continue deliberation on a feasible direction. Whether that initial direction is the entirety of what is proposed for alpha, or something similar to what Jordan mentioned in a comment can be hashed out in the proposal. I'll defer to @Derek Carr and @Mrunal Patel as tech leads, though.

[Derek Carr]

To recap the present state of the KEP:

I empathize with the urgency we all feel to keep pace with the fast-moving agentic sandboxing landscape.  In this case, the author responded to the actionable feedback I provided by narrowing the potential impact to workload types that may not require a two-level scheduling solution.

TLs from SIG Auth have requested a hold on the KEP to allow time for additional review.  The impact this has on authorization seems to be a shared concern.  It is improper for me to approve this exception and the KEP without letting them enumerate actionable concerns to remedy.  This also would provide opportunities for other SIGs and the broader ecosystem to weigh in as they see fit.

Instead of being bound by the existing process, what if we just let the process adjust to the urgency of the moment?  Would there be an objection to ask if we can try and reach closure on this prior to July 4?

Thanks,

Derek

[Tim Allclair]

Yes, that is what I was asking for here: an extension to continue the conversation. Approving the extension is NOT the same as approving the KEP, it is just allowing the conversation to continue.

To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/sig-node/CAHROWxT3VZCMW%2BDWrgPMZ%3DU-TMaqfGAyhtDNLG0ek19a%3DWvZ8g%40mail.gmail.com.

[Kat Cosgrove]

To be clear:

Are you now asking for an exception request extension to July 4?

To view this discussion visit https://groups.google.com/d/msgid/kubernetes-sig-release/CADtktAW600K3rubaKXtvcAt60g_R11O4DEs3TyyjvGFJAqZDDg%40mail.gmail.com.

[David Eads]

July 4 is an acceptable time period for community comment on a KEP of such magnitude.

[Davanum Srinivas]

> Would there be an objection to ask if we can try and reach closure on this prior to July 4?

+1 to keep talking until July 4th.

[Tim Allclair]

This is also being discussed on slack: https://kubernetes.slack.com/archives/C2C40FMNF/p1781716437360259

The revised proposal is a 9-day extension to June 26th (AoE). This lets us discuss the KEP in the upcoming SIG-Architecture meeting, and adds 1 day to allow for any changes proposed in that meeting. I will also present at SIG-Auth today.

[Kat Cosgrove]

It is after hours for Dipesh (the release lead), but we spoke earlier.

In light of the concerns raised by SIG Auth in Slack, and our own concerns about subsequent deadlines within the release cycle while still allowing suitable time for public comment, the release team is DENYING this exception request.

We would like to see work on this KEP continue, and are happy to discuss how to support that during the v1.37 cycle so that it can land in the v1.38 cycle.

To view this discussion visit https://groups.google.com/d/msgid/kubernetes-sig-release/CALXpagwexJxYM__KiRRdc8UAJ3jLL%2BnUR3%2BjLXUw41w0arAg8Q%40mail.gmail.com.

[Davanum Srinivas]

thanks Kat.

Since Kat said "We would like to see work on this KEP continue" ... 

Question to Tim Allclair, How do we keep it going? Do we want to think of some creative options? Go back to trying a feature branch?

[Tim Allclair]

I think the most important piece is continuing discussions around this feature so it is pre-approved for v1.38, ideally with a clear path to beta in v1.39.

On the implementation side, many of the Kubelet changes required to implement this have broader applications, and don't need to be feature gated (for example, improvements to garbage collection, handling of unknown containers, and prober improvements). I plan to proceed with those changes in v1.37. I'm not sure the remaining work is large enough to warrant a dedicated development branch. We can probably just iterate on some draft PRs.

To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/sig-node/CANw6fcEEDGhr2qdz99SFNDsoHTtJ8fxK7DQxeJPdjzec76nY-g%40mail.gmail.com.

[Kevin Hannon]

Adding this item to the agenda for the next sig-architecture meeting would be a good step. It's best to maintain momentum on the design while it's fresh in our minds.

To view this discussion visit https://groups.google.com/a/kubernetes.io/d/msgid/sig-node/CADtktAUbjGJuLKUFFH3g7G0iuoNHQkd3PDcYta2geoP3Z_wDpg%40mail.gmail.com.

[David Eads]

Tim added it already.  I've also added an item about whether we can increase our release cadence to match the desired pace of change.

[Kat Cosgrove]

Just a heads up, it's obviously fine if that discussion is to determine whether or not you want to propose a 4th release, but ultimately the decision belongs to SIG Release, not SIG Arch. 

[David Eads]

Thanks.  I think it's probably good for sig-arch (people like Tim Hockin, John Belamaric, myself, Mo, Jordan, and many others usually attend) to decide if we think it's worthy of bringing up to sig-release.

DE2