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
Support Dynamic Stable Scale without Traffic Routing.
Use Cases
We would like to rollout our Kafka consumer application with Argo Rollout using the canary deployment stategy. The number of replicas must be equal to the number of Kafka partitions. Means, stable replicas + canary replicas must not exceed spec.replicas, and spec.replicas is equal to the number of Kafka partitions.
The behaviour could be achieved by setting maxSurge: 0 (as pointed out in #1707). The problem is that a stable replica always has to be scaled down before a canary replica can be started. To minimize the time until the canary pod takes over, it would be better to start a canary replica first and then scale down a stable replica. Afterwards the consumers are rebalanced (assignment strategy CooperativeStickyAssignor) and the canary replica can take over immediately. With Kubernetes Deployment we ensure this rollout behavior via maxUnavailable: 0 and maxSurge: 100%.
Due to our architecture we can not use traffic routing. Routing is done implicitly by the partitions and the respective consumers pods. We need to scale down a stable replica so that the canary replica can take over. The feature Dynamic Stable Scale seems to be an option to solve my problem. But this feature is only available with traffic routing.
I'm an Argo Rollout newbie. Please let me know if there is already a solution to my problem.
Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritize the issues with the most 👍.
The text was updated successfully, but these errors were encountered:
Summary
Support Dynamic Stable Scale without Traffic Routing.
Use Cases
We would like to rollout our Kafka consumer application with Argo Rollout using the canary deployment stategy. The number of replicas must be equal to the number of Kafka partitions. Means,
stable replicas
+canary replicas
must not exceedspec.replicas
, andspec.replicas
is equal to the number of Kafka partitions.The behaviour could be achieved by setting
maxSurge: 0
(as pointed out in #1707). The problem is that a stable replica always has to be scaled down before a canary replica can be started. To minimize the time until the canary pod takes over, it would be better to start a canary replica first and then scale down a stable replica. Afterwards the consumers are rebalanced (assignment strategy CooperativeStickyAssignor) and the canary replica can take over immediately. With Kubernetes Deployment we ensure this rollout behavior viamaxUnavailable: 0
andmaxSurge: 100%
.Due to our architecture we can not use traffic routing. Routing is done implicitly by the partitions and the respective consumers pods. We need to scale down a stable replica so that the canary replica can take over. The feature Dynamic Stable Scale seems to be an option to solve my problem. But this feature is only available with traffic routing.
I'm an Argo Rollout newbie. Please let me know if there is already a solution to my problem.
Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritize the issues with the most 👍.
The text was updated successfully, but these errors were encountered: