Helm and the zen of managing complex Kubernetes apps
Download as PPTX, PDF1 like108 views
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.
Helm and the zen of managing complex Kubernetes apps
- 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?