Adding system package management to k8s: Hypper

In the last months with Rancher & SUSE, the team I am part of has been working on expanding Helm use-cases for “system and shared” Helm chart dependencies (apart of other upcoming projects).

This has been wonderful; we have knowledgeable Helm Maintainers in our team, which provide valuable insights. There’s always places to look for use-cases in Rancher and SUSE, and getting to know Helm’s codebase as a prototypical successful Golang application is pretty deece.

Helm is awesome: provides a way to manage Kubernetes applications as packages: Helm charts. Yet, it is too general, and so far it only solves tasks of the application developer persona.

• What if you are a Kubernetes system manager, which juggles several tenants/apps, each of them with their own dependency requirements?

• Have you ever wanted to easily install, share and keep track of 1 DB deployment, 1 Prometheus monitoring service, and 1 tracing service in use by several apps?

• Would you like to create tightly knit chart repositories where the charts can optionally depend on one or several of the others, and get notified on when you can update which?

• How about auto-removing charts once no application depends on them?

Enter Hypper!

Hypper extends Helm with concepts of a usual Linux system package manager:

• Shared-dependency charts
• Optional shared-dependency charts
• Default release name and namespaces for charts
• To come: SAT solver, repo tooling for curating and linting, info and upgrades on outdated dependencies, auto-removal of unused deps, “provides” and “implements” charts …

With Hypper, you can create and consume curated repositories of Hypper charts that work well together.

How does a Hypper chart look?

Hypper charts add support for all of that by just expanding the Helm chart Chart.yaml and adding keys and values in Metadata.Annotations:

# Chart.yaml of example hypper-charts/our-app
# This is a diff, showing the added yaml for Hypper

apiVersion: v2
name: our-app
description: An example Hypper chart for Kubernetes
type: application
sources:
  - https://github.com/rancher-sandbox/hypper
version: 0.0.1
appVersion: 0.0.1
annotations:
+  # This is Hypper specific:
+  hypper.cattle.io/namespace: hypper           # default ns for the chart, if none provided
+  hypper.cattle.io/release-name: our-app-name  # default name for the installed release, if none provided
+  hypper.cattle.io/shared-dependencies: |      # list of shared-dependencies of the chart
+    - name: fleet
+      version: "^0.3.500"
+      repository: "https://rancher-sandbox.github.io/hypper-charts/repo"
+    - name: rancher-tracing
+      version: "^1.20.002"
+      repository: "https://rancher-sandbox.github.io/hypper-charts/repo"

Hypper charts are a superset of Helm charts, and keep being valid Helm charts. This means easier upstreaming, and transparent mixing of Helm and Hypper charts.

How does one use Hypper?

Just as Helm, Hypper is both a Golang CLI application and a library:

Hypper’s library extends Helm’s, providing an API to develop against. Its compatibility is governed by semver, it has online docs, and the works.

Hypper’s CLI, hypper, makes use of Hypper’s and Helm’s APIs, and aims to behave just like helm, plus added functionality. In fact, since we are just expanding functionality, they are compatible: you can list Hypper charts and shared-dependencies with helm ls as they are just normal Helm Releases, for example.

We are building Hypper’s CLI and Library to be easily upstreamable into Helm, as we would be happy to see this functionality in future Helm major versions. And we are diligently writing docs and how-tos.

So, if you would like to install the previous Hypper chart and its shared-dependencies, it would look like this:

1. Obtain the repo and chart:

$ hypper repo add hypper-charts 'https://rancher-sandbox.github.io/hypper-charts/repo'
"hypper-charts" has been added to your repositories

$ hypper repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "hypper-charts" chart repository
🛳  Update Complete.

$ hypper pull hypper-charts/our-app # to inspect, or list shared-deps for now

1. Install our-app chart:

$ hypper install hypper-charts/our-app --create-namespace
🛳  Installing shared dependencies for chart "our-app":
🛳  - Installing chart "fleet" as "fleet" in namespace "fleet-system"…
🛳  - Installing chart "rancher-tracing" as "rancher-tracing" in namespace "istio-system"…
🛳  Installing chart "our-app" as "our-app-name" in namespace "hypper"…
👏 Done!

$ hypper ls -A
NAME            NAMESPACE       REVISION        UPDATED                                         STATUS          CHART                           APP VERSION
fleet           fleet-system    1               2021-05-11 17:34:32.389488138 +0200 CEST        deployed        fleet-0.3.500                   0.3.5
our-app-name    hypper          1               2021-05-11 17:34:33.071095379 +0200 CEST        deployed        our-app-0.0.1                   0.0.1
rancher-tracing istio-system    1               2021-05-11 17:34:32.987548361 +0200 CEST        deployed        rancher-tracing-1.20.002        1.20.0

$ hypper shared-deps list ./our-app-0.0.1.tgz
NAME            VERSION         REPOSITORY                                              STATUS          NAMESPACE       TYPE
fleet           ^0.3.500        https://rancher-sandbox.github.io/hypper-charts/repo    deployed        fleet-system    shared
rancher-tracing ^1.20.002       https://rancher-sandbox.github.io/hypper-charts/repo    deployed        istio-system    shared

Thanks to the chart annotations, Hypper automatically knows under what name and namespace to install our-app, and the same applies to its shared-dependencies.

Hypper is still malleable! So don’t hesitate to give it a try, and if you have any comments, questions, feature requests!, or want to stick around, just open an issue at github.com/rancher-sandbox/hypper, come talk to us at #hypper@rancher-users Slack, or write me directly ;).