1

This is a follow up question to my post Parameterized Kubernetes manifest files?.

I understand more about Helm now, after lots of reading, including the Learn Helm book (which I recommend). I still have this understanding that each microservice will have its OWN Helm chart? This defeats the purpose of what I wanted, where I just have ONE helm chart, and every time I want to use it, I just update the Chart.yml and values.yml files for each microservice, everything else is the same. For example, the microservice name, versions, and repo will change of course per microservice. Seems like I'm looking for a "template" for Chart.yaml and values.yaml. Is this possible to do? I don't know if it's recommended or not (I may not care).

I come from a CloudFoormation background, where I just have ONE parameterized CloudFormation template, and I just pass it parameters pertinent to each microservice.

UPDATE: I'm aware of Helm library charts, and I don't think they can provide the functionality I want?

4
  • What problem are you trying to solve? Are there too many lines of yaml? You can do as do describe, but it is not a good practice. – Jonas Feb 17 at 20:18
  • Hi again @Jonas. ALL my microservices (will) use the SAME set of charts. They will literally only differ in name, version, ingress path. If I had one Helm chart per microservice, which I think is the recommended way to do it, I will just literally copy/paste the chart files from one microservice to the other, all templates files will be the SAME, and I'll make changes in Chart.yaml (name, version, etc.) and values.yaml (image, ingress, etc.). So if I update a templates file in one, I'll have to do it in all. What's the point of doing all this? – Chris F Feb 17 at 20:46
  • It sounds like all applications is managed centrally in your org? Usually, different teams manage their own apps. – Jonas Feb 17 at 21:09
  • Yeah, I manage ALL of them, or at least their deployments. LOL. – Chris F Feb 17 at 21:10
2

Generally, a Helm chart would cover all your microservices - ideally, you should be able to deploy whole application in one chart. It may get a little messy if you include external 3rd party dependencies, where you would need to handle dependent charts, but I assume this is out of scope of your question.

More so, if your microservices are very similar you could write for loops, such as:

{{- range $index, $service := .Values.myservices}}
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-{{ $service.name }}
# --- etc ---
{{- end }}

Now, where to put your chart - in most cases a preferred way is to have a separate repo for all Ops CD files, including Helm chart - so this is where Helm chart would live. This is not to be mixed with CI files, such as Dockerfile - those should live alongside microservice repositories themselves.

1
  • Y, i'm leaning toward having my Helm charts in our separate Ops Git repo (we do this for ECS now). I'll explore this idea, thanks! – Chris F Feb 17 at 21:36
2

I believe what you're asking is: "Is there any way to create just one helm chart that can be used for all microservices in my application?". If so, then you can just use the values.yaml file to store all the values for your templates. This is not considered good practice, considering your template file needs to hold the information for each of your microservice deployments (and thus will become really difficult to manage), but it is possible.

One example: say you have two microservices, and you need one Helm chart that will create the template for both microservices. Generally, you would create separate templates for each service under the templates folder, and deploy each Helm chart for each service individually, but instead you could create multiple deployments in one template yaml file, like

# For service 1
apiVersion: apps/v1
type: Deployment
etc., etc... (stick in all values.yaml file values here for service 1)
---
# For service 2
apiVersion: apps/v1
type: Deployment
etc., etc... (stick in all values.yaml file values here for service 2)

In your values.yaml file, you would then just place in the values for each of your services, like

# Service 1 Keys/Values
foo: value
# Service 2 Keys/Values
bar: otherValue

So to answer your question, you can package all your services into one individual Helm chart using the above method, and Kubernetes will run each service as their own ReplicaSet as expected. However, when you have many services to manage, it can be tricky to manage the template YAML files and the values.yaml files when you put in values for all your services in one file, and so it's most likely not a good practice to do this.

This is just my understanding of Helm so far, as I'm still learning Helm myself. As such, I'm not 100% sure if this can be done, so you might want to double check with another person that this answer is actually correct.

EDIT: To summarize: like I mentioned above, in theory, it is possible to use one Helm chart per service. But in practice, it will be extremely messy later on to manage the values.yaml and the templates in the templates folder. So the answer would be, "Yes in theory, but not recommended at all".

7
  • yes, this is exactly what I want. But what will be the directory structure to accomplish this? Each microservice is in it's own Git repo. So where will be the "generic" Helm charts be? Where will the microservice-specific values.yaml files be? How do I consolidate the two directory files? Remember, I want to be able to do a helm install ... from some diretory that has the complete chart. – Chris F Feb 17 at 20:52
  • @ChrisF You would only need to put the regular Helm directory structure (Chart.yaml, values.yaml, and the templates folder) in one service. At that point, you would need to build your Docker images/push them to the registry first. Then, because K8s references only images stored in the registry, when you install your Helm chart using the files in just one microservice, K8s can pull the container image for all of your services and run it as expected. So when you run helm install from one service, it will work, as Kubernetes doesn't reference the directory, it references the container image. – Rohit Karthik Feb 17 at 21:07
  • I think this is a bad way to do it. – Chris F Feb 17 at 21:10
  • 1
    Yes, like I said earlier this isn't a good way to go about it all, it makes more sense to just package each service using Helm separately, as this method is extremely messy. But, this shows it's possible. This is not the best way to do it though. – Rohit Karthik Feb 17 at 21:11
  • My answer highlighted the way to do it, but if you want a much cleaner way to manage each service, you would need to create individual Chart.yaml, values.yaml, and a templates folder for each app. While it might be some additional work in the beginning (have to replicate the same thing across many services), it will be a huge timesaver later on. – Rohit Karthik Feb 17 at 21:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.