Helm
From Christoph's Personal Wiki
Helm is a package manager for Kubernetes.
Contents
Commands
- completion — generate autocompletions script for the specified shell (bash or zsh)
- create — create a new chart with the given name
- delete — given a release name, delete the release from Kubernetes
- dependency — manage a chart's dependencies
- fetch — download a chart from a repository and (optionally) unpack it in local directory
- get — download a named release
- help — help about any command
- history — fetch release history
- home — displays the location of HELM_HOME
- init — initialize Helm on both client and server
- inspect — inspect a chart
- install — install a chart archive
- lint — examines a chart for possible issues
- list — list releases
- package — package a chart directory into a chart archive
- plugin — add, list, or remove Helm plugins
- repo — add, list, remove, update, and index chart repositories
- reset — uninstalls Tiller from a cluster
- rollback — roll back a release to a previous revision
- search — search for a keyword in charts
- serve — start a local http web server
- status — displays the status of the named release
- template — locally render templates
- test — test a release
- upgrade — upgrade a release
- verify — verify that a chart at the given path has been signed and is valid
- version — print the client/server version information
$ helm -[tab][tab] --debug (enable verbose output) --kube-apiserver (the address and the port for the Kubernetes API server) --kube-as-group (group to impersonate for the operation, this flag can be repeated to specify multiple groups.) --kube-as-user (username to impersonate for the operation) --kube-ca-file (the certificate authority file for the Kubernetes API server connection) --kube-context (name of the kubeconfig context to use) --kube-token (bearer token used for authentication) --kubeconfig (path to the kubeconfig file) --namespace (namespace scope for this request) --registry-config (path to the registry config file) --repository-cache (path to the file containing cached repository indexes) --repository-config (path to the file containing repository names and URLs) -n (namespace scope for this request)
$ helm repo [tab][tab] add (add a chart repository) index (generate an index file given a directory containing packaged charts) list (list chart repositories) remove (remove one or more chart repositories) update (update information of available charts locally from chart repositories)
$ helm status [tab][tab] nginx (nginx-9.5.16 -> deployed) nginx-previous (nginx-8.9.1 -> deployed) wordpress (wordpress-12.2.7 -> deployed)
$ helm --kube-context [tab][tab] prod (production) dev (development)
Miscellaneous examples
- Install a Helm Chart with:
$ helm upgrade --install ${MY_CHART_NAME} -f values.yaml --namespace=default .
- Install a Helm Chart with multiple values and variables:
$ helm upgrade \
--install ${MY_CHART_NAME} \
--set-string version="1.1.0" \
--values values.yaml \
--values values-"${DEPLOY_ENV}".yaml \
--namespace=${MY_CHART_NAME} .
- Another example:
$ helm3 upgrade \
--debug \
--install \
--atomic --cleanup-on-fail --timeout 1200s \
--namespace "${PROJECT_NAME}" \
--create-namespace \
--set-string version="${GITHUB_SHA:0:7}" \
--values ./values.yaml \
--values ./values-"${DEPLOY_ENV}".yaml \
"${PROJECT_NAME}" \
.
- Delete this Helm Chart (i.e., destroy what it created) with:
$ helm delete --purge ${MY_CHART_NAME}
Example Helm Charts
ConfigMap
.
├── Chart.yaml
├── templates
│ └── configmap.yaml
└── values.yaml
$ cat values.yaml
vaultConfigMap:
name: vault-demo
namespace: default
certificateAuthorityPem: |
-----BEGIN CERTIFICATE-----
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD==
-----END CERTIFICATE-----
$ cat templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Values.vaultConfigMap.name }}
namespace: {{ .Values.vaultConfigMap.namespace }}
data:
ca.pem: |
{{ .Values.vaultConfigMap.certificateAuthorityPem | indent 4 }}
$ helm template .
---
# Source: foobar/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: vault-demo
namespace: default
data:
ca.pem: |
-----BEGIN CERTIFICATE-----
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD==
-----END CERTIFICATE-----
$ helm template . | kubectl create -f -
configmap/vault-demo created
$ kubectl get cm vault-demo -o yaml
apiVersion: v1
data:
ca.pem: |
-----BEGIN CERTIFICATE-----
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD==
-----END CERTIFICATE-----
kind: ConfigMap
Deployment order
Helm collects all of the resources in a given Chart and its dependencies, groups them by resource type, and then installs them in the following order (as shown here):
- Namespace
- ResourceQuota
- LimitRange
- PodSecurityPolicy
- Secret
- ConfigMap
- StorageClass
- PersistentVolume
- PersistentVolumeClaim
- ServiceAccount
- CustomResourceDefinition
- ClusterRole
- ClusterRoleBinding
- Role
- RoleBinding
- Service
- DaemonSet
- Pod
- ReplicationController
- ReplicaSet
- Deployment
- StatefulSet
- Job
- CronJob
- Ingress
- APIService
During uninstallation of a release, the order is reversed (as shown here).
