How do you manage Helm deployments for many microservices without duplicating charts?

0
0
Asked By MellowPine_47 On

We run multiple microservices on Kubernetes. Our CI/CD pipeline builds and pushes a Docker image, updates the image tag in a values file, and then GitOps tooling detects the change and deploys it. Right now, each service has its own Helm chart and repeated templates. What patterns work well for managing this at scale? Is it better to create one shared chart with separate values files for each service, or should each service keep its own chart? Would Kustomize help reduce duplication, and how do others structure deployments for large numbers of similar services?

4 Answers

Answered By QuietMaple6 On

You can also keep separate application charts while sharing a common library or subchart. Put the reusable templates and defaults in the library chart, then let each service chart provide only its values and any genuinely custom resources. Conditions in the values file can enable optional features without duplicating the core templates.

Answered By SilverOtter_52 On

Avoid forcing every service into one giant chart if their deployment requirements will eventually diverge. A large chart full of conditionals can become harder to maintain than a little duplication. It is also useful to publish shared charts to a chart repository and have services update their chart dependencies through automated pull requests, so changes are reviewed rather than copied manually.

Answered By BrightWalrus_31 On

Another option is to create a generic base chart containing the capabilities most teams need, such as deployments, services, ingress, probes, and resource settings. Each application then supplies its own values. This gives teams a consistent deployment model without copying the templates everywhere.

Answered By CloudyRaccoon8 On

If the services are deployed in mostly the same way, a shared chart with per-service values is a common approach. The templates can iterate over a collection of services, while the values define names, ports, images, replicas, and other differences. This works especially well when a single application release is meant to contain several related services.

Related Questions

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.