Blue-Green Deployment Tutorial

[thesandlord]

We don't have a Blue-Green Tutorial for Kubernetes. We only have rolling updates.

I have the steps for a Blue-Green deployment here: https://github.com/thesandlord/container-orchestration-comparisons/tree/master/blue-green-deployment

This needs to be put into Doc format.

[unixbhaskar]

Cool ! good catch that was missing. thanks

[pop]

@thesandlord Those docs look pretty good. Would you mind making a Pull Request to add them as a User Guide?

If you're too busy I'd be glad to can create something similar and propose it. I do think it'd be a useful document to have around in the upstream docs for people to quickly find.

[ipedrazas]

The doc is mostly correct, I've just added a few comments to it. I'm happy to do it if @thesandlord is too busy.

[robhaswell]

I think this example of a single-service application is too minimal to be useful to anyone. I think users would be more interested in best practices or potential approaches to namespacing service discovery between the two parallel deployments, and how to manage sticky subjects such as stateful services.

[plombardi89]

@robhaswell Disagree. I think both have their place. This information is still useful for people that are just starting. I don't think perfect should be the enemy of good. Of course if we could have both the simple case and the more advanced one that would be even better.

[isavcic]

Question: can this be done non-interactively, ie. without the "This will open the YAML in a text editor" part?

[timoreimann]

@isavcic It probably can using kubectl patch. I haven't verified it though.

[hridyeshpant]

Thanks @thesandlord for document.But i have one query?
how do we check deployment health check before Flip the traffic to "Green"
Deploy "Version 1" of an application as "Blue"
Ensure "Blue" is serving traffic
Deploy "Version 2" of an application as "Green"

now before Flip the traffic to "Green", there might be the case the deployment health check is failing due to some issue in application .
let say i have following health check defined and due to wrong commit, application is failing to launch.
livenessProbe:{
httpGet:{
path:'/buildInfo',
port: 8080
},
initialDelaySeconds:45,
timeoutSeconds:10
}

So i want to check if health check is passing for new version before Flip the traffic to "Green, other wise service will start pointing to failed version and will have downtime.

the main issue there is no way to get health check as soon as we do deployment. i tried to fetch pods status after the deployment, kubernetes is throwing error only after quite log time and during that time the result is aways showing "pods are running".
the only workaround is i need to put some wait time in our workflow and make sure all pods with new version running fine before Flip the traffic to "Green".

Do you have any other suggestion here?
Also is there official document about how to get Blue-Green Deployment.?

i am looking some suggestion, how to achieve below workflow:

• Deploy "Version 1" of an application as "Blue"
• Check health check for Version 1 deployment
• if health check pass Flip the traffic to "Blue" is serving traffic
• Deploy "Version 2" of an application as "Green"
• Ensure "Blue" is still serving traffic
• Check health check for Version 2 deployment
• if health check pass for Version 2 Flip the traffic to "Green" (no client side changes allowed)
• Ensure "Green" is serving traffic and "Blue" is idle
• Delete Version 1 deployment related resource (RC,PODS etc...)

[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

[Frodox]

Upd!

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close