Re: KEP-5972: Dynamic (mutable) Containers

[John Belamaric]

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

On Fri, Jun 12, 2026 at 9:30 AM Tim Allclair <timal...@gmail.com> wrote:

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.

 

On Thu, Jun 11, 2026, 5:03 PM Tim Allclair <timal...@gmail.com> wrote:

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)

--
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.

--
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/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

[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

[Dawn Chen]

Hi David and SIG Architecture,

Thank you, David, for raising your concerns.  I want to take personal responsibility for the timing of this KEP reaching SIG Arch. With the current explosion of new AI-native and Agentic infrastructure, the community is facing an immediate choice: we must adapt the Kubernetes execution envelope to support these ultra-low-latency workloads now, or risk the industry building around us. Recognizing this urgency, I advised Tim to push forward with the PR to capture this current release cycle as an off-by-default Alpha rather than delaying for a prolonged upfront cross-SIG review. If there was a gap in communication with SIG Arch, that is entirely on me.

However, we did recognize the cross-cutting nature of this feature early on and proactively engaged the most critical areas, such as reaching out individually to SIG Auth and SIG Node maintainers, to map out the immediate boundary risks before opening the PR. Tim also reached out to several API reviewers upfront before the PR. The impact on SIG scheduling was discussed via the in-place pod resizing feature previously. 

Meanwhile, I want to emphasize that this proposal strictly follows the community's established KEP Process Guidelines. Per the community definition, the Alpha stage is explicitly intended for early feedback, prototyping, and exploring ideas behind an off-by-default feature gate, without requiring all ecosystem details to be fully worked out on day one. Remember, even after KEP approval, we can delay or stop the release of the feature in 1.37. With alpha, we can even cancel it after the 1.37 release. So proceeding at this point does not add any risk to any production environments.

To David’s specific point regarding ecosystem readiness: Tim explicitly included those exact requirements in the graduation criteria. The KEP mandates comprehensive ecosystem research and outreach regarding static container assumptions as a hard gate for Beta graduation, which perfectly aligns with the KEP process framework where system stability and compatibility are hardened.

Furthermore, this isn't a sudden architectural pivot. Like I replied in PR yesterday, this design is the logical culmination of a multi-year roadmap. Features we have already upstreamed, like In-Place Pod resizing, writable cgroups, and Pod-level resource, CPU DRA driver, etc. were systematically built as the technical foundation for this exact capability.

Derek has raised brilliant architectural alternatives regarding security and RBAC isolation. To eliminate the risk of expanding the standard Pod UPDATE verb and accidentally over-granting privileges to ecosystem controllers, we plan to update the KEP for this milestone to isolate this capability behind a dedicated subresource that requires explicit opt-in through RBAC permissions.

While I value your opinion of having a more extensive review, we can honor both process and velocity by proceeding with Alpha this milestone. This stage provides a disabled-by-default sandbox to gather the real-world data needed to address your concerns for Beta. Let’s use the upcoming bi-weekly SIG Arch meeting to refine graduation requirements and align on ecosystem outreach while maintaining the momentum needed for this fast-moving space.

Best, 

Dawn Chen