Rainbow Deployments with Kubernetes

Re:Rainbow Deployments with Kubernetes by andrewaylett on Wednesday February 14, 2018 @01:47PM (#16378165)

It feels like it should be possible to fix the reconnect experience, especially in the planned termination of underlying container case: if you ask the client to reconnect, rather than abruptly disconnecting them then they could possibly even wait until their new session was fully established before dropping the old one.

That doesn't take away from my appreciation of the pattern, though: I'm very much in favour of rolling releases forwards, rather than being limited to two colours.

[ Parent | on HN ]

Re:Rainbow Deployments with Kubernetes by bdimcheff on Wednesday February 14, 2018 @02:28PM (#16378559)

We actually have this functionality as well: we can send a signal to the process which will cause it to display a message to the user asking them to reload to upgrade. There is a similar feature in slack and riot that I've seen as well.

Making this handoff automatic is definitely possible as well, though we do want people to reload occasionally to get new client-side code.

[ Parent | on HN ]

Re:Rainbow Deployments with Kubernetes by specialist on Thursday February 15, 2018 @08:10AM (#16383679)

I worked on an autobahn like thingie. Server-side could tell clients to reconnect. Useful for draining servers, etc.

I haven't checked to see if autobahn has this functionality.

https://crossbar.io/autobahn/

[ Parent | on HN ]

Re:Rainbow Deployments with Kubernetes by pronoiac on Wednesday February 14, 2018 @02:37PM (#16378654)

I agree. I can think of reasons for urgent updates - kernel security, software bugs, etc. - and this feels like it would lead their engineers to possibly support weeks-old versions of their systems. And they're running a multiple of the needed servers.

[ Parent | on HN ]