Support native blue/green deployments

[F21]

It would be really cool if kubernetes can have blue/green deployments built-in in addition to the rolling updates currently available.

This would allow for the ability to atomically update an app without the risk of clients connecting to the app seeing different versions.

[adohe-zz]

@F21 would you mind give a more deep explanation? how would you expect this?

[F21]

Let's say we have an app deployed as version 1. If we ask kubernetes to perform a rolling update to version 2, my understanding is that v2 would be able to serve traffic before all of v1 is removed. That means that we will have a small window where v1 and v2 are both serving traffic.

With blue/green deployments, let's say we initially deployed v1 (blue). We then ask kubernetes to deploy v2 (green). However, v2 does not serve any traffic yet and kubernetes does not perform a rolling update. Instead, it leaves v1 alone and lets it continue serving, and deploys all instances of v2. It then uses health checks to check if all of v2 is healthy, and when it is ready, it cuts over all traffic to v2. At this point, it then deletes all instances of v1.

[luxas]

That would be a nice feature indeed. cc @kubernetes/deployment

[0xmichalis]

It would be easier to add another strategy natively once we have custom strategies and people cannot come up with custom BG easily on their own. #14510

[Haybu]

@Kargakis does this suggest that BG is a strategy now is supported ? or it is still underway feature ?

[0xmichalis]

@Haybu no, BG is not supported natively and I am not sure this is going to happen anytime soon if at all in the core. We have a couple of issues for implementing custom strategies: #39337 #14510
You can also join Monday meetings of sig-apps if you want to discuss this.

[woopstar]

For inspiration, we started to build our own BG deployment setup which is integrated into our bamboo deployment process.

Feel free to have a look at https://github.com/pasientskyhosting/kubernetes-blue-green-deploy

Please be aware this is still in beta.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

[bgrant0607]

This is the domain of higher-level deployment pipelines and service meshes. It's not a deployment strategy that can be implemented in our workload APIs alone.

We're aware of the use case, but I'm going to close this as being out of scope here.