Kubernetes has established itself as a de facto container orchestration platform for deploying cloud-native applications. Its growth shows no signs of stopping, as demonstrated by the fact that every major cloud has its own managed Kubernetes version (GKE, AKS, EKS). While it’s proved a critical tool for simplifying cloud-native continuous deployment, it has led to increased container management complexity, which can hold up delivery. However, it is possible to significantly reduce feature delivery lead time on Kubernetes by making the deployment mechanism robust, consistent, and re-usable. Digital engineers can use a variety of tools to deploy an application, its configuration, and Kubernetes specific objects, including Kubectl, Helm, Kustomize, Skaffold, and Draft. Today, we’ll be focusing on Helm, a valuable solution for managing Kubernetes apps.
Managing Kubernetes – Common Challenges
The Kubernetes native approach for deploying applications and other Kubernetes objects (persistent volumes, ConfigMaps, ingresses, network policy, etc.) involves writing YAML-based manifests. These manifests are unable to process/evaluate variables or parameters, which results in teams needing to write almost identical manifests for different clusters or environments. Needless to say, this goes against the DRY (Don’t Repeat Yourself) software design principle.
Furthermore, applications are continuously evolving due to business, executive and technical requirements. The result? Further changes in application configurations and other Kubernetes objects are required, leading to configuration management challenges that arise from binding a Kubernetes manifest with the application version. The knock-on effect of not being able to maintain versioning is that it introduces additional challenges, for instance, with rolling back an application in the event of deployment failure(s).
Additionally, modern applications and Kubernetes objects might be dependent on other applications and other Kubernetes objects, respectively, which then further increases deployment complexity as each component and manifest needs to be deployed exactly in that order.
The Solution: Helm
Helm is an official project of the Cloud Native Computing Foundation focused on packaging, sharing, and deploying cloud-native applications on Kubernetes. We are going to look closer at Helm V3 and how it can address the challenges around versioning, enable repeatable builds, and result in faster release cycles. Apexon has worked with multiple clients to slash their lead time for changes and increase deployment frequency of their cloud-native applications by leveraging Helm, CD platforms and advance deployment patterns like blue-green and canary deployments. This blog will look at the core components that make up the Helm solution and then examine why digital engineering teams should consider using Helm.
Helm’s Core Offering:
Helm uses a packaging format called charts which contains the file packaging application, its configurations and a set of Kubernetes objects. Charts provide:
Helm’s chart repository is an HTTP server that remotely hosts and stores the different charts. Its main functions are to:
As it is an HTTP server it can also be easily hosted on cloud with object storage (AWS S3, GCS, etc.) and also on-premise with webservers (HTTPD, Nginx).
Continuous Deployment with Helm
Before jumping into deployment with Helm, it is important to define your team’s Helm chart versioning strategy. Helm’s versioning scheme is semantic, and teams have two options when it comes to versioning. If a single application is released as part of a single Helm chart without any dependencies, then the most straightforward approach would be to use the same semantic version for the Helm chart as for the application. However, different semantic versions may be more suitable when multiple applications are released as part of a single Helm chart. This is a complex strategy to implement, but it provides version correlation and traceability between the Helm chart and applications deployed as part of the Helm chart. It requires team co-ordination on when to bump up the release version.
CD/CD best practices recommend using the same generated artifact and promoting it to a different environment. The two options for engineering teams to weigh up are whether to choose to promote charts across different environments using the same chart repository or different chart repositories.
If using the same chart repository across different environments, the Helm chart promotion strategy should involve the following steps for CI/CD:
It is a simple and easy approach to implement, but it requires guard rails to prevent the accidental promotion of any unwanted Helm chart releases.
If promoting Helm charts across different environments and different chart repositories, the steps should be as follows:
This approach is flexible and robust and prevents teams from accidentally promoting unwanted releases to the production environment, as the production Helm chart repository won’t contain the uncertified chart versions, but it does add a little complexity to the workflow.
If you are looking for ways to accelerate your organization’s cloud-native continuous deployment, get in touch with Apexon today using the form below.