Dealing with Helm Charts of micro-services with interdependent API end points

Tiller: “Sigh! I am going 😢, goodbye folks!”.

Me: “Oh no, please don’t go, you have caused me so much pain in last years, I started loving you 😜!”

If you are wondering about the above sweet conversation and thinking what is Tiller, why it’s gone and am I sad or happy as it’s gone? please pause reading and go through Helm document first. In this article I am not going over Helm and it’s concepts, it is nicely documented and there are so many blogs around it.

What I am going to elaborate here is the concept of Helm Subcharts and see how it can solve a problem that we encounter very frequently in the micro-services world.

Background:

Let’s have a look to one of the typical micro-services deployment architecture in Kubernetes, that is deployed in Azure using Azure Kubernetes Service (AKS) and several other Azure Services like Storage, Key Vault, etc.

Sample Retail Micro-Services Deployment Architecture that enables E-Commerce Solution

Where the inter-dependencies between micro-services (Portal, Product Catalog, Customer Management, Order Management, Order History and Payment Solution)highlighted in Green color lines. Except Portal (User Interface) all other micro-services are REST API’s and exposed as -

1. Portal: https://my-e-commerce-domain.in Accessible from external world by browser
2. Product Catalog: https://<helm-release-name>-product-catalog/api Accessible only inside AKS as a Kubernetes Service
3. Customer Management: https://<helm-release-name>-customer-management/api Accessible only inside AKS as a Kubernetes Service
4. Order Management: https://<helm-release-name>-order-management/api Accessible only inside AKS as a Kubernetes Service
5. Order History: https://<helm-release-name>-order-history/api Accessible only inside AKS as a Kubernetes Service
6. Payment Solution: https://<helm-release-name>-payment-solution/api Accessible only inside AKS as a Kubernetes Service

The micro-services are having independent deployment life-cycles and having different Helm Charts. Where API endpoints are configured as environment variables. For example when Portal is trying to access Order Management it will read REST API endpoint URL from environment variable ORDER_MANAGEMENT_API_ENDPOINT

Problem Statement:

Let’s see how the deployment is done and what problem we may face.

As a standard practice each deploy able change will go through several automated tests (sanity/regression/performance/etc.) in completely isolated environments. For every types of tests there are respective CI/CD pipelines.

Also sometime to re-produce customer Bugs, we might need to create an isolated environment manually from certain release (this we don’t foresee at the beginning of the project, however as project progresses we do see the need of it).

And <helm-release-name> may vary from environment to environment, for example it might be alpha, beta, pre-prod, etc. Hence all the respective micro-services API endpoint URL’s will change, for example the value of ORDER_MANAGEMENT_API_ENDPOINT will be https://alpha-order-management/api

Now the problem is if we start hard-coding this <helm-release-name> for all API endpoint URL environment variables, the respective CI/CD pipelines become bulky and create maintenance overhead and become a pain as micro-services ecosystem grows over time. And for manual deployment it becomes a nightmare to configure each dependency separately.

NOTE: This above story is not the only scenario where we are having inter-dependencies, there are several scenarios where the similar problem might appear.

Possible Solution:

Helm Subcharts is one of the possible solution, we will see how we can solve the problem now by going through the following steps -

1. Create a parent Helm Chart named my-e-commerce-solution and move all of the micro-services Helm Charts as Subcharts into charts folder

Directory structure of the Helm Parent and Subcharts

2. Create file Chart.yaml and add all the Subcharts path, version and condition to enable/disable

3. Create file Values.yaml and define all the global variables and option to enable/disable the Subcharts

4. So far we have seen the usual stuffs mostly we do with Helm Subcharts. Now comes the interesting part where we will define the micro-service API endpoints as Helm variables in a file templates/_helpers.tpl. This makes <helm-release-name> dynamic for all micro-services API endpoints

File — my-e-commerce-solution/templates/_helpers.tpl

5. Now for using the defined API endpoints in each inter-dependent micro-service first we need to declare the required variables in respective Helm Chart in file templates/_helpers.tpl, so that the respective Subcharts are aware about the incoming variables from Parent Helm Chart

Left my-e-commerce-solution/charts/portal/templates/_helpers.tpl, Right my-e-commerce-solution/charts/order-management/templates/_helpers.tpl

6. As a second step for using defined API endpoints, we need to modify the respective values.yaml & deployment.yaml to use the defined variable and defaults to Charts local variable, so that we don’t break the individual Helm Chart and still they can be deployed separately (from respective micro-service individual CI/CD pipeline)

Ex. my-e-commerce-solution/charts/order-management/values.yaml similar will be for Portal as well

Ex. my-e-commerce-solution/charts/order-management/templates/deployment.yaml similar will be for Portal as well

7. Now it’s time for a demo, where we will see how we can deploy the parent Helm Chart by resolving all inter-dependencies and as well as we can deploy a single Helm Chart separately

Demo of the Parent Helm Chart and Subchart

All of these above mentioned samples are present in GitHub Repository — prabdeb/sample-helm-parent-chart

Conclusion:

Now as you have read so far I can assume that you started realizing the power of Helm Subcharts.

In the above sections we have seen one sample retail micro-services ecosystem with inter-dependencies and observed how Helm Subcharts can ease the deployment and adds flexibility around. But I am sure this is very common in any micro-services ecosystem and might have more complexity and I strongly believe that Helm Subcharts can solve those problem as well!

Being aware about Kustomize (an alternate to Helm) and after using it as well, I still feel Helm can do lots of magic around Kubernetes deployment/packaging.