Kubernetes Helm: K8s Application Deployment Made Simple

What is Kubernetes Helm?

Helm is a package manager for Kubernetes, similar to yum for Linux or npm for Node.js. Charts deployed by Helm are complete, packaged Kubernetes applications. They include versioned, pre-configured application resources that can be deployed as a single unit. You can deploy different versions of the chart with different sets of configurations.

Helm is an important part of a well-designed Kubernetes architecture. It can significantly improve the Kubernetes development experience, by improving productivity, making Kubernetes applications less complex, and making it easier to manage cloud native and microservices applications.

In this article, you will learn:

• What Problems Does Kubernetes Helm Solve?
• Helm Architecture
• Kubernetes Helm Best Practices
  • Helm Repositories are Optional
  • Chart Versions and appVersions
  • Avoid a Chart Per Service
  • Use Helm End-to-End
  • Do Not Tamper with Helm-Deployed Environments

What Problems Does Kubernetes Helm Solve?

Kubernetes isn’t easy to learn and use, especially for those new to containerized environments. Kubernetes Helm can make Kubernetes much easier to use by:

• Sharing Helm charts—Helm charts are a convenient way to share commonly used applications like databases, CMSs, etc. Other developers, both in the same organization and in others, can then deploy the same application on Kubernetes effortlessly.
• Reduced complexity—applications orchestrated by Kubernetes can be very complex, and deployments can break if you use incorrect values in the configuration file or if YAML templates are not planned correctly. Helm charts allow the community to preconfigure applications, define fixed and configurable values that make it possible to customize the deployment, and provide a consistent interface for configuration changes.
• Preventing bad configuration—Helm charts make it possible to lock down bad configurations, further reducing complexity and eliminating deployment errors. This can also have security advantages, because well configured Helm charts can already have security best practices built in.

Helm Architecture

As of Helm 3, Helm is a client-only system: the client is known as helm, it interacts directly with the Kubernetes API server. The old Helm server-side component, known as Tiller, has been removed.

Here are the main components of Kubernetes Helm is a bit more detail:

• Helm—a command line interface (CLI) that installs charts on Kubernetes, and defines a release for each installation. Helm can install charts from a Helm Repository, or from chart files you provide.
• Chart—an application package containing a template of the set of resources required to run the application. The template uses variables, which are replaced by values when creating the manifest—a YAML-encoded record of resources that were generated by the release. The chart contains a values file that lets you specify your individual configuration.
• Release—an instance of a chart running on a Kubernetes cluster. Installing the same chart multiple times results in multiple releases.
• Repository—lets you store and manage Helm charts. There is a central hub for official Helm charts, and you can store your own.

Kubernetes Helm Best Practices

The following best practices can help you use Helm more effectively.

Chart Versions and appVersions

Helm charts have two types of versions—the chart version (version field in Chart.yaml) and the version of the application deployed by the chart (appVersion field in Chart.yaml). The two are totally independent and can be synced or separated. However, it is recommended to maintain consistency in your versioning strategy across all charts.

Centralize Charts for the Entire Organization

A considerable advantage of Helm charts is the ability to consolidate multiple operational components, which have a common denominator, into a single chart. Avoid placing a single chart in each repository from which you intend to deploy. Instead, invest in having a central set of charts that can serve the entire organization.

This makes it easy to administer standardized health checks, and maintain common configurations across the organization. And, as an added benefit, you can update Kubernetes resource API versions from a central location.

To facilitate using a central set of Helm charts for the entire organization, ensure charts are created by experienced Kubernetes professionals, who can plan them for consistent use across multiple use cases. Ensure they are built with proper error handling, consistent labeling, and correct YAML indentation. 

Use Helm End-to-End

Helm is more than just a template engine. It is a package manager that also includes template functionality. It is possible to only use Helm to create a generic Kubernetes manifest, and install it on your cluster using kubectl, but this misses the true power of the platform. Helm truly shines when you use it as an end-to-end package manager, and use it not only to create manifests but also to actually install applications on your cluster.

Do Not Tamper with Helm-Deployed Environments

If you are using the Helm CLI, make sure that only Helm can change values in Kubernetes manifest. For example, don’t modify deployment replicas directly—use Helm to change the values. 

You may be familiar with kubectl apply, which is an easy way to deploy resources to your Kubernetes environment. However, you should not use kubectl for Helm-deployed environments, as this can cause problems the next time you run Helm commands. To change your environment, modify values in your Helm chart and use Helm to redeploy.

Automating Kubernetes Infrastructure with Spot by NetApp

To further reduce the complexities of Kubernetes environments, Spot Ocean automates infrastructure management. Users can leverage the Spot Helm chart to deploy the Ocean toolkit, which will install the Spot Kubernetes controller and operators, as well as a metrics-server. These components are core to Ocean’s serverless engine and delivering: 

• Container-driven autoscaling for the fastest matching of pods with appropriate nodes
• Easy management of workloads with different resource requirements in a single cluster
• Intelligent bin-packing for highly utilized nodes and greater cost-efficiency
• Cost allocation by namespaces, resources, annotation and labels
• Reliable usage of the optimal blend of spot, reserved and on-demand compute pricing models
• Automated infrastructure headroom ensuring high availability
• Right-sizing based on actual pod resource consumption  

Learn more about Spot Ocean today!