In-place Pod resizing #194
Conversation
Signed-off-by: Jakub Scholz <[email protected]>
scholzj
requested review from
Frawless,
PaulRMellor,
im-konge,
katheris,
ppatierno,
samuel-hawker,
see-quick,
sknot-rh and
tombentley
PaulRMellor
left a comment
PaulRMellor
left a comment
There was a problem hiding this comment.
I found the accompanying video helpful, and the rationale and limitations are clearly explained. The proposal introduces an improved approach to resizing, and documenting it as experimental is appropriate given the current limitations.
im-konge
left a comment
im-konge
left a comment
There was a problem hiding this comment.
LGTM, thanks for the proposal and the demo - it was really nice to see how it works :) I left just few small comments.
Co-authored-by: PaulRMellor <[email protected]> Co-authored-by: Lukáš Král <[email protected]> Signed-off-by: Jakub Scholz <[email protected]>
Signed-off-by: Jakub Scholz <[email protected]>
|
This proposal now has 3 binding +1 votes (plus mine implicit). If there are no new comments by the end of Tuesday, I will close it as approved. |
ppatierno
left a comment
ppatierno
left a comment
There was a problem hiding this comment.
Thanks for the proposal. I left some comments/questions for better understanding of how this feature works and has an impact on Strimzi.
129-in-place-pod-resizing.md
Outdated
| In-place Pod resizing allows dynamically resizing Kafka broker Pods without necessarily restarting them. | ||
| However, Cruise Control maintains its own configuration that includes the CPU and memory capacity of Kafka brokers. | ||
| This configuration is not updated dynamically. | ||
| As a result, when broker resource requirements change, the Kafka broker Pods might not roll, but the Cruise Control Pod must be restarted to apply the updated capacity information. |
There was a problem hiding this comment.
"must be restarted" ... is the operator doing it automatically?
There was a problem hiding this comment.
This is done by the same mechanism as today. Nothing changed here. I made it more clear in the proposal.
Signed-off-by: Jakub Scholz <[email protected]>
| _Note: In-place resizing will not be supported for `KafkaBridge`, because it does not use the `StrimziPodSet` resources._ | ||
| _`KafkaBridge` is using Kubernetes `Deployment` and Strimzi is managing only the `Deployment` resource it self._ | ||
| _So when resource configuration is changed in `KafkaBridge`, the change is propagated by Strimzi Cluster Operator into the `Deployment` resource._ | ||
| _And it is up to Kubernetes to decide how to handle it - and Kubernetes will currently roll the Pod in this case rather than use the in-place Pod resizing._ |
There was a problem hiding this comment.
"and Kubernetes will currently roll the Pod in this case rather than use the in-place Pod resizing" ... is this always true? even if the Kubernetes version supports the in-place pod resizing? Where I can find more about it, I tried to look at doc but couldn't find any direct reference to how a Deployment resources change is handled.
There was a problem hiding this comment.
I'm not aware of any documentation as there was no change and no assumption of change on how Kubernetes do this. But you should be able to try it on Kube 1.35 yourself.
5 participants
This proposal suggests adding support for in-place Pod resizing to Strimzi.
If anyone is interested, I have a short demo of my prototype https://youtu.be/983tFK2327A and source code https://github.com/strimzi/strimzi-kafka-operator/compare/main...scholzj:strimzi-kafka-operator:in-place-pod-resizing?expand=1.