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
I believe that Argo Rollouts does not play well with long lived connections like websockets. I don't believe it's Argo Rollouts fault, but just due to the nature of using label selectors with Kubernetes Services. I want to make sure I'm not missing something, but I believe that as soon as a Rollout promotes that canary to stable, and the Service endpoints change, existing connections are immediately terminated. If Rollouts does not have a way around this (even if it requires something like Istio), then I believe it should at least be documented that websockets will not be gracefully drained.
To Reproduce
Establish a websocket to your pod
Begin a rollout and promote full
Once the promotion completes, the websocket will be killed PRIOR to the previous release pods being terminated.
Expected behavior
Expectation: Although any NEW connections should be sent to the new release, existing connections should persist and terminated gracefully as the pod enters a terminating state.
Outcome: my existing connection is terminated when the pod I'm connecting to is removed from the endpoint
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:
Describe the bug
I believe that Argo Rollouts does not play well with long lived connections like websockets. I don't believe it's Argo Rollouts fault, but just due to the nature of using label selectors with Kubernetes Services. I want to make sure I'm not missing something, but I believe that as soon as a Rollout promotes that canary to stable, and the Service endpoints change, existing connections are immediately terminated. If Rollouts does not have a way around this (even if it requires something like Istio), then I believe it should at least be documented that websockets will not be gracefully drained.
To Reproduce
Expected behavior
Expectation: Although any NEW connections should be sent to the new release, existing connections should persist and terminated gracefully as the pod enters a terminating state.
Outcome: my existing connection is terminated when the pod I'm connecting to is removed from the endpoint
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: