Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Helm and the zen of managing complex Kubernetes...

Helm and the zen of managing complex Kubernetes apps

Devopsdays Edinburgh 2017

Abhishek Chanda

October 23, 2017
Tweet

Other Decks in Technology

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. 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"
  10. 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
  11. 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
  12. 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
  13. 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/