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.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
- Build and push Docker images (we currently do this, and won't change)
- Deploy new containers (pods) via Deployment using
kubectl apply -f deployment.yaml
- Wait for the deployments to finish
- Update the
Serviceto 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.