Helm Support for Harness Continuous Delivery

Harness recently made several major updates to our Helm support. Here's a quick recap of whats changed.

By Puneet Saraswat
May 2, 2019

Helm has become a widely popular way to package, distribute and manage Kubernetes Applications. At Harness, we see an increasing number of our customers are already using Helm and the usages are varied. In this post, we talk about how Harness provides first-class Continuous delivery solution for microservices/applications packaged as Helm Charts.

Canary and Blue/Green Deployments for Helm Charts

While Helm has been good for packaging multiple Kubernetes resources into Kubernetes Applications, it provides limited functionality with respect to deployment and rollback. Helm project does not aim to solve Continuous Delivery, and implementing advanced deployment strategies like Canary and Blue/Green are not straight forward. In many cases we see people using smart templating tricks to achieve them. This typically entails manual work to run helm CLI with different values files.

In the Harness platform, we have built first-class support for canary and blue/green deployment strategies. We also do a deployment status check and if needed, an automatic rollback. Our implementation is very flexible and any set of Kubernetes resources could be deployed as part of a service. With our Helm integration, we aimed to bring the same feature sets to the customers who already use Helm Charts today.

The following Figure illustrates the canary deployment strategy. A parallel canary deployment is created by Harness workflow. When the canary deployment passes all verifications, primary deployment is upgraded. Achieving this requires no change in specs.

Figure 1: Harness orchestrated Canary Deployment

Figure 2: Example run of Canary Workflow

Figure 2: Example run of Canary Workflow

Similarly, the following figure illustrates Blue/Green strategy. Harness workflow creates two parallel deployments [aka Blue and Green slots]. A service object [i.e. primary service] is used to track which of the deployment serves production traffic. New service is deployed into another slot. Once all the tests pass, production traffic can be routed to new Pods by updating the Service. At any time the Service can be updated to point to an older version to achieve instant rollback.

Figure 3: Harness Orchestrated Blue/Green Deployment

Figure 3: Harness Orchestrated Blue/Green Deployment

In our approach, we use Helm to fetch chart from repository and template rendering. Once we have rendered Helm chart into Kubernetes Resources – we can orchestrate a canary or blue-green deployment like described above and do automated rollback in case of failures. All this requires no change in the chart spec of microservice.

Deploying Services across Environments using Helm

With Helm templating, it’s easy to have a chart deployed to multiple environments. The environment-specific configuration is kept in values override files. Still, there is a need to manage environment specific secrets and cluster configuration, e.g.. Kubeconfig. Keeping track of what overrides go to what cluster becomes intractable as you scale to more environments.

Harness provides an environment abstraction where all of the above can be organized in Environment resource. When Services are deployed to a particular environment – the right cluster is targeted with the right configuration and values overrides.

Figure 4: Harness environment encapsulates Cluster details and configuration specific to an environment

Figure 4: Harness environment encapsulates Cluster details and configuration specific to an environment

Automated Rollback of Helm deployments

Helm install/upgrade commands do not track the status of deployment rollout. After the helm upgrade is complete, there is still a need a manual tracking status of the rollout. Rolling back is also a manual operation. Harness tracks rollout status of the deployment and can auto-rollback if needed.

Other Helm Enhancements

Some customers maintain their Helm charts in git repositories but find it a hassle to maintain a separate Helm repository. Many people use Amazon S3 and GCS buckets to store chart packages.

Many use Helm just for packaging and templating while others leverage Helm client to manage install/upgrade/rollback of releases. We heard from a few customers about the challenges they run into with tiller and prefer to use client-only mode.

Based on these learnings we have improved the following aspects of our Helm integration:

Helm Repository Connectors

We have added a connector for Helm Repository. HTTP server, Amazon S3, and Google Cloud Storage based repositories are supported out of the box.

helm_5

Helm Charts from Source Repository

Helm charts can be directly fetched from chart source in a git repository. This avoids the overhead of maintaining a separate Helm repository server.

helm_6

Remote Values Overrides

Values override at service and environment level can now be stored in remote git repositories. This enables GitOps flow and environment level overrides can be kept in the same repository as charts.

Support of Client-Only Helm Usage

We have added support for client-only mode of Helm. Client only mode is preferred by many as tiller creates challenges with setup, RBAC, and availability. In this mode, Helm client is used to fetch charts from the repository and render a template. Deployment is done through the standard kubectl mechanism. This avoids dependency on the tiller.

We hope you find these enhancements useful.

Regards,

Anshul, Vaibhav, Ishant, Venkatesh & Puneet

 

 

➞ Back to Blog

Leave a Reply

avatar
  Subscribe  
Notify of