helm aliases docs plugins A Helm plugin is a tool that can be accessed through the CLI but which Introduces how to use and create plugins to extend Helm s functionality is not part of the built in Helm codebase title The Helm Plugins Guide weight 12

Answer:
---
title: "The Helm Plugins Guide"
description: "Introduces how to use and create plugins to extend Helm's functionality."
aliases: ["/docs/plugins/"]
weight: 12
---

A Helm plugin is a tool that can be accessed through the `helm` CLI, but which
is not part of the built-in Helm codebase.

Existing plugins can be found on [related]() section or by searching
[GitHub](https://github.com/search?q=topic%3Ahelm-plugin&type=Repositories).

This guide explains how to use and create plugins.

## An Overview

Helm plugins are add-on tools that integrate seamlessly with Helm. They provide
a way to extend the core feature set of Helm, but without requiring every new
feature to be written in Go and added to the core tool.

Helm plugins have the following features:

- They can be added and removed from a Helm installation without impacting the
  core Helm tool.
- They can be written in any programming language.
- They integrate with Helm, and will show up in `helm help` and other places.

Helm plugins live in `$HELM_PLUGINS`. You can find the current value of this,
including the default value when not set in the environment, using the
`helm env` command.

The Helm plugin model is partially modeled on Git's plugin model. To that end,
you may sometimes hear `helm` referred to as the _porcelain_ layer, with plugins
being the _plumbing_. This is a shorthand way of suggesting that Helm provides
the user experience and top level processing logic, while the plugins do the
"detail work" of performing a desired action.

## Installing a Plugin

Plugins are installed using the `$ helm plugin install <path|url>` command. You
can pass in a path to a plugin on your local file system or a url of a remote
VCS repo. The `helm plugin install` command clones or copies the plugin at the
path/url given into `$HELM_PLUGINS`

```console
$ helm plugin install https://github.com/adamreese/helm-env
```

If you have a plugin tar distribution, simply untar the plugin into the
`$HELM_PLUGINS` directory. You can also install tarball plugins
directly from url by issuing `helm plugin install
https://domain/path/to/plugin.tar.gz`

## Testing a locally built Plugin

First you need to find your `HELM_PLUGINS` path to do it run the folowing command:

``` bash
helm env
```

Change your current directory to the director that `HELM_PLUGINS` is set to.

Now you can add a symbolic link to your build out put of your plugin in this example we did it for `mapkubeapis`.

``` bash
ln -s ~/GitHub/helm-mapkubeapis ./helm-mapkubeapis
```

## Building Plugins

In many ways, a plugin is similar to a chart. Each plugin has a top-level
directory, and then a `plugin.yaml` file.

```
$HELM_PLUGINS/
  |- last/
      |
      |- plugin.yaml
      |- last.sh

```

In the example above, the `last` plugin is contained inside of a directory
named `last`. It has two files: `plugin.yaml` (required) and an executable
script, `last.sh` (optional).

The core of a plugin is a simple YAML file named `plugin.yaml`. Here is a plugin
YAML for a plugin that helps get the last release name:

```yaml
name: "last"
version: "0.1.0"
usage: "get the last release name"
description: "get the last release name"
ignoreFlags: false
command: "$HELM_BIN --host $TILLER_HOST list --short --max 1 --date -r"
platformCommand:
  - os: linux
    arch: i386
    command: "$HELM_BIN list --short --max 1 --date -r"
  - os: linux
    arch: amd64
    command: "$HELM_BIN list --short --max 1 --date -r"
  - os: windows
    arch: amd64
    command: "$HELM_BIN list --short --max 1 --date -r"
```

The `name` is the name of the plugin. When Helm executes this plugin, this is
the name it will use (e.g. `helm NAME` will invoke this plugin).

_`name` should match the directory name._ In our example above, that means the
plugin with `name: last` should be contained in a directory named `last`.

Restrictions on `name`:

- `name` cannot duplicate one of the existing `helm` top-level commands.
- `name` must be restricted to the characters ASCII a-z, A-Z, 0-9, `_` and `-`.

`version` is the SemVer 2 version of the plugin. `usage` and `description` are
both used to generate the help text of a command.

The `ignoreFlags` switch tells Helm to _not_ pass flags to the plugin. So if a
plugin is called with `helm myplugin --foo` and `ignoreFlags: true`, then
`--foo` is silently discarded.

Finally, and most importantly, `platformCommand` or `command` is the command
that this plugin will execute when it is called. The `platformCommand` section
defines the OS/Architecture specific variations of a command. The following
rules will apply in deciding which command to use:

- If `platformCommand` is present, it will be searched first.
- If both `os` and `arch` match the current platform, search will stop and the
  command will be used.
- If `os` matches and there is no more specific `arch` match, the command will
  be used.
- If no `platformCommand` match is found, the default `command` will be used.
- If no matches are found in `platformCommand` and no `command` is present, Helm
  will exit with an error.

Environment variables are interpolated before the plugin is executed. The
pattern above illustrates the preferred way to indicate where the plugin program
lives.

There are some strategies for working with plugin commands:

- If a plugin includes an executable, the executable for a `platformCommand:` or
  a `command:` should be packaged in the plugin directory.
- The `platformCommand:` or `command:` line will have any environment variables
  expanded before execution. `$HELM_PLUGIN_DIR` will point to the plugin
  directory.
- The command itself is not executed in a shell. So you can't oneline a shell
  script.
- Helm injects lots of configuration into environment variables. Take a look at
  the environment to see what information is available.
- Helm makes no assumptions about the language of the plugin. You can write it
  in whatever you prefer.
- Commands are responsible for implementing specific help text for `-h` and
  `--help`. Helm will use `usage` and `description` for `helm help` and `helm
  help myplugin`, but will not handle `helm myplugin --help`.

## Downloader Plugins
By default, Helm is able to pull Charts using HTTP/S. As of Helm 2.4.0, plugins
can have a special capability to download Charts from arbitrary sources.

Plugins shall declare this special capability in the `plugin.yaml` file (top
level):

```yaml
downloaders:
- command: "bin/mydownloader"
  protocols:
  - "myprotocol"
  - "myprotocols"
```

If such plugin is installed, Helm can interact with the repository using the
specified protocol scheme by invoking the `command`. The special repository
shall be added similarly to the regular ones: `helm repo add favorite
myprotocol://example.com/` The rules for the special repos are the same to the
regular ones: Helm must be able to download the `index.yaml` file in order to
discover and cache the list of available Charts.

The defined command will be invoked with the following scheme: `command certFile
keyFile caFile full-URL`. The SSL credentials are coming from the repo
definition, stored in `$HELM_REPOSITORY_CONFIG`
(i.e., `$HELM_CONFIG_HOME/repositories.yaml`). A Downloader plugin
is expected to dump the raw content to stdout and report errors on stderr.

The downloader command also supports sub-commands or arguments, allowing you to
specify for example `bin/mydownloader subcommand -d` in the `plugin.yaml`. This
is useful if you want to use the same executable for the main plugin command and
the downloader command, but with a different sub-command for each.

## Environment Variables

When Helm executes a plugin, it passes the outer environment to the plugin, and
also injects some additional environment variables.

Variables like `KUBECONFIG` are set for the plugin if they are set in the outer
environment.

The following variables are guaranteed to be set:

- `HELM_PLUGINS`: The path to the plugins directory.
- `HELM_PLUGIN_NAME`: The name of the plugin, as invoked by `helm`. So `helm
  myplug` will have the short name `myplug`.
- `HELM_PLUGIN_DIR`: The directory that contains the plugin.
- `HELM_BIN`: The path to the `helm` command (as executed by the user).
- `HELM_DEBUG`: Indicates if the debug flag was set by helm.
- `HELM_REGISTRY_CONFIG`: The location for the registry configuration (if
  using). Note that the use of Helm with registries is an experimental feature.
- `HELM_REPOSITORY_CACHE`: The path to the repository cache files.
- `HELM_REPOSITORY_CONFIG`: The path to the repository configuration file.
- `HELM_NAMESPACE`: The namespace given to the `helm` command (generally using
  the `-n` flag).
- `HELM_KUBECONTEXT`: The name of the Kubernetes config context given to the
  `helm` command.

Additionally, if a Kubernetes configuration file was explicitly specified, it
will be set as the `KUBECONFIG` variable

## A Note on Flag Parsing

When executing a plugin, Helm will parse global flags for its own use. None of
these flags are passed on to the plugin.

- `--debug`: If this is specified, `$HELM_DEBUG` is set to `1`
- `--registry-config`: This is converted to `$HELM_REGISTRY_CONFIG`
- `--repository-cache`: This is converted to `$HELM_REPOSITORY_CACHE`
- `--repository-config`: This is converted to `$HELM_REPOSITORY_CONFIG`
- `--namespace` and `-n`: This is converted to `$HELM_NAMESPACE`
- `--kube-context`: This is converted to `$HELM_KUBECONTEXT`
- `--kubeconfig`: This is converted to `$KUBECONFIG`

Plugins _should_ display help text and then exit for `-h` and `--help`. In all
other cases, plugins may use flags as appropriate.

## Providing shell auto-completion

As of Helm 3.2, a plugin can optionally provide support for shell
auto-completion as part of Helm's existing auto-completion mechanism.

### Static auto-completion

If a plugin provides its own flags and/or sub-commands, it can inform Helm of
them by having a `completion.yaml` file located in the plugin's root directory.
The `completion.yaml` file has the form:

```yaml
name: <pluginName>
flags:
- <flag 1>
- <flag 2>
validArgs:
- <arg value 1>
- <arg value 2>
commands:
  name: <commandName>
  flags:
  - <flag 1>
  - <flag 2>
  validArgs:
  - <arg value 1>
  - <arg value 2>
  commands:
     <and so on, recursively>
```

Notes:
1. All sections are optional but should be provided if applicable.
1. Flags should not include the `-` or `--` prefix.
1. Both short and long flags can and should be specified. A short flag need not
   be associated with its corresponding long form, but both forms should be
   listed.
1. Flags need not be ordered in any way, but need to be listed at the correct
   point in the sub-command hierarchy of the file.
1. Helm's existing global flags are already handled by Helm's auto-completion
   mechanism, therefore plugins need not specify the following flags `--debug`,
   `--namespace` or `-n`, `--kube-context`, and `--kubeconfig`, or any other
   global flag.
1. The `validArgs` list provides a static list of possible completions for the
   first parameter following a sub-command.  It is not always possible to
   provide such a list in advance (see the [Dynamic
   Completion](#dynamic-completion) section below), in which case the
   `validArgs` section can be omitted.

The `completion.yaml` file is entirely optional.  If it is not provided, Helm
will simply not provide shell auto-completion for the plugin (unless [Dynamic
Completion](#dynamic-completion) is supported by the plugin).  Also, adding a
`completion.yaml` file is backwards-compatible and will not impact the behavior
of the plugin when using older helm versions.

As an example, for the [`fullstatus
plugin`](https://github.com/marckhouzam/helm-fullstatus) which has no
sub-commands but accepts the same flags as the `helm status` command, the
`completion.yaml` file is:

```yaml
name: fullstatus
flags:
- o
- output
- revision
```

A more intricate example for the [`2to3
plugin`](https://github.com/helm/helm-2to3), has a `completion.yaml` file of:

```yaml
name: 2to3
commands:
- name: cleanup
  flags:
  - config-cleanup
  - dry-run
  - l
  - label
  - release-cleanup
  - s
  - release-storage
  - tiller-cleanup
  - t
  - tiller-ns
  - tiller-out-cluster
- name: convert
  flags:
  - delete-v2-releases
  - dry-run
  - l
  - label
  - s
  - release-storage
  - release-versions-max
  - t
  - tiller-ns
  - tiller-out-cluster
- name: move
  commands:
  - name: config
    flags:
    - dry-run
```

### Dynamic completion

Also starting with Helm 3.2, plugins can provide their own dynamic shell
auto-completion. Dynamic shell auto-completion is the completion of parameter
values or flag values that cannot be defined in advance.  For example,
completion of the names of helm releases currently available on the cluster.

For the plugin to support dynamic auto-completion, it must provide an
**executable** file called `plugin.complete` in its root directory. When the
Helm completion script requires dynamic completions for the plugin, it will
execute the `plugin.complete` file, passing it the command-line that needs to be
completed.  The `plugin.complete` executable will need to have the logic to
determine what the proper completion choices are and output them to standard
output to be consumed by the Helm completion script.

The `plugin.complete` file is entirely optional.  If it is not provided, Helm
will simply not provide dynamic auto-completion for the plugin.  Also, adding a
`plugin.complete` file is backwards-compatible and will not impact the behavior
of the plugin when using older helm versions.

The output of the `plugin.complete` script should be a new-line separated list
such as:

```
rel1
rel2
rel3
```

When `plugin.complete` is called, the plugin environment is set just like when
the plugin's main script is called. Therefore, the variables `$HELM_NAMESPACE`,
`$HELM_KUBECONTEXT`, and all other plugin variables will already be set, and
their corresponding global flags will be removed.

The `plugin.complete` file can be in any executable form; it can be a shell
script, a Go program, or any other type of program that Helm can execute. The
`plugin.complete` file ***must*** have executable permissions for the user. The
`plugin.complete` file ***must*** exit with a success code (value 0).

In some cases, dynamic completion will require to obtain information from the
Kubernetes cluster.  For example, the `helm fullstatus` plugin requires a
release name as input. In the `fullstatus` plugin, for its `plugin.complete`
script to provide completion for current release names, it can simply run `helm
list -q` and output the result.

If it is desired to use the same executable for plugin execution and for plugin
completion, the `plugin.complete` script can be made to call the main plugin
executable with some special parameter or flag; when the main plugin executable
detects the special parameter or flag, it will know to run the completion. In
our example, `plugin.complete` could be implemented like this:

```sh
#!/usr/bin/env sh

# "$@" is the entire command-line that requires completion.
# It is important to double-quote the "$@" variable to preserve a possibly empty last parameter.
$HELM_PLUGIN_DIR/status.sh --complete "$@"
```

The `fullstatus` plugin's real script (`status.sh`) must then look for the
`--complete` flag and if found, printout the proper completions.

### Tips and tricks

1. The shell will automatically filter out completion choices that don't match
   user input. A plugin can therefore return all relevant completions without
   removing the ones that don't match the user input.  For example, if the
   command-line is `helm fullstatus ngin<TAB>`, the `plugin.complete` script can
   print *all* release names (of the `default` namespace), not just the ones
   starting with `ngin`; the shell will only retain the ones starting with
   `ngin`.
1. To simplify dynamic completion support, especially if you have a complex
   plugin, you can have your  `plugin.complete` script call your main plugin
   script and request completion choices.  See the [Dynamic
   Completion](#dynamic-completion) section above for an example.
1. To debug dynamic completion and the `plugin.complete` file, one can run the
   following to see the completion results :
    - `helm __complete <pluginName> <arguments to complete>`.  For example:
    - `helm __complete fullstatus --output js<ENTER>`,
    - `helm __complete fullstatus -o json ""<ENTER>`

title   The Helm Plugins Guide  description   Introduces how to use and create plugins to extend Helm s functionality   aliases     docs plugins    weight  12      A Helm plugin is a tool that can be accessed through the  helm  CLI  but which is not part of the built in Helm codebase   Existing plugins can be found on  related    section or by searching  GitHub  https   github com search q topic 3Ahelm plugin type Repositories    This guide explains how to use and create plugins      An Overview  Helm plugins are add on tools that integrate seamlessly with Helm  They provide a way to extend the core feature set of Helm  but without requiring every new feature to be written in Go and added to the core tool   Helm plugins have the following features     They can be added and removed from a Helm installation without impacting the   core Helm tool    They can be written in any programming language    They integrate with Helm  and will show up in  helm help  and other places   Helm plugins live in   HELM PLUGINS   You can find the current value of this  including the default value when not set in the environment  using the  helm env  command   The Helm plugin model is partially modeled on Git s plugin model  To that end  you may sometimes hear  helm  referred to as the  porcelain  layer  with plugins being the  plumbing   This is a shorthand way of suggesting that Helm provides the user experience and top level processing logic  while the plugins do the  detail work  of performing a desired action      Installing a Plugin  Plugins are installed using the    helm plugin install  path url   command  You can pass in a path to a plugin on your local file system or a url of a remote VCS repo  The  helm plugin install  command clones or copies the plugin at the path url given into   HELM PLUGINS      console   helm plugin install https   github com adamreese helm env      If you have a plugin tar distribution  simply untar the plugin into the   HELM PLUGINS  directory  You can also install tarball plugins directly from url by issuing  helm plugin install https   domain path to plugin tar gz      Testing a locally built Plugin  First you need to find your  HELM PLUGINS  path to do it run the folowing command       bash helm env      Change your current directory to the director that  HELM PLUGINS  is set to   Now you can add a symbolic link to your build out put of your plugin in this example we did it for  mapkubeapis        bash ln  s   GitHub helm mapkubeapis   helm mapkubeapis         Building Plugins  In many ways  a plugin is similar to a chart  Each plugin has a top level directory  and then a  plugin yaml  file        HELM PLUGINS       last                   plugin yaml          last sh       In the example above  the  last  plugin is contained inside of a directory named  last   It has two files   plugin yaml   required  and an executable script   last sh   optional    The core of a plugin is a simple YAML file named  plugin yaml   Here is a plugin YAML for a plugin that helps get the last release name      yaml name   last  version   0 1 0  usage   get the last release name  description   get the last release name  ignoreFlags  false command    HELM BIN   host  TILLER HOST list   short   max 1   date  r  platformCommand      os  linux     arch  i386     command    HELM BIN list   short   max 1   date  r      os  linux     arch  amd64     command    HELM BIN list   short   max 1   date  r      os  windows     arch  amd64     command    HELM BIN list   short   max 1   date  r       The  name  is the name of the plugin  When Helm executes this plugin  this is the name it will use  e g   helm NAME  will invoke this plugin      name  should match the directory name   In our example above  that means the plugin with  name  last  should be contained in a directory named  last    Restrictions on  name       name  cannot duplicate one of the existing  helm  top level commands     name  must be restricted to the characters ASCII a z  A Z  0 9      and        version  is the SemVer 2 version of the plugin   usage  and  description  are both used to generate the help text of a command   The  ignoreFlags  switch tells Helm to  not  pass flags to the plugin  So if a plugin is called with  helm myplugin   foo  and  ignoreFlags  true   then    foo  is silently discarded   Finally  and most importantly   platformCommand  or  command  is the command that this plugin will execute when it is called  The  platformCommand  section defines the OS Architecture specific variations of a command  The following rules will apply in deciding which command to use     If  platformCommand  is present  it will be searched first    If both  os  and  arch  match the current platform  search will stop and the   command will be used    If  os  matches and there is no more specific  arch  match  the command will   be used    If no  platformCommand  match is found  the default  command  will be used    If no matches are found in  platformCommand  and no  command  is present  Helm   will exit with an error   Environment variables are interpolated before the plugin is executed  The pattern above illustrates the preferred way to indicate where the plugin program lives   There are some strategies for working with plugin commands     If a plugin includes an executable  the executable for a  platformCommand   or   a  command   should be packaged in the plugin directory    The  platformCommand   or  command   line will have any environment variables   expanded before execution    HELM PLUGIN DIR  will point to the plugin   directory    The command itself is not executed in a shell  So you can t oneline a shell   script    Helm injects lots of configuration into environment variables  Take a look at   the environment to see what information is available    Helm makes no assumptions about the language of the plugin  You can write it   in whatever you prefer    Commands are responsible for implementing specific help text for   h  and      help   Helm will use  usage  and  description  for  helm help  and  helm   help myplugin   but will not handle  helm myplugin   help       Downloader Plugins By default  Helm is able to pull Charts using HTTP S  As of Helm 2 4 0  plugins can have a special capability to download Charts from arbitrary sources   Plugins shall declare this special capability in the  plugin yaml  file  top level       yaml downloaders    command   bin mydownloader    protocols       myprotocol       myprotocols       If such plugin is installed  Helm can interact with the repository using the specified protocol scheme by invoking the  command   The special repository shall be added similarly to the regular ones   helm repo add favorite myprotocol   example com   The rules for the special repos are the same to the regular ones  Helm must be able to download the  index yaml  file in order to discover and cache the list of available Charts   The defined command will be invoked with the following scheme   command certFile keyFile caFile full URL   The SSL credentials are coming from the repo definition  stored in   HELM REPOSITORY CONFIG   i e     HELM CONFIG HOME repositories yaml    A Downloader plugin is expected to dump the raw content to stdout and report errors on stderr   The downloader command also supports sub commands or arguments  allowing you to specify for example  bin mydownloader subcommand  d  in the  plugin yaml   This is useful if you want to use the same executable for the main plugin command and the downloader command  but with a different sub command for each      Environment Variables  When Helm executes a plugin  it passes the outer environment to the plugin  and also injects some additional environment variables   Variables like  KUBECONFIG  are set for the plugin if they are set in the outer environment   The following variables are guaranteed to be set      HELM PLUGINS   The path to the plugins directory     HELM PLUGIN NAME   The name of the plugin  as invoked by  helm   So  helm   myplug  will have the short name  myplug      HELM PLUGIN DIR   The directory that contains the plugin     HELM BIN   The path to the  helm  command  as executed by the user      HELM DEBUG   Indicates if the debug flag was set by helm     HELM REGISTRY CONFIG   The location for the registry configuration  if   using   Note that the use of Helm with registries is an experimental feature     HELM REPOSITORY CACHE   The path to the repository cache files     HELM REPOSITORY CONFIG   The path to the repository configuration file     HELM NAMESPACE   The namespace given to the  helm  command  generally using   the   n  flag      HELM KUBECONTEXT   The name of the Kubernetes config context given to the    helm  command   Additionally  if a Kubernetes configuration file was explicitly specified  it will be set as the  KUBECONFIG  variable     A Note on Flag Parsing  When executing a plugin  Helm will parse global flags for its own use  None of these flags are passed on to the plugin        debug   If this is specified    HELM DEBUG  is set to  1       registry config   This is converted to   HELM REGISTRY CONFIG       repository cache   This is converted to   HELM REPOSITORY CACHE       repository config   This is converted to   HELM REPOSITORY CONFIG       namespace  and   n   This is converted to   HELM NAMESPACE       kube context   This is converted to   HELM KUBECONTEXT       kubeconfig   This is converted to   KUBECONFIG   Plugins  should  display help text and then exit for   h  and    help   In all other cases  plugins may use flags as appropriate      Providing shell auto completion  As of Helm 3 2  a plugin can optionally provide support for shell auto completion as part of Helm s existing auto completion mechanism       Static auto completion  If a plugin provides its own flags and or sub commands  it can inform Helm of them by having a  completion yaml  file located in the plugin s root directory  The  completion yaml  file has the form      yaml name   pluginName  flags     flag 1     flag 2  validArgs     arg value 1     arg value 2  commands    name   commandName    flags       flag 1       flag 2    validArgs       arg value 1       arg value 2    commands        and so on  recursively       Notes  1  All sections are optional but should be provided if applicable  1  Flags should not include the     or      prefix  1  Both short and long flags can and should be specified  A short flag need not    be associated with its corresponding long form  but both forms should be    listed  1  Flags need not be ordered in any way  but need to be listed at the correct    point in the sub command hierarchy of the file  1  Helm s existing global flags are already handled by Helm s auto completion    mechanism  therefore plugins need not specify the following flags    debug         namespace  or   n      kube context   and    kubeconfig   or any other    global flag  1  The  validArgs  list provides a static list of possible completions for the    first parameter following a sub command   It is not always possible to    provide such a list in advance  see the  Dynamic    Completion   dynamic completion  section below   in which case the     validArgs  section can be omitted   The  completion yaml  file is entirely optional   If it is not provided  Helm will simply not provide shell auto completion for the plugin  unless  Dynamic Completion   dynamic completion  is supported by the plugin    Also  adding a  completion yaml  file is backwards compatible and will not impact the behavior of the plugin when using older helm versions   As an example  for the   fullstatus plugin   https   github com marckhouzam helm fullstatus  which has no sub commands but accepts the same flags as the  helm status  command  the  completion yaml  file is      yaml name  fullstatus flags    o   output   revision      A more intricate example for the   2to3 plugin   https   github com helm helm 2to3   has a  completion yaml  file of      yaml name  2to3 commands    name  cleanup   flags      config cleanup     dry run     l     label     release cleanup     s     release storage     tiller cleanup     t     tiller ns     tiller out cluster   name  convert   flags      delete v2 releases     dry run     l     label     s     release storage     release versions max     t     tiller ns     tiller out cluster   name  move   commands      name  config     flags        dry run          Dynamic completion  Also starting with Helm 3 2  plugins can provide their own dynamic shell auto completion  Dynamic shell auto completion is the completion of parameter values or flag values that cannot be defined in advance   For example  completion of the names of helm releases currently available on the cluster   For the plugin to support dynamic auto completion  it must provide an   executable   file called  plugin complete  in its root directory  When the Helm completion script requires dynamic completions for the plugin  it will execute the  plugin complete  file  passing it the command line that needs to be completed   The  plugin complete  executable will need to have the logic to determine what the proper completion choices are and output them to standard output to be consumed by the Helm completion script   The  plugin complete  file is entirely optional   If it is not provided  Helm will simply not provide dynamic auto completion for the plugin   Also  adding a  plugin complete  file is backwards compatible and will not impact the behavior of the plugin when using older helm versions   The output of the  plugin complete  script should be a new line separated list such as       rel1 rel2 rel3      When  plugin complete  is called  the plugin environment is set just like when the plugin s main script is called  Therefore  the variables   HELM NAMESPACE     HELM KUBECONTEXT   and all other plugin variables will already be set  and their corresponding global flags will be removed   The  plugin complete  file can be in any executable form  it can be a shell script  a Go program  or any other type of program that Helm can execute  The  plugin complete  file    must    have executable permissions for the user  The  plugin complete  file    must    exit with a success code  value 0    In some cases  dynamic completion will require to obtain information from the Kubernetes cluster   For example  the  helm fullstatus  plugin requires a release name as input  In the  fullstatus  plugin  for its  plugin complete  script to provide completion for current release names  it can simply run  helm list  q  and output the result   If it is desired to use the same executable for plugin execution and for plugin completion  the  plugin complete  script can be made to call the main plugin executable with some special parameter or flag  when the main plugin executable detects the special parameter or flag  it will know to run the completion  In our example   plugin complete  could be implemented like this      sh    usr bin env sh         is the entire command line that requires completion    It is important to double quote the      variable to preserve a possibly empty last parameter   HELM PLUGIN DIR status sh   complete           The  fullstatus  plugin s real script   status sh   must then look for the    complete  flag and if found  printout the proper completions       Tips and tricks  1  The shell will automatically filter out completion choices that don t match    user input  A plugin can therefore return all relevant completions without    removing the ones that don t match the user input   For example  if the    command line is  helm fullstatus ngin TAB    the  plugin complete  script can    print  all  release names  of the  default  namespace   not just the ones    starting with  ngin   the shell will only retain the ones starting with     ngin   1  To simplify dynamic completion support  especially if you have a complex    plugin  you can have your   plugin complete  script call your main plugin    script and request completion choices   See the  Dynamic    Completion   dynamic completion  section above for an example  1  To debug dynamic completion and the  plugin complete  file  one can run the    following to see the completion results          helm   complete  pluginName   arguments to complete     For example         helm   complete fullstatus   output js ENTER           helm   complete fullstatus  o json    ENTER


helm title Role based Access Control Explains how Helm interacts with Kubernetes Role Based Access Control weight 11 scope that you have specified Read more about service account permissions in account is a best practice to ensure that your application is operating in the In Kubernetes granting roles to a user or an application specific service aliases docs rbac

Answer:
---
title: "Role-based Access Control"
description: "Explains how Helm interacts with Kubernetes' Role-Based Access Control."
aliases: ["/docs/rbac/"]
weight: 11
---

In Kubernetes, granting roles to a user or an application-specific service
account is a best practice to ensure that your application is operating in the
scope that you have specified. Read more about service account permissions [in
the official Kubernetes
docs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions).

From Kubernetes 1.6 onwards, Role-based Access Control is enabled by default.
RBAC allows you to specify which types of actions are permitted depending on the
user and their role in your organization.

With RBAC, you can

- grant privileged operations (creating cluster-wide resources, like new roles)
  to administrators
- limit a user's ability to create resources (pods, persistent volumes,
  deployments) to specific namespaces, or in cluster-wide scopes (resource
  quotas, roles, custom resource definitions)
- limit a user's ability to view resources either in specific namespaces or at a
  cluster-wide scope.

This guide is for administrators who want to restrict the scope of a user's
interaction with the Kubernetes API.

## Managing user accounts

All Kubernetes clusters have two categories of users: service accounts managed
by Kubernetes, and normal users.

Normal users are assumed to be managed by an outside, independent service. An
administrator distributing private keys, a user store like Keystone or Google
Accounts, even a file with a list of usernames and passwords. In this regard,
Kubernetes does not have objects which represent normal user accounts. Normal
users cannot be added to a cluster through an API call.

In contrast, service accounts are users managed by the Kubernetes API. They are
bound to specific namespaces, and created automatically by the API server or
manually through API calls. Service accounts are tied to a set of credentials
stored as Secrets, which are mounted into pods allowing in-cluster processes to
talk to the Kubernetes API.

API requests are tied to either a normal user or a service account, or are
treated as anonymous requests. This means every process inside or outside the
cluster, from a human user typing `kubectl` on a workstation, to kubelets on
nodes, to members of the control plane, must authenticate when making requests
to the API server, or be treated as an anonymous user.

## Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings

In Kubernetes, user accounts and service accounts can only view and edit
resources they have been granted access to. This access is granted through the
use of Roles and RoleBindings. Roles and RoleBindings are bound to a particular
namespace, which grant users the ability to view and/or edit resources within
that namespace the Role provides them access to.

At a cluster scope, these are called ClusterRoles and ClusterRoleBindings.
Granting a user a ClusterRole grants them access to view and/or edit resources
across the entire cluster. It is also required to view and/or edit resources at
the cluster scope (namespaces, resource quotas, nodes).

ClusterRoles can be bound to a particular namespace through reference in a
RoleBinding. The `admin`, `edit` and `view` default ClusterRoles are commonly
used in this manner.

These are a few ClusterRoles available by default in Kubernetes. They are
intended to be user-facing roles. They include super-user roles
(`cluster-admin`), and roles with more granular access (`admin`, `edit`,
`view`).

| Default ClusterRole | Default ClusterRoleBinding | Description
|---------------------|----------------------------|-------------
| `cluster-admin`     | `system:masters` group     | Allows super-user access to perform any action on any resource. When used in a ClusterRoleBinding, it gives full control over every resource in the cluster and in all namespaces. When used in a RoleBinding, it gives full control over every resource in the rolebinding's namespace, including the namespace itself.
| `admin`             | None                       | Allows admin access, intended to be granted within a namespace using a RoleBinding. If used in a RoleBinding, allows read/write access to most resources in a namespace, including the ability to create roles and rolebindings within the namespace. It does not allow write access to resource quota or to the namespace itself.
| `edit`              | None                       | Allows read/write access to most objects in a namespace. It does not allow viewing or modifying roles or rolebindings.
| `view`              | None                       | Allows read-only access to see most objects in a namespace. It does not allow viewing roles or rolebindings. It does not allow viewing secrets, since those are escalating.

## Restricting a user account's access using RBAC

Now that we understand the basics of Role-based Access Control, let's discuss
how an administrator can restrict a user's scope of access.

### Example: Grant a user read/write access to a particular namespace

To restrict a user's access to a particular namespace, we can use either the
`edit` or the `admin` role. If your charts create or interact with Roles and
Rolebindings, you'll want to use the `admin` ClusterRole.

Additionally, you may also create a RoleBinding with `cluster-admin` access.
Granting a user `cluster-admin` access at the namespace scope provides full
control over every resource in the namespace, including the namespace itself.

For this example, we will create a user with the `edit` Role. First, create the
namespace:

```console
$ kubectl create namespace foo
```

Now, create a RoleBinding in that namespace, granting the user the `edit` role.

```console
$ kubectl create rolebinding sam-edit
    --clusterrole edit \
    --user sam \
    --namespace foo
```

### Example: Grant a user read/write access at the cluster scope

If a user wishes to install a chart that installs cluster-scope resources
(namespaces, roles, custom resource definitions, etc.), they will require
cluster-scope write access.

To do that, grant the user either `admin` or `cluster-admin` access.

Granting a user `cluster-admin` access grants them access to absolutely every
resource available in Kubernetes, including node access with `kubectl drain` and
other administrative tasks. It is highly recommended to consider providing the
user `admin` access instead, or to create a custom ClusterRole tailored to their
needs.

```console
$ kubectl create clusterrolebinding sam-view
    --clusterrole view \
    --user sam

$ kubectl create clusterrolebinding sam-secret-reader
    --clusterrole secret-reader \
    --user sam
```

### Example: Grant a user read-only access to a particular namespace

You might've noticed that there is no ClusterRole available for viewing secrets.
The `view` ClusterRole does not grant a user read access to Secrets due to
escalation concerns. Helm stores release metadata as Secrets by default.

In order for a user to run `helm list`, they need to be able to read these
secrets. For that, we will create a special `secret-reader` ClusterRole.

Create the file `cluster-role-secret-reader.yaml` and write the following
content into the file:

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
```

Then, create the ClusterRole using

```console
$ kubectl create -f clusterrole-secret-reader.yaml
```

Once that's done, we can grant a user read access to most resources, and then
grant them read access to secrets:

```console
$ kubectl create namespace foo

$ kubectl create rolebinding sam-view
    --clusterrole view \
    --user sam \
    --namespace foo

$ kubectl create rolebinding sam-secret-reader
    --clusterrole secret-reader \
    --user sam \
    --namespace foo
```

### Example: Grant a user read-only access at the cluster scope

In certain scenarios, it may be beneficial to grant a user cluster-scope access.
For example, if a user wants to run the command `helm list --all-namespaces`,
the API requires the user has cluster-scope read access.

To do that, grant the user both `view` and `secret-reader` access as described
above, but with a ClusterRoleBinding.

```console
$ kubectl create clusterrolebinding sam-view
    --clusterrole view \
    --user sam

$ kubectl create clusterrolebinding sam-secret-reader
    --clusterrole secret-reader \
    --user sam
```

## Additional Thoughts

The examples shown above utilize the default ClusterRoles provided with
Kubernetes. For more fine-grained control over what resources users are granted
access to, have a look at [the Kubernetes
documentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) on
creating your own custom Roles and ClusterRoles.

title   Role based Access Control  description   Explains how Helm interacts with Kubernetes  Role Based Access Control   aliases     docs rbac    weight  11      In Kubernetes  granting roles to a user or an application specific service account is a best practice to ensure that your application is operating in the scope that you have specified  Read more about service account permissions  in the official Kubernetes docs  https   kubernetes io docs reference access authn authz rbac  service account permissions    From Kubernetes 1 6 onwards  Role based Access Control is enabled by default  RBAC allows you to specify which types of actions are permitted depending on the user and their role in your organization   With RBAC  you can    grant privileged operations  creating cluster wide resources  like new roles    to administrators   limit a user s ability to create resources  pods  persistent volumes    deployments  to specific namespaces  or in cluster wide scopes  resource   quotas  roles  custom resource definitions    limit a user s ability to view resources either in specific namespaces or at a   cluster wide scope   This guide is for administrators who want to restrict the scope of a user s interaction with the Kubernetes API      Managing user accounts  All Kubernetes clusters have two categories of users  service accounts managed by Kubernetes  and normal users   Normal users are assumed to be managed by an outside  independent service  An administrator distributing private keys  a user store like Keystone or Google Accounts  even a file with a list of usernames and passwords  In this regard  Kubernetes does not have objects which represent normal user accounts  Normal users cannot be added to a cluster through an API call   In contrast  service accounts are users managed by the Kubernetes API  They are bound to specific namespaces  and created automatically by the API server or manually through API calls  Service accounts are tied to a set of credentials stored as Secrets  which are mounted into pods allowing in cluster processes to talk to the Kubernetes API   API requests are tied to either a normal user or a service account  or are treated as anonymous requests  This means every process inside or outside the cluster  from a human user typing  kubectl  on a workstation  to kubelets on nodes  to members of the control plane  must authenticate when making requests to the API server  or be treated as an anonymous user      Roles  ClusterRoles  RoleBindings  and ClusterRoleBindings  In Kubernetes  user accounts and service accounts can only view and edit resources they have been granted access to  This access is granted through the use of Roles and RoleBindings  Roles and RoleBindings are bound to a particular namespace  which grant users the ability to view and or edit resources within that namespace the Role provides them access to   At a cluster scope  these are called ClusterRoles and ClusterRoleBindings  Granting a user a ClusterRole grants them access to view and or edit resources across the entire cluster  It is also required to view and or edit resources at the cluster scope  namespaces  resource quotas  nodes    ClusterRoles can be bound to a particular namespace through reference in a RoleBinding  The  admin    edit  and  view  default ClusterRoles are commonly used in this manner   These are a few ClusterRoles available by default in Kubernetes  They are intended to be user facing roles  They include super user roles   cluster admin    and roles with more granular access   admin    edit    view       Default ClusterRole   Default ClusterRoleBinding   Description                                                                      cluster admin         system masters  group       Allows super user access to perform any action on any resource  When used in a ClusterRoleBinding  it gives full control over every resource in the cluster and in all namespaces  When used in a RoleBinding  it gives full control over every resource in the rolebinding s namespace  including the namespace itself     admin                None                         Allows admin access  intended to be granted within a namespace using a RoleBinding  If used in a RoleBinding  allows read write access to most resources in a namespace  including the ability to create roles and rolebindings within the namespace  It does not allow write access to resource quota or to the namespace itself     edit                 None                         Allows read write access to most objects in a namespace  It does not allow viewing or modifying roles or rolebindings     view                 None                         Allows read only access to see most objects in a namespace  It does not allow viewing roles or rolebindings  It does not allow viewing secrets  since those are escalating      Restricting a user account s access using RBAC  Now that we understand the basics of Role based Access Control  let s discuss how an administrator can restrict a user s scope of access       Example  Grant a user read write access to a particular namespace  To restrict a user s access to a particular namespace  we can use either the  edit  or the  admin  role  If your charts create or interact with Roles and Rolebindings  you ll want to use the  admin  ClusterRole   Additionally  you may also create a RoleBinding with  cluster admin  access  Granting a user  cluster admin  access at the namespace scope provides full control over every resource in the namespace  including the namespace itself   For this example  we will create a user with the  edit  Role  First  create the namespace      console   kubectl create namespace foo      Now  create a RoleBinding in that namespace  granting the user the  edit  role      console   kubectl create rolebinding sam edit       clusterrole edit          user sam          namespace foo          Example  Grant a user read write access at the cluster scope  If a user wishes to install a chart that installs cluster scope resources  namespaces  roles  custom resource definitions  etc    they will require cluster scope write access   To do that  grant the user either  admin  or  cluster admin  access   Granting a user  cluster admin  access grants them access to absolutely every resource available in Kubernetes  including node access with  kubectl drain  and other administrative tasks  It is highly recommended to consider providing the user  admin  access instead  or to create a custom ClusterRole tailored to their needs      console   kubectl create clusterrolebinding sam view       clusterrole view          user sam    kubectl create clusterrolebinding sam secret reader       clusterrole secret reader          user sam          Example  Grant a user read only access to a particular namespace  You might ve noticed that there is no ClusterRole available for viewing secrets  The  view  ClusterRole does not grant a user read access to Secrets due to escalation concerns  Helm stores release metadata as Secrets by default   In order for a user to run  helm list   they need to be able to read these secrets  For that  we will create a special  secret reader  ClusterRole   Create the file  cluster role secret reader yaml  and write the following content into the file      yaml apiVersion  rbac authorization k8s io v1  kind  ClusterRole  metadata     name  secret reader  rules     apiGroups          resources    secrets      verbs    get    watch    list        Then  create the ClusterRole using     console   kubectl create  f clusterrole secret reader yaml       Once that s done  we can grant a user read access to most resources  and then grant them read access to secrets      console   kubectl create namespace foo    kubectl create rolebinding sam view       clusterrole view          user sam          namespace foo    kubectl create rolebinding sam secret reader       clusterrole secret reader          user sam          namespace foo          Example  Grant a user read only access at the cluster scope  In certain scenarios  it may be beneficial to grant a user cluster scope access  For example  if a user wants to run the command  helm list   all namespaces   the API requires the user has cluster scope read access   To do that  grant the user both  view  and  secret reader  access as described above  but with a ClusterRoleBinding      console   kubectl create clusterrolebinding sam view       clusterrole view          user sam    kubectl create clusterrolebinding sam secret reader       clusterrole secret reader          user sam         Additional Thoughts  The examples shown above utilize the default ClusterRoles provided with Kubernetes  For more fine grained control over what resources users are granted access to  have a look at  the Kubernetes documentation  https   kubernetes io docs reference access authn authz rbac   on creating your own custom Roles and ClusterRoles


helm Explains library charts and examples of usage that defines chart primitives or definitions which can be shared by Helm title Library Charts A library chart is a type of templates in other charts This allows users to share snippets of code that can weight 4 aliases docs librarycharts

Answer:
---
title: "Library Charts"
description: "Explains library charts and examples of usage"
aliases: ["docs/library_charts/"]
weight: 4
---

A library chart is a type of [Helm chart]()
that defines chart primitives or definitions which can be shared by Helm
templates in other charts. This allows users to share snippets of code that can
be re-used across charts, avoiding repetition and keeping charts
[DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).

The library chart was introduced in Helm 3 to formally recognize common or
helper charts that have been used by chart maintainers since Helm 2. By
including it as a chart type, it provides:
- A means to explicitly distinguish between common and application charts
- Logic to prevent installation of a common chart
- No rendering of templates in a common chart which may contain release
  artifacts
- Allow for dependent charts to use the importer's context

A chart maintainer can define a common chart as a library chart and now be
confident that Helm will handle the chart in a standard consistent fashion. It
also means that definitions in an application chart can be shared by changing
the chart type.

## Create a Simple Library Chart

As mentioned previously, a library chart is a type of [Helm chart](). This means that you can start off by creating a
scaffold chart:

```console
$ helm create mylibchart
Creating mylibchart
```

You will first remove all the files in `templates` directory as we will create
our own templates definitions in this example.

```console
$ rm -rf mylibchart/templates/*
```

The values file will not be required either.

```console
$ rm -f mylibchart/values.yaml
```

Before we jump into creating common code, lets do a quick review of some
relevant Helm concepts. A [named template]() (sometimes called a partial
or a subtemplate) is simply a template defined inside of a file, and given a
name.  In the `templates/` directory, any file that begins with an underscore(_)
is not expected to output a Kubernetes manifest file. So by convention, helper
templates and partials are placed in a `_*.tpl` or `_*.yaml` files.

In this example, we will code a common ConfigMap which creates an empty
ConfigMap resource. We will define the common ConfigMap in file
`mylibchart/templates/_configmap.yaml` as follows:

```yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name:
data: {}

```

The ConfigMap construct is defined in named template `mylibchart.configmap.tpl`.
It is a simple ConfigMap with an empty resource, `data`. Within this file there
is another named template called `mylibchart.configmap`. This named template
includes another named template `mylibchart.util.merge` which will take 2 named
templates as arguments, the template calling `mylibchart.configmap` and
`mylibchart.configmap.tpl`.

The helper function `mylibchart.util.merge` is a named template in
`mylibchart/templates/_util.yaml`. It is a handy util from [The Common Helm
Helper Chart](#the-common-helm-helper-chart) because it merges the 2 templates
and overrides any common parts in both:

```yaml

```

This is important when a chart wants to use common code that it needs to
customize with its configuration.

Finally, lets change the chart type to `library`. This requires editing
`mylibchart/Chart.yaml` as follows:

```yaml
apiVersion: v2
name: mylibchart
description: A Helm chart for Kubernetes

# A chart can be either an 'application' or a 'library' chart.
#
# Application charts are a collection of templates that can be packaged into versioned archives
# to be deployed.
#
# Library charts provide useful utilities or functions for the chart developer. They're included as
# a dependency of application charts to inject those utilities and functions into the rendering
# pipeline. Library charts do not define any templates and therefore cannot be deployed.
# type: application
type: library

# This is the chart version. This version number should be incremented each time you make changes
# to the chart and its templates, including the app version.
version: 0.1.0

# This is the version number of the application being deployed. This version number should be
# incremented each time you make changes to the application and it is recommended to use it with quotes.
appVersion: "1.16.0"
```

The library chart is now ready to be shared and its ConfigMap definition to be
re-used.

Before moving on, it is worth checking if Helm recognizes the chart as a library
chart:

```console
$ helm install mylibchart mylibchart/
Error: library charts are not installable
```

## Use the Simple Library Chart

It is time to use the library chart. This means creating a scaffold chart again:

```console
$ helm create mychart
Creating mychart
```

Lets clean out the template files again as we want to create a ConfigMap only:

```console
$ rm -rf mychart/templates/*
```

When we want to create a simple ConfigMap in a Helm template, it could look
similar to the following:

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name:
data:
  myvalue: "Hello World"
```

We are however going to re-use the common code already created in `mylibchart`.
The ConfigMap can be created in the file `mychart/templates/configmap.yaml` as
follows:

```yaml

data:
  myvalue: "Hello World"

```

You can see that it simplifies the work we have to do by inheriting the common
ConfigMap definition which adds standard properties for ConfigMap. In our
template we add the configuration, in this case the data key `myvalue` and its
value. The configuration override the empty resource of the common ConfigMap.
This is feasible because of the helper function `mylibchart.util.merge` we
mentioned in the previous section.

To be able to use the common code, we need to add `mylibchart` as a dependency.
Add the following to the end of the file `mychart/Chart.yaml`:

```yaml
# My common code in my library chart
dependencies:
- name: mylibchart
  version: 0.1.0
  repository: file://../mylibchart
```

This includes the library chart as a dynamic dependency from the filesystem
which is at the same parent path as our application chart. As we are including
the library chart as a dynamic dependency, we need to run `helm dependency
update`. It will copy the library chart into your `charts/` directory.

```console
$ helm dependency update mychart/
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈Happy Helming!⎈
Saving 1 charts
Deleting outdated charts
```

We are now ready to deploy our chart. Before installing, it is worth checking
the rendered template first.

```console
$ helm install mydemo mychart/ --debug --dry-run
install.go:159: [debug] Original chart version: ""
install.go:176: [debug] CHART PATH: /root/test/helm-charts/mychart

NAME: mydemo
LAST DEPLOYED: Tue Mar  3 17:48:47 2020
NAMESPACE: default
STATUS: pending-install
REVISION: 1
TEST SUITE: None
USER-SUPPLIED VALUES:
{}

COMPUTED VALUES:
affinity: {}
fullnameOverride: ""
image:
  pullPolicy: IfNotPresent
  repository: nginx
imagePullSecrets: []
ingress:
  annotations: {}
  enabled: false
  hosts:
  - host: chart-example.local
    paths: []
  tls: []
mylibchart:
  global: {}
nameOverride: ""
nodeSelector: {}
podSecurityContext: {}
replicaCount: 1
resources: {}
securityContext: {}
service:
  port: 80
  type: ClusterIP
serviceAccount:
  annotations: {}
  create: true
  name: null
tolerations: []

HOOKS:
MANIFEST:
---
# Source: mychart/templates/configmap.yaml
apiVersion: v1
data:
  myvalue: Hello World
kind: ConfigMap
metadata:
  labels:
    app: mychart
    chart: mychart-0.1.0
    release: mydemo
  name: mychart-mydemo
```

This looks like the ConfigMap we want with data override of `myvalue: Hello
World`. Lets install it:

```console
$ helm install mydemo mychart/
NAME: mydemo
LAST DEPLOYED: Tue Mar  3 17:52:40 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
```

We can retrieve the release and see that the actual template was loaded.

```console
$ helm get manifest mydemo
---
# Source: mychart/templates/configmap.yaml
apiVersion: v1
data:
  myvalue: Hello World
kind: ConfigMap
metadata:
  labels:
    app: mychart
    chart: mychart-0.1.0
    release: mydemo
  name: mychart-mydemo
  ```

## Library Chart Benefits
Because of their inability to act as standalone charts, library charts can leverage the following functionality:
- The `.Files` object references the file paths on the parent chart, rather than the path local to the library chart
- The `.Values` object is the same as the parent chart, in contrast to application [subcharts]() which receive the section of values configured under their header in the parent.

## The Common Helm Helper Chart

```markdown
Note: The Common Helm Helper Chart repo on Github is no longer actively maintained, and the repo has been deprecated and archived.
```

This [chart](https://github.com/helm/charts/tree/master/incubator/common) was
the original pattern for common charts. It provides utilities that reflect best
practices of Kubernetes chart development. Best of all it can be used off the
bat by you when developing your charts to give you handy shared code.

Here is a quick way to use it. For more details, have a look at the
[README](https://github.com/helm/charts/blob/master/incubator/common/README.md).

Create a scaffold chart again:

```console
$ helm create demo
Creating demo
```

Lets use the common code from the helper chart. First, edit deployment
`demo/templates/deployment.yaml` as follows:

```yaml

## Define overrides for your Deployment resource here, e.g.
apiVersion: apps/v1
spec:
  replicas:
  selector:
    matchLabels:

  template:
    metadata:
      labels:

```

And now the service file, `demo/templates/service.yaml` as follows:

```yaml

## Define overrides for your Service resource here, e.g.
# metadata:
#   labels:
#     custom: label
# spec:
#   ports:
#   - port: 8080

```

These templates show how inheriting the common code from the helper chart
simplifies your coding down to your configuration or customization of the
resources.

To be able to use the common code, we need to add `common` as a dependency. Add
the following to the end of the file `demo/Chart.yaml`:

```yaml
dependencies:
- name: common
  version: "^0.0.5"
  repository: "https://charts.helm.sh/incubator/"
```

Note: You will need to add the `incubator` repo to the Helm repository list
(`helm repo add`).

As we are including the chart as a dynamic dependency, we need to run `helm
dependency update`. It will copy the helper chart into your `charts/` directory.

As helper chart is using some Helm 2 constructs, you will need to add the
following to `demo/values.yaml` to enable the `nginx` image to be loaded as this
was updated in Helm 3 scaffold chart:

```yaml
image:
  tag: 1.16.0
```

You can test that the chart templates are correct prior to deploying using the `helm lint` and `helm template` commands.

If it's good to go, deploy away using `helm install`!

title   Library Charts  description   Explains library charts and examples of usage  aliases    docs library charts    weight  4      A library chart is a type of  Helm chart    that defines chart primitives or definitions which can be shared by Helm templates in other charts  This allows users to share snippets of code that can be re used across charts  avoiding repetition and keeping charts  DRY  https   en wikipedia org wiki Don 27t repeat yourself    The library chart was introduced in Helm 3 to formally recognize common or helper charts that have been used by chart maintainers since Helm 2  By including it as a chart type  it provides    A means to explicitly distinguish between common and application charts   Logic to prevent installation of a common chart   No rendering of templates in a common chart which may contain release   artifacts   Allow for dependent charts to use the importer s context  A chart maintainer can define a common chart as a library chart and now be confident that Helm will handle the chart in a standard consistent fashion  It also means that definitions in an application chart can be shared by changing the chart type      Create a Simple Library Chart  As mentioned previously  a library chart is a type of  Helm chart     This means that you can start off by creating a scaffold chart      console   helm create mylibchart Creating mylibchart      You will first remove all the files in  templates  directory as we will create our own templates definitions in this example      console   rm  rf mylibchart templates        The values file will not be required either      console   rm  f mylibchart values yaml      Before we jump into creating common code  lets do a quick review of some relevant Helm concepts  A  named template     sometimes called a partial or a subtemplate  is simply a template defined inside of a file  and given a name   In the  templates   directory  any file that begins with an underscore    is not expected to output a Kubernetes manifest file  So by convention  helper templates and partials are placed in a     tpl  or     yaml  files   In this example  we will code a common ConfigMap which creates an empty ConfigMap resource  We will define the common ConfigMap in file  mylibchart templates  configmap yaml  as follows      yaml  apiVersion  v1 kind  ConfigMap metadata    name   data              The ConfigMap construct is defined in named template  mylibchart configmap tpl   It is a simple ConfigMap with an empty resource   data   Within this file there is another named template called  mylibchart configmap   This named template includes another named template  mylibchart util merge  which will take 2 named templates as arguments  the template calling  mylibchart configmap  and  mylibchart configmap tpl    The helper function  mylibchart util merge  is a named template in  mylibchart templates  util yaml   It is a handy util from  The Common Helm Helper Chart   the common helm helper chart  because it merges the 2 templates and overrides any common parts in both      yaml             This is important when a chart wants to use common code that it needs to customize with its configuration   Finally  lets change the chart type to  library   This requires editing  mylibchart Chart yaml  as follows      yaml apiVersion  v2 name  mylibchart description  A Helm chart for Kubernetes    A chart can be either an  application  or a  library  chart      Application charts are a collection of templates that can be packaged into versioned archives   to be deployed      Library charts provide useful utilities or functions for the chart developer  They re included as   a dependency of application charts to inject those utilities and functions into the rendering   pipeline  Library charts do not define any templates and therefore cannot be deployed    type  application type  library    This is the chart version  This version number should be incremented each time you make changes   to the chart and its templates  including the app version  version  0 1 0    This is the version number of the application being deployed  This version number should be   incremented each time you make changes to the application and it is recommended to use it with quotes  appVersion   1 16 0       The library chart is now ready to be shared and its ConfigMap definition to be re used   Before moving on  it is worth checking if Helm recognizes the chart as a library chart      console   helm install mylibchart mylibchart  Error  library charts are not installable         Use the Simple Library Chart  It is time to use the library chart  This means creating a scaffold chart again      console   helm create mychart Creating mychart      Lets clean out the template files again as we want to create a ConfigMap only      console   rm  rf mychart templates        When we want to create a simple ConfigMap in a Helm template  it could look similar to the following      yaml apiVersion  v1 kind  ConfigMap metadata    name   data    myvalue   Hello World       We are however going to re use the common code already created in  mylibchart   The ConfigMap can be created in the file  mychart templates configmap yaml  as follows      yaml   data    myvalue   Hello World        You can see that it simplifies the work we have to do by inheriting the common ConfigMap definition which adds standard properties for ConfigMap  In our template we add the configuration  in this case the data key  myvalue  and its value  The configuration override the empty resource of the common ConfigMap  This is feasible because of the helper function  mylibchart util merge  we mentioned in the previous section   To be able to use the common code  we need to add  mylibchart  as a dependency  Add the following to the end of the file  mychart Chart yaml       yaml   My common code in my library chart dependencies    name  mylibchart   version  0 1 0   repository  file      mylibchart      This includes the library chart as a dynamic dependency from the filesystem which is at the same parent path as our application chart  As we are including the library chart as a dynamic dependency  we need to run  helm dependency update   It will copy the library chart into your  charts   directory      console   helm dependency update mychart  Hang tight while we grab the latest from your chart repositories       Successfully got an update from the  stable  chart repository Update Complete   Happy Helming   Saving 1 charts Deleting outdated charts      We are now ready to deploy our chart  Before installing  it is worth checking the rendered template first      console   helm install mydemo mychart    debug   dry run install go 159   debug  Original chart version     install go 176   debug  CHART PATH   root test helm charts mychart  NAME  mydemo LAST DEPLOYED  Tue Mar  3 17 48 47 2020 NAMESPACE  default STATUS  pending install REVISION  1 TEST SUITE  None USER SUPPLIED VALUES      COMPUTED VALUES  affinity     fullnameOverride     image    pullPolicy  IfNotPresent   repository  nginx imagePullSecrets     ingress    annotations       enabled  false   hosts      host  chart example local     paths       tls     mylibchart    global     nameOverride     nodeSelector     podSecurityContext     replicaCount  1 resources     securityContext     service    port  80   type  ClusterIP serviceAccount    annotations       create  true   name  null tolerations      HOOKS  MANIFEST        Source  mychart templates configmap yaml apiVersion  v1 data    myvalue  Hello World kind  ConfigMap metadata    labels      app  mychart     chart  mychart 0 1 0     release  mydemo   name  mychart mydemo      This looks like the ConfigMap we want with data override of  myvalue  Hello World   Lets install it      console   helm install mydemo mychart  NAME  mydemo LAST DEPLOYED  Tue Mar  3 17 52 40 2020 NAMESPACE  default STATUS  deployed REVISION  1 TEST SUITE  None      We can retrieve the release and see that the actual template was loaded      console   helm get manifest mydemo       Source  mychart templates configmap yaml apiVersion  v1 data    myvalue  Hello World kind  ConfigMap metadata    labels      app  mychart     chart  mychart 0 1 0     release  mydemo   name  mychart mydemo           Library Chart Benefits Because of their inability to act as standalone charts  library charts can leverage the following functionality    The   Files  object references the file paths on the parent chart  rather than the path local to the library chart   The   Values  object is the same as the parent chart  in contrast to application  subcharts    which receive the section of values configured under their header in the parent       The Common Helm Helper Chart     markdown Note  The Common Helm Helper Chart repo on Github is no longer actively maintained  and the repo has been deprecated and archived       This  chart  https   github com helm charts tree master incubator common  was the original pattern for common charts  It provides utilities that reflect best practices of Kubernetes chart development  Best of all it can be used off the bat by you when developing your charts to give you handy shared code   Here is a quick way to use it  For more details  have a look at the  README  https   github com helm charts blob master incubator common README md    Create a scaffold chart again      console   helm create demo Creating demo      Lets use the common code from the helper chart  First  edit deployment  demo templates deployment yaml  as follows      yaml      Define overrides for your Deployment resource here  e g  apiVersion  apps v1 spec    replicas     selector      matchLabels           template      metadata        labels                  And now the service file   demo templates service yaml  as follows      yaml      Define overrides for your Service resource here  e g    metadata      labels        custom  label   spec      ports        port  8080       These templates show how inheriting the common code from the helper chart simplifies your coding down to your configuration or customization of the resources   To be able to use the common code  we need to add  common  as a dependency  Add the following to the end of the file  demo Chart yaml       yaml dependencies    name  common   version    0 0 5    repository   https   charts helm sh incubator        Note  You will need to add the  incubator  repo to the Helm repository list   helm repo add     As we are including the chart as a dynamic dependency  we need to run  helm dependency update   It will copy the helper chart into your  charts   directory   As helper chart is using some Helm 2 constructs  you will need to add the following to  demo values yaml  to enable the  nginx  image to be loaded as this was updated in Helm 3 scaffold chart      yaml image    tag  1 16 0      You can test that the chart templates are correct prior to deploying using the  helm lint  and  helm template  commands   If it s good to go  deploy away using  helm install


ingress nginx Do not move it without providing redirects https github com kubernetes ingress nginx blob main docs kubectl plugin md This file is referenced in code as NOTICE The ingress nginx kubectl plugin

NOTICE                         This file is referenced in code as https   github com kubernetes ingress nginx blob main docs kubectl plugin md Do not move it without providing redirects                                                         The ingress nginx kubectl plugin     Installation  Install  krew  https   github com GoogleContainerTools krew   then run     console kubectl krew install ingress nginx      to install the plugin  Then run     console kubectl ingress nginx   help      to make sure the plugin is properly installed and to get a list of commands      console kubectl ingress nginx   help A kubectl plugin for inspecting your ingress nginx deployments  Usage    ingress nginx  command   Available Commands    backends    Inspect the dynamic backend information of an ingress nginx instance   certs       Output the certificate data stored in an ingress nginx pod   conf        Inspect the generated nginx conf   exec        Execute a command inside an ingress nginx pod   general     Inspect the other dynamic ingress nginx information   help        Help about any command   info        Show information about the ingress nginx service   ingresses   Provide a short summary of all of the ingress definitions   lint        Inspect kubernetes resources for possible issues   logs        Get the kubernetes logs for an ingress nginx pod   ssh         ssh into a running ingress nginx pod  Flags          as string                      Username to impersonate for the operation         as group stringArray           Group to impersonate for the operation  this flag can be repeated to specify multiple groups          cache dir string               Default HTTP cache directory  default   Users alexkursell  kube http cache           certificate authority string   Path to a cert file for the certificate authority         client certificate string      Path to a client certificate file for TLS         client key string              Path to a client key file for TLS         cluster string                 The name of the kubeconfig cluster to use         context string                 The name of the kubeconfig context to use    h    help                           help for ingress nginx         insecure skip tls verify       If true  the server s certificate will not be checked for validity  This will make your HTTPS connections insecure         kubeconfig string              Path to the kubeconfig file to use for CLI requests     n    namespace string               If present  the namespace scope for this CLI request         request timeout string         The length of time to wait before giving up on a single server request  Non zero values should contain a corresponding time unit  e g  1s  2m  3h   A value of zero means don t timeout requests   default  0      s    server string                  The address and port of the Kubernetes API server         token string                   Bearer token for authentication to the API server         user string                    The name of the kubeconfig user to use  Use  ingress nginx  command    help  for more information about a command          Common Flags    Every subcommand supports the basic  kubectl  configuration flags like    namespace      context      client key  and so on    Subcommands that act on a particular  ingress nginx  pod   backends    certs    conf    exec    general    logs    ssh    support the    deployment  deployment       pod  pod    and    container  container   flags to select either a pod from a deployment with the given name  or a pod with the given name  and the given container name   The    deployment  flag defaults to  ingress nginx controller   and the    container  flag defaults to  controller     Subcommands that inspect resources   ingresses    lint   support the    all namespaces  flag  which causes them to inspect resources in every namespace      Subcommands  Note that  backends    general    certs   and  conf  require  ingress nginx  version  0 23 0  or higher       backends  Run  kubectl ingress nginx backends  to get a JSON array of the backends that an ingress nginx controller currently knows about      console   kubectl ingress nginx backends  n ingress nginx            name    default apple service 5678        service            metadata              creationTimestamp   null                 spec              ports                              protocol    TCP                port   5678               targetPort   5678                                 selector                app    apple                      clusterIP    10 97 230 121            type    ClusterIP            sessionAffinity    None                  status              loadBalancer                          port   0       sslPassthrough   false       endpoints                      address    10 1 3 86            port    5678                      sessionAffinityConfig            name              cookieSessionAffinity              name                          upstreamHashByConfig            upstream hash by subset size   3             noServer   false       trafficShapingPolicy            weight   0         header              headerValue              cookie                          name    default echo service 8080                         name    upstream default backend                      Add the    list  option to show only the backend names  Add the    backend  backend   option to show only the backend with the given name       certs  Use  kubectl ingress nginx certs   host  hostname   to dump the SSL cert key information for a given host     WARNING    This command will dump sensitive private key information  Don t blindly share the output  and certainly don t log it anywhere      console   kubectl ingress nginx certs  n ingress nginx   host testaddr local      BEGIN CERTIFICATE               END CERTIFICATE           BEGIN CERTIFICATE               END CERTIFICATE            BEGIN RSA PRIVATE KEY       REDACTED  DO NOT SHARE THIS        END RSA PRIVATE KEY               conf  Use  kubectl ingress nginx conf  to dump the generated  nginx conf  file  Add the    host  hostname   option to view only the server block for that host      console kubectl ingress nginx conf  n ingress nginx   host testaddr local   server     server name testaddr local      listen 80     set  proxy upstream name        set  pass access scheme  scheme    set  pass server port  server port    set  best http host  http host    set  pass port  pass server port     location         set  namespace             set  ingress name          set  service name          set  service port    0      set  location path                     exec   kubectl ingress nginx exec  is exactly the same as  kubectl exec   with the same command flags  It will automatically choose an  ingress nginx  pod to run the command in      console   kubectl ingress nginx exec  i  n ingress nginx    ls  etc nginx fastcgi params geoip lua mime types modsecurity modules nginx conf opentracing json opentelemetry toml owasp modsecurity crs template          info  Shows the internal and external IP CNAMES for an  ingress nginx  service      console   kubectl ingress nginx info  n ingress nginx Service cluster IP address  10 187 253 31 LoadBalancer IP CNAME  35 123 123 123      Use the    service  service   flag if your  ingress nginx   LoadBalancer  service is not named  ingress nginx        ingresses   kubectl ingress nginx ingresses   alternately  kubectl ingress nginx ing   shows a more detailed view of the ingress definitions in a namespace   Compare      console   kubectl get ingresses   all namespaces NAMESPACE   NAME               HOSTS                            ADDRESS     PORTS   AGE default     example ingress1   testaddr local testaddr2 local   localhost   80      5d default     test ingress 2                                      localhost   80      5d      vs      console   kubectl ingress nginx ingresses   all namespaces NAMESPACE   INGRESS NAME       HOST PATH                        ADDRESSES   TLS   SERVICE         SERVICE PORT   ENDPOINTS default     example ingress1   testaddr local etameta           localhost   NO    pear service    5678           5 default     example ingress1   testaddr2 local otherpath        localhost   NO    apple service   5678           1 default     example ingress1   testaddr2 local otherotherpath   localhost   NO    pear service    5678           5 default     test ingress 2                                      localhost   NO    echo service    8080           2          lint   kubectl ingress nginx lint  can check a namespace or entire cluster for potential configuration issues  This command is especially useful when upgrading between  ingress nginx  versions      console   kubectl ingress nginx lint   all namespaces   verbose Checking ingresses      anamespace this nginx     Contains the removed session cookie hash annotation         Lint added for version 0 24 0        https   github com kubernetes ingress nginx issues 3743   othernamespace ingress definition blah     The rewrite target annotation value does not reference a capture group       Lint added for version 0 22 0       https   github com kubernetes ingress nginx issues 3174  Checking deployments      namespace2 ingress nginx controller     Uses removed config flag   sort backends       Lint added for version 0 22 0       https   github com kubernetes ingress nginx issues 3655     Uses removed config flag   enable dynamic certificates       Lint added for version 0 24 0       https   github com kubernetes ingress nginx issues 3808      To show the lints added   only   for a particular  ingress nginx  release  use the    from version  and    to version  flags      console   kubectl ingress nginx lint   all namespaces   verbose   from version 0 24 0   to version 0 24 0 Checking ingresses      anamespace this nginx     Contains the removed session cookie hash annotation         Lint added for version 0 24 0        https   github com kubernetes ingress nginx issues 3743  Checking deployments      namespace2 ingress nginx controller     Uses removed config flag   enable dynamic certificates       Lint added for version 0 24 0       https   github com kubernetes ingress nginx issues 3808          logs   kubectl ingress nginx logs  is almost the same as  kubectl logs   with fewer flags  It will automatically choose an  ingress nginx  pod to read logs from      console   kubectl ingress nginx logs  n ingress nginx                                                                                NGINX Ingress controller   Release     dev   Build       git 48dc3a867   Repository  git github com kubernetes ingress nginx git                                                                                W0405 16 53 46 061589       7 flags go 214  SSL certificate chain completion is disabled    enable ssl chain completion false  nginx version  nginx 1 15 9 W0405 16 53 46 070093       7 client config go 549  Neither   kubeconfig nor   master was specified   Using the inClusterConfig   This might not work  I0405 16 53 46 070499       7 main go 205  Creating API client for https   10 96 0 1 443 I0405 16 53 46 077784       7 main go 249  Running in Kubernetes cluster version v1 10  v1 10 11    git  clean  commit 637c7e288581ee40ab4ca210618a89a555b6e7e9   platform linux amd64 I0405 16 53 46 183359       7 nginx go 265  Starting NGINX Ingress controller I0405 16 53 46 193913       7 event go 209  Event v1 ObjectReference Kind  ConfigMap   Namespace  ingress nginx   Name  udp services   UID  82258915 563e 11e9 9c52 025000000001   APIVersion  v1   ResourceVersion  494   FieldPath       type   Normal  reason   CREATE  ConfigMap ingress nginx udp services              ssh   kubectl ingress nginx ssh  is exactly the same as  kubectl ingress nginx exec  it     bin bash   Use it when you want to quickly be dropped into a shell inside a running  ingress nginx  container      console   kubectl ingress nginx ssh  n ingress nginx www data ingress nginx controller 7cbf77c976 wx5pn  etc nginx