Difference between revisions of "Helm"
From Christoph's Personal Wiki
(→Commands) |
(→Commands) |
||
(5 intermediate revisions by the same user not shown) | |||
Line 29: | Line 29: | ||
*<tt>verify</tt> — verify that a chart at the given path has been signed and is valid | *<tt>verify</tt> — verify that a chart at the given path has been signed and is valid | ||
*<tt>version</tt> — print the client/server version information | *<tt>version</tt> — print the client/server version information | ||
+ | |||
+ | <pre> | ||
+ | $ 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) | ||
+ | </pre> | ||
+ | |||
+ | <pre> | ||
+ | $ 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) | ||
+ | </pre> | ||
+ | |||
+ | <pre> | ||
+ | $ helm status [tab][tab] | ||
+ | nginx (nginx-9.5.16 -> deployed) | ||
+ | nginx-previous (nginx-8.9.1 -> deployed) | ||
+ | wordpress (wordpress-12.2.7 -> deployed) | ||
+ | </pre> | ||
+ | |||
+ | <pre> | ||
+ | $ helm --kube-context [tab][tab] | ||
+ | prod (production) | ||
+ | dev (development) | ||
+ | </pre> | ||
+ | |||
+ | ==Miscellaneous examples== | ||
+ | |||
+ | * Install a Helm Chart with: | ||
+ | <pre> | ||
+ | $ helm upgrade --install ${MY_CHART_NAME} -f values.yaml --namespace=default . | ||
+ | </pre> | ||
+ | |||
+ | * Install a Helm Chart with multiple values and variables: | ||
+ | <pre> | ||
+ | $ helm upgrade \ | ||
+ | --install ${MY_CHART_NAME} \ | ||
+ | --set-string version="1.1.0" \ | ||
+ | --values values.yaml \ | ||
+ | --values values-"${DEPLOY_ENV}".yaml \ | ||
+ | --namespace=${MY_CHART_NAME} . | ||
+ | </pre> | ||
+ | |||
+ | * Another example: | ||
+ | <pre> | ||
+ | $ 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}" \ | ||
+ | . | ||
+ | </pre> | ||
+ | |||
+ | * Delete this Helm Chart (i.e., destroy what it created) with: | ||
+ | <pre> | ||
+ | $ helm delete --purge ${MY_CHART_NAME} | ||
+ | </pre> | ||
+ | |||
+ | ==Example Helm Charts== | ||
+ | |||
+ | ===ConfigMap=== | ||
+ | |||
+ | <pre> | ||
+ | . | ||
+ | ├── 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 | ||
+ | </pre> | ||
+ | |||
+ | ==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 [https://github.com/helm/helm/blob/release-2.10/pkg/tiller/kind_sorter.go#L29 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 [https://github.com/helm/helm/blob/release-2.10/pkg/tiller/kind_sorter.go#L61 here]). | ||
==External links== | ==External links== |
Latest revision as of 19:00, 11 April 2022
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).