I have a vague feeling that this is fighting the framework… what is the usecase here? Do you often have very-long-lived websocket connections that need to be preserved over upgrades?
The “k8s way” here is to have your pods quiesce on rollout (old pods marked “unready” and removed from the Service), so existing connections are not torn down, but new connections get sent to the up-level pods. Then when all connections have drained from the down-level pods you terminate them. This would break down if you need to have say 1-hour websockets, but aren’t willing to wait 1h+ to roll out a new release. Is this a common requirement?
Interested to hear examples of cases where extremely long-lived connections are worth a lot of engineering pain to achieve.
The “k8s way” here is to have your pods quiesce on rollout (old pods marked “unready” and removed from the Service), so existing connections are not torn down, but new connections get sent to the up-level pods. Then when all connections have drained from the down-level pods you terminate them. This would break down if you need to have say 1-hour websockets, but aren’t willing to wait 1h+ to roll out a new release. Is this a common requirement?
Interested to hear examples of cases where extremely long-lived connections are worth a lot of engineering pain to achieve.