I'm in the process of modernizing our deployment to use containers and kubernetes to deploy a complex microservices application.  The current deployment uses python scripts to place things where they need to go, and while it works, that deployment model doesn't deliver on some promises we made.

We have around 30 different services we need to deploy, most of which are Spring Boot based.  The bottom line is that the deployment for individual services should be reasonably the same.  The availability check would use the Spring Actuator health endpoint, and the only a few things need to be distinct (such as service port, ingress path, resource limits, and things of that nature).

My goal was to have a very small deployment of three microservices (discovery, config, and one of the simpler non-database services).  There's some things that I like:

• Templating makes it easier to customize deployments
  
• The default template is a good 80% solution, which I was able to make some needed customizations
  
• It wasn't hard to figure out how to make starters for my project
  
• I can collocate the chart definition with my service source code
  

That said, there are a lot of rough edges:

• You can't avoid the templating language if you customize your deployment, and if go-lang isn't something you do in your shop, it can be challenging to do otherwise simple things.
  
• The templates themselves are part of the chart.  That means if I convert 15 out of 30 services to Helm, and discover something I need to fix in the generated templates, I have to change my starter and 15 services to provide that piece.
  
• Helm does not have transitive package resolution, like most package management software I am used to using (Maven, Nuget, etc.)
  

I'm hoping I am missing something, or that there are already plans to address these rough edges.  The biggest problem is the transitive package resolution.  My helm charts look like this:

• logging-configmap
  
• system-configmap
  
• eureka
  
• logging-configmap
  
• config-server
  
• eureka
  
• system-configmap
  
• simple-service
  
• eureka
  
• config-server
  

The remainder of my ~30 services will be like simple-service.  In order for a successful deployment of that to happen I need the two other dependent services.  However each of those declare a copy of their dependencies, and so on.  When I run the command "helm dependency build" I will have the sub-charts loaded.

Problem is when the kubernetes template is actually rendered I have a new instance of the logging-configmap for each service, etc.  I need to be able to build and deploy my services in isolation as well as part of the whole for testing purposes.

At any rate, I would like to help make helm better.  I do have time constraints, and I'm not very familiar with go-lang.  I think this is a good start in a mostly correct direction.  It just needs to address those rough edges.

--

Berin Loritsch

Systems Integration Lead

7921 Jones Branch Drive
McLean, VA 22102
Email bloritsch@...

Office (703) 735-6281

Mobile (571) 215-7708