Helm: direct support for blue / green deployment pattern in helm
The blue / green deployment pattern as described at http://container-solutions.com/kubernetes-deployment-strategies is not supported natively in kubernetes or helm. If it belonged anywhere, would it be helm or kubernetes? Would the helm maintainers potentially accept a blue/green pull request?
burnettk
All 3 comments
This actually happens to be something service meshes handle really well. I highly suggest taking a look at tools like istio if you require the need to perform blue/green deployments for your application as they are able to handle gradual roll-ins and roll-outs because they control the flow of traffic coming into your application.
Helm works more in the sense of a traditional package manager, upgrading charts from one version to the next in a graceful manner (thanks to pod liveness/readiness probes and deployment update strategies), much like how one expects something like apt upgrade to work. Blue/green deployments are a very different beast compared to the package manager style of upgrade workflows; blue/green sits at a level higher in the toolchain because the use cases around these deployments require step-in/step-out policies, gradual traffic migrations and rollbacks. Because of that, we decided that blue/green deployments are something out of scope for Helm, though a tool that utilizes Helm under the covers (or something parallel like istio) could more than likely be able to handle that use case.
For more context, see the discussion in these threads/blog posts:
- https://github.com/kubernetes/kubernetes/issues/33462
- http://dougbtv.com/nfvpe/2017/06/05/istio-deploy/
Hope this helps!
bacongobbler
on 16 Feb 2018
Closing as answered but please re-open if there are further questions about b/g deployments. Thanks!
bacongobbler
on 20 Feb 2018
@bacongobbler I understand where you are coming from, but I think that istio is the low level way of implementing what we would like. What I mean to say is that (at least to me) I describe my entire server deployment with helm charts. If I change a chart from one version to the next, its helm that reads the helm files and deploys all the changes. Now, it does this by interfacing with lower level components described in the chart, but nonetheless I'm not running kubectl or other commands myself directly to change things. Furthermore, I think it would be incorrect to do so because it means that the state of the world isnt within the realm of any one tool which will lead to errors when these tools dont work together. Or am I missing something?
ofersadgat
on 9 Apr 2018
Related issues
vdice
·
3Comments
tjquinno
·
3Comments
sgoings
·
3Comments
danielcb
·
3Comments
dkirrane
·
3Comments
Most helpful comment
@bacongobbler I understand where you are coming from, but I think that istio is the low level way of implementing what we would like. What I mean to say is that (at least to me) I describe my entire server deployment with helm charts. If I change a chart from one version to the next, its helm that reads the helm files and deploys all the changes. Now, it does this by interfacing with lower level components described in the chart, but nonetheless I'm not running kubectl or other commands myself directly to change things. Furthermore, I think it would be incorrect to do so because it means that the state of the world isnt within the realm of any one tool which will lead to errors when these tools dont work together. Or am I missing something?