{{announcement.body}}
{{announcement.title}}

Navigating Kubernetes With Helm 3 Charts and ChartCenter

DZone 's Guide to

Navigating Kubernetes With Helm 3 Charts and ChartCenter

ChartCenter is a free central repository for discovering Helm Charts, created to help manage your Kubernetes applications

· DevOps Zone ·
Free Resource

Many DevOps teams use Docker for secure deployments and agility, and use the popular open-source container orchestration tool known as Kubernetes. Kubernetes has a steep learning curve, and the setup for your Kubernetes clusters can become complex. This is where the ecosystem really benefits from an additional support tool like Helm, a package manager, to streamline installing and managing Kubernetes applications. The building block when it comes to Helm based deployments are Helm Charts, and these charts are the packages managed by Helm. Helm charts are curated, reusable application definitions for Kubernetes, nothing but a curated set of files that define a related set of Kubernetes resources for an application. 

Helm 3 is one of the most eagerly anticipated releases by the Kubernetes enthusiasts. This latest version of Helm is finally available. Let’s take a look at how we got here.

History of Helm

Plain Kubernetes manifests can be used to release and roll out an application and its related resources. It works fine initially and allows you to have Infrastructure as code. While it is perfectly feasible to keep your YAML files in a Git repository, there is no practical way of versioning them correctly. You can use the Git revision, but ideally, you’d like to have something more appropriate, like semantic versioning, and that’s where Helm as a tool helps developers. Helm is a package manager for Kubernetes and is a well-defined gateway for better application and release management on clusters. Helm also happens to be the only tool that provides a dependency declaration between applications.

Helm was initially an open-source project of Deis, Inc, and the focus of Helm was to shorten the complex Kubernetes learning curve. In that direction, Helm 1 was introduced to make it easy for Kubernetes enthusiasts to rapidly and smoothly install their first workloads on Kubernetes without worrying much. The Helm was officially announced at the inaugural KubeCon conference San Francisco in 2015. After a few months, the team at Helm joined with Google’s Kubernetes Deployment team and began working on Helm 2. 

In Helm 2, there were security and access control issues since it was not possible to give selective access control while using Tiller, and anyone who can talk with Tiller could make changes or releases. We needed to create a Service Account and also a Role for the Tiller, and the whole thing became a big headache to maintain and use. Also Helm 2 used to keep an unlimited history of every release, which used to have an adverse impact on the system. In contrast, Helm 3, only the last 10 release histories are saved by default, and they reside as Kubernetes secret.

Introducing Helm 3

A lot of changes went into version three of the tool and incorporated some valuable modifications. All in all, it was an effort to make Helm 3 more secure and simpler to use. With the release of Helm 3, the companies are keen to migrate off Helm 2 as soon as possible to enjoy the new benefits of productivity, usability improvements, improved security, and backward compatibility. Here is more information on how to migrate from Helm v2 to Helm v3 by co-founder of Helm Rimas Mocevicius (@rimusz).

The Helm project has undergone a significant rewrite to match up with the evolution of Kubernetes and provide solutions to the security concerns involved. If you’re aware that Tiller has been removed in the new version of Helm, this means that you already know a lot. Tiller used to add unnecessary complexity and also posed a security risk to the project. By default, Tiller used to expose an unauthenticated gRPC endpoint inside the Kubernetes cluster. That made a massive impact on the community. Removing Tiller in v3 became an essential step forward. 

Helm 3 has made Helm a standard in the DevOps ecosystem and the community is growing faster than ever. Helm is now a client-only tool. Since Custom Resource Definitions are available, there is no need for Tiller to maintain state or be the central hub to report about releases deployed through Helm. Helm 2 had ConfigMaps to store release information, and Helm 3 uses Secrets as the default storage driver, which is also a much-needed security upgrade.. Helm 3 includes features like improvements to the chart format, distributed repositories, performance-oriented changes for chart repositories, JSON schema validation,and  a new event system that chart developers can tie into and much more. 

Kubernetes API evolved over time, but it was time to kick out Tiller, and it finally happened. Today, Helm 3 has a client-only architecture (the client still called Helm). The client interacts directly with the Kubernetes API server without any dependencies. Helm 3 supports all the modern security, identity, and authorization features of modern Kubernetes. Let’s see what else Helm 3 supports:

Release management:

Using Release Objects and Kubernetes Secrets, releases will be managed inside of Kubernetes in Helm 3. Any modifications such as installing, upgrading, downgrading releases will end in having a new version of the Kubernetes Secret. 

Chart dependency:

Now users have to care about only a few files as the dependencies are directly listed inside of the Chart.yaml file in Helm 3. Before, dependencies used to be maintained with the requirements.yaml file.

Helm initialization:

Now there is no need to initialize Helm because it is obsolete in version 3. Helm init has been removed, and a Helm state is created automatically whenever required, so no need to set up a Helm state before using it.

Library chart support: 

Helm 3 supports a new and updated class of chart called “library chart,” a chart that is shared by other charts. It does not create any release artifacts of its own. This library chart’s templates can only declare to define elements.

Helm Charts and Docker Images

When you have an application that is running on five containers or less in small startups, you can smoothly run, deploy, and manage these containers on Docker alone without any difficulty. But the problem arises for enterprise applications that run thousands of containers, managing these containers becomes exceptionally complicated - especially at scale. This is Kubernetes has become the de-facto container orchestration tool to manage all your functional aspects for Service Management, Scheduling, and Resource Management.

So while Docker containers are connected to Kubernetes for the orchestration purpose, Kubernetes, in turn, is dependent on Helm for smooth sailing of applications. How? 

Kubernetes can be tricky and complex, to ease the usage and smooth deployment of applications, Hem charts can be used to create reproducible builds and manage the state of the application. A single chart might be used to deploy something simple or you can use a chart with other chart dependencies for complex applications. How do you find these more involved Helm charts?

Finding Helm Charts

As we know, Helm is a digestible way to get started with Kubernetes productively. DevOps team can perform the same activities using standard kubectl commands, but working with Helm charts provides the ability to quickly define, easily manage, and quickly deploy the applications. Kubernetes + Helm duo will become a must to have toolset for DevOps specialists. To use Helm, the key is finding the right charts.

HelmHub was one of the first places to find an index of all publicly available Helm charts and can be accessed directly from the Helm.sh website. While HelmHub has been great as a first resource for developers, charts aren’t actually hosted there and can go down. Many in the community have been asking for a robust and stable system to host, store, and deploy their Helm applications. CNCF currently has an alpha release for a more evolved project called Artifact Hub: https://artifacthub.io/. Artifact Hub will allow developers a user portal to upload their charts, and also supports operator and Falco projects, but there is new helm chart central repository that solves a lot of the issues faced by the community.

JFrog ChartCenter

ChartCenter is where you can find immutable and secure Helm charts. It is the new central Helm repository from JFrog, and it comes with hundreds of charts to get you started on your Helm journey. You can focus on organizational charts or search to see more than 200 additional Helm charts to help you with your Kubernetes setup and deployment. The great thing about ChartCenter - a feature that makes it unique is that you can even see security information right in the UI. ChartCenter scans all charts and versions and provides vulnerability information for the dependencies (the docker images and subcharts associated with them) for free and gives you access to this in the security and dependencies tabs. This information comes from publicly available databases such as NVD and is provided via JFrog Xray.

Other important features that make ChartCenter unique are:

1. Central Repo for artifact distribution - Today there are over 800+ different repositories and users need to add the different repos individually that they need to their helm client or a repository manager they use. ChartCenter simplifies this by reducing it to just one central repo that you can point to using $ helm repo add center https://repo.chartcenter.

2. Immutable, HA - A central repo which is immutable and includes HA (high availability) means users don't have to worry about outages in the multitude of repos they might be using with different SLAs.

3. Superior Search - ChartCenter uses Elasticsearch to provide you a way to find charts by name, description, and keyword.

4. Upstream Dependencies - With the dependency tab, knowing that the Helm chart you are using is not reliant on deprecated, stale or vulnerable components is very helpful to mitigate production issues.

5. Downstream consumers - For maintainers knowing who else depends on their charts can help them understand use cases as well as provide better understanding of breaking changes. For consumers, this can be a measure of stability in addition to other metrics such as downloads.

6. Security - Free vulnerability information provided by JFrog Xray on ChartCenter.

To conclude, ChartCenter is an improvement over existing solutions because of its immutability. All Helm charts in ChartCenter are permanently stored, and every available version can be accessed from the drop-down menu. ChartCenter also has robust metadata that show you keywords, chart type, license, and download information. On the Charts Info tab, you can even track linting issues and see maintainer information. My favorite part of JFrog’s ChartCenter is the dependency tab that also shows all the transitive dependencies for each chart. You can click on the sub-charts and be directed there in ChartCenter to see how charts and docker images are associated with each other. And so, ChartCenter is a great improvement to the Helm ecosystem and as an immutable, safe, and free central repository that includes high-level security - it’s a great central place for all your Helm charts. 

Topics:
chartcenter, helm, helm chart, heml review, history of helm, kubernetes

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}