<p>Yeah, this is what I had in mind all along. <a href="https://www.ianlewis.org/en/bluegreen-deployments-kubernetes" rel="nofollow noreferrer">Blue/Green Deployments on Kubernetes</a>. So in short, Helm as it stands, is <strong>not</strong> for me since it doesn't have the concept of a blue/green deployment. With Helm, when you install a new package, the Deployment gets updated with the new Pod versions, but the Service is still pointing to the Deployment. Helm doesn't have the concept of having 2 Deployments, a blue and a green, and doesn't have the concept of switching between the two. Kubernetes itself supports this though.</p>
<p>Now maybe Helm can work if you create your Helm charts <strong>without</strong> the Service, and run a script to update the Service to switch to the new Deployment later in your installation process.</p>

CC BY-SA 4.0
2021-02-24T15:58:45.740Z
Ok I will elaborate my answer later.
Chris F
CC BY-SA 4.0
2021-02-24T01:51:01.927Z
2021-02-24T16:12:41.187Z
2021-02-24T16:12:41.187Z
Chris F
<p>I've been studying Kubernetes and Helm lately (I'm new to both) and figuring out how I can fit them into my companies CI/CD process. On top of this, I want to adapt to the GitOps process, where you check out and release an environment. I firmly believe in fitting to tools to the process, instead of the other way around.</p>
<p>Because of this I'm beginning to think that Helm may not be for us? Let me explain.</p>
<p>In GitOps, you check out a whole environment, correct? You say, I want to checkout <code>rc-2.1.0</code> (release candidate) for example, and it will define ALL the microservices needed for that version. So if we had 20 microservices, only 3/20 may have changed between <code>rc-2.0.0</code> and <code>rc-2.1.0</code> but you still deploy all 20 of them. With Kubernetes, 17/20 will be a no-op since nothing's changed, and only the changed 3/20 will actually be updated. This way we can later go back to <code>rc-2.0.0</code> if need be for any reason, and get the 20 microservices defined in that version.</p>
<p>But I want to decouple the activity of deploying new versions, which takes time, to the actual action of &quot;switching&quot; to the new versions. The deployment is done with Deployments, while the action can be done by updating a Service's label correct? So I want to do the following</p>
<ol>
<li>Build and push Docker images (we currently do this, and won't change)</li>
<li>Deploy new containers (pods) via Deployment using <code>kubectl apply -f deployment.yaml</code></li>
<li>Wait for the deployments to finish</li>
<li>Update the <code>Service</code> to point to the new Deployment, which is instantaneous</li>
</ol>
<p>Since a Helm chart deploys a whole package, it contains both Service and Deployment templates, I can't really &quot;decouple&quot; steps 2-3 with step 4 above?</p>
<p>So is Helm indeed not for me? If I'm completely off-base in my understanding of Helm, how can I accomplish this process using the tool?</p>
<p><strong>NOTE:</strong> I know I can accomplish rollouts and rollbacks via Deployments, but again, if I understand correctly, this takes time.</p>

CC BY-SA 4.0
2021-02-22T04:03:29.463Z
There may be some misconception, since deployment has replica sets underneath and usually deployments are updated in place. Could you describe what is your concern here? Do you want to achieve some sort of canary deployment scenario or are you simply worried that a service may be switched to a new deployment before it's ready?
taleodor
CC BY-SA 4.0
2021-02-22T13:46:49.977Z
@taleodor, just speed and readiness of new deployment. With Helm, my Service, which never changes, is talking to the Deployment as it's being deployed, so it may take a while for the Service to finally be talking to the new deployment. My process is to do the Deployments first, with different labels, then when the new Deployments are up, match the Service to the new labels.
Chris F
CC BY-SA 4.0
2021-02-22T14:15:29.467Z
But i will indeed test the Helm process, where I install all my charts per release.
Chris F
CC BY-SA 4.0
2021-02-22T14:21:57.357Z
But yes @taleodor, a canary deployment will be one scenario that I would want to implement. I may not want "everyone" to be switched to the new deployment until it's ready. I realize Deployments have ReplicaSets under them.
Chris F
CC BY-SA 4.0
2021-02-22T15:28:46.017Z
I see, so generally if you have properly configured startup, liveness and readiness probes, then it's safe to update deployment in place - because deployment will take care of underlying replica sets and make sure pods are available. I agree, canary deployment is the real scenario where this is not enough - it's best achieved with service meshes and can be trickier to implement - tooling is not perfect there. One alternative is blue-green deployment where you can switch say between namespaces.
taleodor
CC BY-SA 4.0
2021-02-24T01:11:15.107Z
@taleodor I’ll explode the blue/green idea indeed, thanks.
Chris F
CC BY-SA 4.0
2021-02-24T01:44:00.940Z
@taleodor, this is exactly what I had in mind all along. https://www.ianlewis.org/en/bluegreen-deployments-kubernetes
Chris F
CC BY-SA 4.0
2021-02-24T03:33:47.223Z
Yes, this is a workable concept but currently automating such strategy on a scale is problematic. I'm not aware of any tooling that supports this well at the moment. Say for us - it's on our road-map. Also depends for how many microservices you need this, if it's just a few - would be easier to organize.
taleodor
CC BY-SA 4.0
2021-02-24T16:05:21.613Z
@taleodor, as an former colleague said a long time ago, "it's just software, anything can be done in software." More true than not.
Chris F
CC BY-SA 4.0
2021-02-24T17:22:18.197Z
Lol :) + Actually, you can parametrize helm chart in a way to achieve described functionality and then automate - for this you don't have to keep your service outside, you may use some if conditions and then just update values file to support blue/green model. Key issue is that all this requires several manual steps in most cases at the moment.
taleodor
CC BY-SA 4.0
2021-02-24T19:07:38.207Z
@taleodor, that's very true, parameterize `templates/service.yaml` also
Chris F
<helm><kubernetes-helm>
Is Helm not for me?
Chris F
# Is Helm not for me?

(Asked by: username_0 on 2021-02-22)

I've been studying Kubernetes and Helm lately (I'm new to both) and figuring out how I can fit them into my companies CI/CD process. On top of this, I want to adapt to the GitOps process, where you check out and release an environment. I firmly believe in fitting to tools to the process, instead of the other way around.

Because of this I'm beginning to think that Helm may not be for us? Let me explain.

In GitOps, you check out a whole environment, correct? You say, I want to checkout `rc-2.1.0` (release candidate) for example, and it will define ALL the microservices needed for that version. So if we had 20 microservices, only 3/20 may have changed between `rc-2.0.0` and `rc-2.1.0` but you still deploy all 20 of them. With Kubernetes, 17/20 will be a no-op since nothing's changed, and only the changed 3/20 will actually be updated. This way we can later go back to `rc-2.0.0` if need be for any reason, and get the 20 microservices defined in that version.

But I want to decouple the activity of deploying new versions, which takes time, to the actual action of "switching" to the new versions. The deployment is done with Deployments, while the action can be done by updating a Service's label correct? So I want to do the following

1. Build and push Docker images (we currently do this, and won't change)
2. Deploy new containers (pods) via Deployment using `kubectl apply -f deployment.yaml`
3. Wait for the deployments to finish
4. Update the `Service` to point to the new Deployment, which is instantaneous

Since a Helm chart deploys a whole package, it contains both Service and Deployment templates, I can't really "decouple" steps 2-3 with step 4 above?

So is Helm indeed not for me? If I'm completely off-base in my understanding of Helm, how can I accomplish this process using the tool?

**NOTE:** I know I can accomplish rollouts and rollbacks via Deployments, but again, if I understand correctly, this takes time.

**Tags:** helm, kubernetes-helm

> **Comments:**
> **username_1**: There may be some misconception, since deployment has replica sets underneath and usually deployments are updated in place. Could you describe what is your concern here? Do you want to achieve some sort of canary deployment scenario or are you simply worried that a service may be switched to a new deployment before it's ready?  
> **username_0**: @username_1, just speed and readiness of new deployment. With Helm, my Service, which never changes, is talking to the Deployment as it's being deployed, so it may take a while for the Service to finally be talking to the new deployment. My process is to do the Deployments first, with different labels, then when the new Deployments are up, match the Service to the new labels.  
> **username_0**: But i will indeed test the Helm process, where I install all my charts per release.  
> **username_0**: But yes @username_1, a canary deployment will be one scenario that I would want to implement. I may not want "everyone" to be switched to the new deployment until it's ready. I realize Deployments have ReplicaSets under them.  
> **username_1**: I see, so generally if you have properly configured startup, liveness and readiness probes, then it's safe to update deployment in place - because deployment will take care of underlying replica sets and make sure pods are available. I agree, canary deployment is the real scenario where this is not enough - it's best achieved with service meshes and can be trickier to implement - tooling is not perfect there. One alternative is blue-green deployment where you can switch say between namespaces.  
> **username_0**: @username_1 I’ll explode the blue/green idea indeed, thanks.  
> **username_0**: @username_1, this is exactly what I had in mind all along. https://www.ianlewis.org/en/bluegreen-deployments-kubernetes  
> **username_1**: Yes, this is a workable concept but currently automating such strategy on a scale is problematic. I'm not aware of any tooling that supports this well at the moment. Say for us - it's on our road-map. Also depends for how many microservices you need this, if it's just a few - would be easier to organize.  
> **username_0**: @username_1, as an former colleague said a long time ago, "it's just software, anything can be done in software." More true than not.  
> **username_1**: Lol :) + Actually, you can parametrize helm chart in a way to achieve described functionality and then automate - for this you don't have to keep your service outside, you may use some if conditions and then just update values file to support blue/green model. Key issue is that all this requires several manual steps in most cases at the moment.  
> **username_0**: @username_1, that's very true, parameterize `templates/service.yaml` also  

---

## 1 answers

### Answer by username_0 on 2021-02-24. Score: 1 | Accepted answer

Yeah, this is what I had in mind all along. [Blue/Green Deployments on Kubernetes](https://www.ianlewis.org/en/bluegreen-deployments-kubernetes). So in short, Helm as it stands, is **not** for me since it doesn't have the concept of a blue/green deployment. With Helm, when you install a new package, the Deployment gets updated with the new Pod versions, but the Service is still pointing to the Deployment. Helm doesn't have the concept of having 2 Deployments, a blue and a green, and doesn't have the concept of switching between the two. Kubernetes itself supports this though.

Now maybe Helm can work if you create your Helm charts **without** the Service, and run a script to update the Service to switch to the new Deployment later in your installation process.

> **Comments:**
> **username_0**: Ok I will elaborate my answer later.  

---

