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