Helm and the zen of managing complex Kubernetes apps

Helm and the zen of managing complex Kubernetes apps

Devopsdays Edinburgh 2017

F421ada6691154df746598ee49535df4?s=128

Abhishek Chanda

October 23, 2017
Tweet

Transcript

  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?