Helm is a package manager for Kubernetes that allows deploying and managing Kubernetes applications. It defines applications as charts that contain templates for Kubernetes manifest files along with configuration parameters. Helm runs a server called Tiller on the Kubernetes cluster that manages releasing and installing charts. Charts can be stored in local or remote repositories and contain templates, dependencies, configuration and hooks. Helm provides commands to search, install, upgrade, and delete releases of packaged applications on Kubernetes clusters.

1. Helm and the zen of managing complex
Kubernetes apps
Devopsdays Edinburgh 2017
Abhishek Chanda
@rony358

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. Writing charts
● Templating
● Debug and deploy
● Rinse and repeat

10. 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
$ helm repo add my-charts
http://mystorage.mycompany.io
$ cat gorest-chart/requirements.yaml
dependencies:
- name: postgresql
version: "9.6"
repository: "@my-charts"

11. 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

12. 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

13. 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

14. 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/

15. Questions?