Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2021-02-24T15:58:45.740Z
Answers: Ok I will elaborate my answer later.
Answers: Chris F
Answers: CC BY-SA 4.0
Answers: 2021-02-24T01:51:01.927Z
Answers: 2021-02-24T16:12:41.187Z
Answers: 2021-02-24T16:12:41.187Z
Answers: Chris F
Body: <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>
  
Comments: CC BY-SA 4.0
Comments: 2021-02-22T04:03:29.463Z
Comments: 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?
Comments: taleodor
Comments: CC BY-SA 4.0
Comments: 2021-02-22T13:46:49.977Z
Comments: @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.
Comments: Chris F
Comments: CC BY-SA 4.0
Comments: 2021-02-22T14:15:29.467Z
Comments: But i will indeed test the Helm process, where I install all my charts per release.
Comments: Chris F
Comments: CC BY-SA 4.0
Comments: 2021-02-22T14:21:57.357Z
Comments: 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.
Comments: Chris F
Comments: CC BY-SA 4.0
Comments: 2021-02-22T15:28:46.017Z
Comments: 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.
Comments: taleodor
Comments: CC BY-SA 4.0
Comments: 2021-02-24T01:11:15.107Z
Comments: @taleodor I’ll explode the blue/green idea indeed, thanks.
Comments: Chris F
Comments: CC BY-SA 4.0
Comments: 2021-02-24T01:44:00.940Z
Comments: @taleodor, this is exactly what I had in mind all along. https://www.ianlewis.org/en/bluegreen-deployments-kubernetes
Comments: Chris F
Comments: CC BY-SA 4.0
Comments: 2021-02-24T03:33:47.223Z
Comments: 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.
Comments: taleodor
Comments: CC BY-SA 4.0
Comments: 2021-02-24T16:05:21.613Z
Comments: @taleodor, as an former colleague said a long time ago, "it's just software, anything can be done in software." More true than not.
Comments: Chris F
Comments: CC BY-SA 4.0
Comments: 2021-02-24T17:22:18.197Z
Comments: 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.
Comments: taleodor
Comments: CC BY-SA 4.0
Comments: 2021-02-24T19:07:38.207Z
Comments: @taleodor, that's very true, parameterize `templates/service.yaml` also
Comments: Chris F
Tags: <helm><kubernetes-helm>
Title: Is Helm not for me?
UserDisplayName: Chris F
ThreadText: # 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.  
  
  ---
  
  