You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue to collect thoughts and best practices for handling automatic node pool upgrades.
In GKE, nodepool upgrades are handled via one of two strategies: surge or blue-green. It doesn't seem like either of these will play well with the Redpanda Operator, which currently only decommissions brokers when the replica count changes. The old node(s) and pods will be destroyed, then the pods will get scheduled on the new nodes (I think?), and the cluster will have a perpetually missing broker until it's manually force-decommissioned.
Presumably EKS and AKS have similar functionality.
Issue to collect thoughts and best practices for handling automatic node pool upgrades.
In GKE, nodepool upgrades are handled via one of two strategies: surge or blue-green. It doesn't seem like either of these will play well with the Redpanda Operator, which currently only decommissions brokers when the replica count changes. The old node(s) and pods will be destroyed, then the pods will get scheduled on the new nodes (I think?), and the cluster will have a perpetually missing broker until it's manually force-decommissioned.
Presumably EKS and AKS have similar functionality.
JIRA Link: K8S-212
The text was updated successfully, but these errors were encountered: