KEP-5972: Dynamic (mutable) Containers

[Tim Allclair]

I want to raise the visibility of KEP-5972: Dynamic Containers, which proposes making the (main) containers list in a pod mutable while a pod is running.

The KEP has the full design details in it, but it's worth noting that this change mostly builds on the work done for in-place pod resize, so the net code change is actually relatively small. The primary concern that's been raised is around ecosystem tooling that assumes containers never change. We will be engaging in proactive research and outreach as part of the Beta graduation criteria to mitigate this issue.

The next SIG-Arch meeting isn't until after KEP freeze, so please comment on the KEP or respond here with any questions or concerns.

Thank you.

-- Tim Allclair (tallclair)

[Tim Allclair]

On Fri, Jun 12, 2026 at 7:50 AM Michael Taufen <mta...@google.com> wrote:

Should we do something special in admission control to ensure that Pod-oriented security policies that previously only ran on create will automatically be run on update, to avoid policy gaps when this is enabled?

The mitigations for this are:

1. For 1st party security controls (e.g. PodSecurityAdmission), they'll be updated to ensure coverage.

2. Dynamically added containers are not allowed to escalate security permissions. See the section "No SecurityContext Escalations". This does treat these as independent axes though.

3. User communications & outreach (release notes, announcements, etc.)

I don't think we can force general 3rd party admission controllers that run on pod create to also run on pod update.

 

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CALXpagwCBhzqiXp4jKRf5Dv5SMuw4auZQmtrhH5A9YeC2aUhtw%40mail.gmail.com.

[John Belamaric]

Tim - please send future email to sig-arch...@kubernetes.io as the older list is deprecated.

To view this discussion visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CALXpagxmVSxHxmm%2B4WGkuQ735xYVpJsRKyEviqU4qiFgkeRGJw%40mail.gmail.com.

[Tim Allclair]

This went out to the wrong sig-arch mailing list: +sig-arc...@kubernetes.io 

> The most immediate failure that I see is a lack of beta requirements that include moving major ecosystem projects to tolerate this change before enabling the feature by default, but a major value of the community is bringing together multiple perspectives.

That was my intention with this beta criteria: "Ecosystem research & outreach for static container assumptions", but I can flesh that out to be more explicit.

There's also an ongoing discussion with Derek on the KEP itself about making dynamic containers a more explicit opt-in through an RBAC subresource.

I'll let Dawn respond to the specific SIG-Architecture involvement concerns.

On Fri, Jun 12, 2026 at 10:02 AM David Eads <de...@redhat.com> wrote:

Failure to open the PR in time for a sig-arch meeting is not a valid argument to steamroll a massive architectural change into the project without time for structured community feedback.  The most immediate failure that I see is a lack of beta requirements that include moving major ecosystem projects to tolerate this change before enabling the feature by default, but a major value of the community is bringing together multiple perspectives.  The behavior of "I opened it too late to discuss, please contain to this email thread and prioritize merge" is not in keeping with the past decade of consensus building and does not reflect the need to bring our community along with us for major architectural shifts.

DE2

To view this discussion visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CALXpagxmVSxHxmm%2B4WGkuQ735xYVpJsRKyEviqU4qiFgkeRGJw%40mail.gmail.com.

[David Eads]

 The next SIG-Arch meeting isn't until after KEP freeze, so please comment on the KEP or respond here with any questions or concerns.

Failure to open the PR in time for a sig-arch meeting is not a valid argument to steamroll a massive architectural change into the project without time for structured community feedback.  The behavior of "I opened it too late to discuss, please contain to this email thread and prioritize merge" is not in keeping with the past decade of consensus building and does not reflect the need to bring our community along with us for major architectural shifts.  Given common sig meeting cadences of two weeks, having at least a month for feedback on a KEP for a change this large is far more reasonable than five working days.  We rely on community review to build better designs.

Separately from the mechanism of introducing the change, my most immediate concern is the lack of beta requirements that include moving major ecosystem projects to tolerate this change before enabling the feature by default.  

DE2