Helm and the zen of managing complex

Kubernetes apps

Devopsdays Edinburgh 2017

Abhishek Chanda
@rony358
whoami
● Openstacker (formerly), Kubernaut, Pythonista and Rustacean

● Devops/backend/software engineer at DataSine

● Manages a few Kubernetes clusters on AWS

… and that’s how I bumped into Helm

Problem: deploying a Kubernetes app
… is hardly straightforward

● Multiple interacting components: Deployment, ConfigMap, Service etc.

● Dependencies

● No easy way to parameterize the manifests

○ CI/CD integration

Similar to installing applications on a Linux box

sudo apt install nginx

Solution: a cloud native package manager
Let’s call it Helm

● Single command application install on Kubernetes

● Template based configuration of manifests

○ Supports go text templating and Sprig extensions

● Reproducible installations

● Ecosystem of searchable and shareable packages

● Supports signing and verifying package integrity

Helm terms
● Chart: a set of things that define a complete application

○ Manifest templates, dependencies, post installation instructions

○ Stored in repositories (local or remote)

○ Packaged as a tgz archive

● Config: a set of configuration parameters for a given chart

○ Predefined or user-defined

○ Final config = predefined + user-defined + defaults

● Release: a configured and installed instance of a chart

○ Defined by manifests generated from templates using config

Helm architecture
● Client side CLI: helm

○ Search, configure, install and uninstall a chart

○ Local development: skeleton chart, debugging

○ Interacting with chart repositories

● Server: tiller

○ Runs as a Kubernetes service in the kube-system namespace

○ Manages release lifecycle

helm init --upgrade
Anatomy of a helm chart
● Chart.yaml has release metadata

● values.yaml has default values for config parameters

● requirements.yaml can be used to declare dependencies

○ Dependencies are vendored in the charts/ directory

● templates/ directory has templates for generating manifests

○ NOTES.txt has post-install usage notes

○ _helpers.tpl has template helper functions

● pre/post install, delete, upgrade, rollback hooks

Using helm
$ helm init gorest-chart

$ helm install gorest-chart/

$ helm install kubernetes-charts/nginx-ingress

$ helm --dry-run --debug gorest-chart/

$ helm list

$ helm delete <release_name> --purge

Writing charts
● Templating

● Debug and deploy

● Rinse and repeat

Chart repositories
● Stores charts

○ Charts as tgz archives

○ An index.yaml file has metadata about charts (generated by helm)

○ Fronted by a HTTP server

○ Useful for private chart hosting

$ helm repo list

$ cat gorest-chart/requirements.yaml
dependencies:
$ helm repo add my-charts \ - name: postgresql
http://mystorage.mycompany.io version: "9.6"
repository: "@my-charts"
Standard repositories
● https://github.com/kubernetes/charts

○ Stable: charts that meet a set of requirements and are widely used

○ Incubator: staging for stable

● https://kubeapps.com/

○ Built on the monocular web UI for helm chart repositories

Also many others from different organizations

Helm plugins
● Extend functionality without modifying the core

○ Plugins exposed as a subcommand for helm

● Can be in any language as long as it produces an executable

● Must follow a set of guidelines to integrate with the core

Useful for debugging charts: https://github.com/technosophos/helm-template

Anatomy of a plugin
● Located in $(helm home)/plugins

● Plugin.yaml has metadata

○ name is the helm subcommand

○ command is the command to execute

on invoking the plugin

● Helm also passes some

env vars to the plugin
Demo!
● We have an existing cluster running an app
https://github.com/achanda/gorest

● Chart is located in the same directory

https://github.com/achanda/gorest/tree/master/gorest-chart

● We will build a new image locally and push it up to GCR

● We will use Helm to update the image tag of our release

○ Easily automatable in a CI system

helm upgrade <name> --set image.tag=0.2 gorest-chart/

Questions?