github.com/pensu/helm@v2.6.1+incompatible/docs/glossary.md (about) 1 # Helm Glossary 2 3 Helm uses a few special terms to describe components of the 4 architecture. 5 6 ## Chart 7 8 A Helm package that contains information sufficient for installing a set 9 of Kubernetes resources into a Kubernetes cluster. 10 11 Charts contain a `Chart.yaml` file as well as templates, default values 12 (`values.yaml`), and dependencies. 13 14 Charts are developed in a well-defined directory structure, and then 15 packaged into an archive format called a _chart archive_. 16 17 ## Chart Archive 18 19 A _chart archive_ is a tarred and gzipped (and optionally signed) chart. 20 21 ## Chart Dependency (Subcharts) 22 23 Charts may depend upon other charts. There are two ways a dependency may 24 occur: 25 26 - Soft dependency: A chart may simply not function without another chart 27 being installed in a cluster. Helm does not provide tooling for this 28 case. In this case, dependencies may be managed separately. 29 - Hard dependency: A chart may contain (inside of its `charts/` 30 directory) another chart upon which it depends. In this case, 31 installing the chart will install all of its dependencies. In this 32 case, a chart and its dependencies are managed as a collection. 33 34 When a chart is packaged (via `helm package`) all of its hard dependencies 35 are bundled with it. 36 37 ## Chart Version 38 39 Charts are versioned according to the [SemVer 2 40 spec](http://semver.org). A version number is required on every chart. 41 42 ## Chart.yaml 43 44 Information about a chart is stored in a special file called 45 `Chart.yaml`. Every chart must have this file. 46 47 ## Helm (and helm) 48 49 Helm is the package manager for Kubernetes. As an operating system 50 package manager makes it easy to install tools on an OS, Helm makes it 51 easy to install applications and resources into Kubernetes clusters. 52 53 While _Helm_ is the name of the project, the command line client is also 54 named `helm`. By convention, when speaking of the project, _Helm_ is 55 capitalized. When speaking of the client, _helm_ is in lowercase. 56 57 ## Helm Home (HELM_HOME) 58 59 The Helm client stores information in a local directory referred to as 60 _helm home_. By default, this is in the `$HOME/.helm` directory. 61 62 This directory contains configuration and cache data, and is created by 63 `helm init`. 64 65 ## Kube Config (KUBECONFIG) 66 67 The Helm client learns about Kubernetes clusters by using files in the _Kube 68 config_ file format. By default, Helm attempts to find this file in the 69 place where `kubectl` creates it (`$HOME/.kube/config`). 70 71 ## Lint (Linting) 72 73 To _lint_ a chart is to validate that it follows the conventions and 74 requirements of the Helm chart standard. Helm provides tools to do this, 75 notably the `helm lint` command. 76 77 ## Provenance (Provenance file) 78 79 Helm charts may be accompanied by a _provenance file_ which provides 80 information about where the chart came from and what it contains. 81 82 Provenance files are one part of the Helm security story. A provenance contains 83 a cryptographic hash of the chart archive file, the Chart.yaml data, and 84 a signature block (an OpenPGP "clearsign" block). When coupled with a 85 keychain, this provides chart users with the ability to: 86 87 - Validate that a chart was signed by a trusted party 88 - Validate that the chart file has not been tampered with 89 - Validate the contents of a chart metadata (`Chart.yaml`) 90 - Quickly match a chart to its provenance data 91 92 Provenance files have the `.prov` extension, and can be served from a 93 chart repository server or any other HTTP server. 94 95 ## Release 96 97 When a chart is installed, Tiller (the Helm server) creates a _release_ 98 to track that installation. 99 100 A single chart may be installed many times into the same cluster, and 101 create many different releases. For example, one can install three 102 PostgreSQL databases by running `helm install` three times with a 103 different release name. 104 105 (Prior to 2.0.0-Alpha.1, releases were called _deployments_. But this 106 caused confusion with the Kubernetes _Deployment_ kind.) 107 108 ## Release Number (Release Version) 109 110 A single release can be updated multiple times. A sequential counter is 111 used to track releases as they change. After a first `helm install`, a 112 release will have _release number_ 1. Each time a release is upgraded or 113 rolled back, the release number will be incremented. 114 115 ## Rollback 116 117 A release can be upgraded to a newer chart or configuration. But since 118 release history is stored, a release can also be _rolled back_ to a 119 previous release number. This is done with the `helm rollback` command. 120 121 Importantly, a rolled back release will receive a new release number. 122 123 Operation | Release Number 124 ----------|--------------- 125 install | release 1 126 upgrade | release 2 127 upgrade | release 3 128 rollback 1| release 4 (but running the same config as release 1) 129 130 The above table illustrates how release numbers increment across 131 install, upgrade, and rollback. 132 133 ## Tiller 134 135 Tiller is the in-cluster component of Helm. It interacts directly with 136 the Kubernetes API server to install, upgrade, query, and remove 137 Kubernetes resources. It also stores the objects that represent 138 releases. 139 140 ## Repository (Repo, Chart Repository) 141 142 Helm charts may be stored on dedicated HTTP servers called _chart 143 repositories_ (_repositories_, or just _repos_). 144 145 A chart repository server is a simple HTTP server that can serve an 146 `index.yaml` file that describes a batch of charts, and provides 147 information on where each chart can be downloaded from. (Many chart 148 repositories serve the charts as well as the `index.yaml` file.) 149 150 A Helm client can point to zero or more chart repositories. By default, 151 Helm clients point to the `stable` official Kubernetes chart 152 repository. 153 154 ## Values (Values Files, values.yaml) 155 156 Values provide a way to override template defaults with your own 157 information. 158 159 Helm Charts are "parameterized", which means the chart developer may 160 expose configuration that can be overridden at installation time. For 161 example, a chart may expose a `username` field that allows setting a 162 user name for a service. 163 164 These exposed variables are called _values_ in Helm parlance. 165 166 Values can be set during `helm install` and `helm upgrade` operations, 167 either by passing them in directly, or by uploading a `values.yaml` 168 file. 169 170