Helm V3, Latest & Greatest of Kubernetes

shimib — Wed, 19 Aug 2020 17:53:39 +0000

Helm is becoming the de facto standard for managing Kubernetes deployments.
Although not the only tool in the landscape, it’s by far more popular than the alternatives.
The reason for using Helm is quite obvious: managing your K8S deployments by hand requires a lot of YAML manipulation which usually leads to high maintenance and duplication.

Recently, Helm v3 was released and I wanted to describe the changes and new features in detail.

Removal of Tiller

If you have worked with previous versions of Helm, one of the mandatory installation components was the Tiller Helm server that needed to be installed in your K8s cluster.
You might have asked, why is it needed? Can’t all the operations be performed from the client side?
Well, when Helm v2 was released in 2016, some of the K8s features that we are now used to (e.g., Custom Resource Definitions (CRDs)) weren’t available yet.
These days, there is really no need for Tiller.
In version 3, Tiller is no more ☺

With the removal of Tiller, there is no centralized namespace where all Releases’ information is stored (the namespace where the Tiller was installed). Now this information is stored in the namespace of the chart itself.
Your releases are now under their own namespace (yes you have to create the namespace).

Security is also now handled where it should, i.e., by K8s RBAC.

XDG-based Directory Structure

Starting with Helm v3, directory structure and its configuration are based on the XDG Base Directory Specification.
For those not familiar, the XDG specification defines standard environment variables for locating the home directory and various subfolders.

In version 3, $HELM_HOME is no more ☺

Also, the “helm init” and “helm home” commands no longer exist.

Library Charts

Starting with v3, a chart can have the type (meta-data chart property) of either “application” or “library” (“application” by default).
Library charts are common charts that are reusable and intended for use in a containing application.

Regarding chart dependencies, requirements and dependencies have been moved into the chart.yaml itself.
A Smooth Migration?

While experimenting with Helm v3, I ran into some issues where I had a chart deployed with v2 and tried to delete and replace it using a v3 client.
I got some weird errors when trying to reinstall the chart (e.g., already exists). Although looking at “helm ls” didn’t display anything about my chart.
This error occurred because the different versions of Helm store their catalog in different locations.
I had to revert to Helm v2 client to purge my chart.
So, keep that in mind and follow proper migration guides.

ChartCenter

Combined with the release of Helm v3, I was also excited to hear the announcement of ChartCenter.
ChartCenter (https://chartcenter.io/) provides you with all the information you need about the charts you depend on, including security vulnerabilities scanning information powered by JFrog Xray.
On the site’s UI you can dig deep into the subcomponents of the included containers and see the vulnerable components down to the application’s dependencies.
Not only do I now have a “go-to” place for fetching my infrastructure chart, I can also assure myself that my dependencies have no critical security vulnerabilities.

Best Practices with Container Registry

shimib — Wed, 04 Dec 2019 21:53:15 +0000

With the announcement of JFrog Container Registry, I wanted to share several thoughts about some patterns and best practices regarding container registries.

Use multiple repositories

In many organizations there are clear and well-defined policies regarding permissions. In some companies, members of one team can’t access the images of other teams (in some cases they shouldn’t even be aware of the existence of those projects)

Although you could probably define fine-grained permissions based on image names/paths, an easier and more maintainable approach would be to define it by repositories!

Use Build Promotions

The main idea here is to ‘promote’ your builds (images) to more mature repositories as your artifacts graduate through the CI/CD pipeline.
This means having different repositories for the different CI/CD phases (e.g., dev, qa, pre-prod and prod).
Then, your runtime (e.g., K8S cluster) should pull images only from a production-level repository.
This best-practice goes hand-to-hand with the previous one of having multiple repositories.

Always use Virtual Repositories

A virtual repository is an aggregate of one or more repositories. It allows you to manage this group while providing your clients (developers, build jobs and consumption sites) a single and stable URI.
When always exposing your repositories through virtual ones (even when you have a single repository) you essentially guarantee that maintenance will not require changes on the consuming side (jobs, developers, etc.…).

Always Publish Build-info

If your container registry supports it, always publish build information along with the image you build.
For example, dependency information about what actually resides in the image itself.
Let’s discuss an example:
Suppose you are building a Java web application (WAR file) and put that in a Docker image.
Your Docker image doesn’t have a direct dependency on the Java application. In Docker, dependencies are always in the form of Docker layers.
Having in your build information the dependencies themselves (i.e., the Java application and its own dependencies) will greatly help with traceability, scanning and management of the process.

High Availability