0

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.

Improve this question
11
  • 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? Commented Feb 22, 2021 at 4:03
  • @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. Commented Feb 22, 2021 at 13:46
  • But i will indeed test the Helm process, where I install all my charts per release. Commented Feb 22, 2021 at 14:15
  • 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. Commented Feb 22, 2021 at 14:21
  • 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. Commented Feb 22, 2021 at 15:28

1 Answer 1

Reset to default
1

Yeah, this is what I had in mind all along. Blue/Green Deployments on 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.

Improve this answer
1
  • 1
    Ok I will elaborate my answer later. Commented Feb 24, 2021 at 15:58

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.