Hello everyone,
In the current Kubernetes implementation, any modification to specifications of StatefulSets or Deployments, such as changes to spec.templates.container[*].resources, typically triggers a Pod rebuild. This process can lead to interruptions in business traffic and service jitters, especially in production environments. Considering that modifying container resources essentially involves adjusting cgroup parameters, I am wondering if it’s possible to implement these changes through an in-place upgrade of the Pod, without a rebuild.
Additionally, for changes to metadata like spec.templates.metadata.labels and annotations, since these fields are static metadata, could we consider applying them directly to the Pod via a patch operation, without necessitating a rebuild?
Furthermore, regarding updates to container images (spec.templates.container[*].image), is there a possibility to only restart the affected container instead of the entire Pod?
Based on these considerations, I propose that the community explores the possibility of introducing an “In-Place-If-Possible” upgrade mechanism. This mechanism would first attempt an in-place upgrade, and if the current modifications are not supported, it would fallback to the full rebuild upgrade process.
I believe such an enhancement would greatly increase the flexibility and stability of Kubernetes in production environments. I hope we can initiate a discussion on this topic to see if it is feasible to implement such a feature in future releases.
Thank you all for your time and consideration!