Helm

https://docs.helm.sh/using%5Fhelm/#using-helm https://docs.helm.sh/chart%5Ftemplate%5Fguide/

1 THREE BIG CONCEPTS:

A Chart is a Helm package. It contains all of the resource definitions necessary to run an application, tool, or service inside of a Kubernetes cluster. Think of it like the Kubernetes equivalent of a Homebrew formula, an Apt dpkg, or a Yum RPM file.

A Repository is the place where charts can be collected and shared. It’s like Perl’s CPAN archive or the Fedora Package Database, but for Kubernetes packages.

A Release is an instance of a chart running in a Kubernetes cluster. One chart can often be installed many times into the same cluster. And each time it is installed, a new release is created. Consider a MySQL chart. If you want two databases running in your cluster, you can install that chart twice. Each one will have its own release, which will in turn have its own release name.

With these concepts in mind, we can now explain Helm like this:

Helm installs charts into Kubernetes, creating a new release for each installation. And to find new charts, you can search Helm chart repositories.

2 Commands

2.1 ‘helm init’: Install Tiller into Kubernetes cluster

2.2 ‘helm search’: FINDING CHARTS

2.3 ‘helm install’: INSTALLING A PACKAGE

(If you want to use your own release name, simply use the –name flag on helm install.)

2.4 Customizing the Chart Before Installing

Installing the way we have here will only use the default configuration options for this chart. Many times, you will want to customize the chart to use your preferred configuration.

To see what options are configurable on a chart, use ‘‘‘helm inspect values’'':

2.5 More Installation Methods

The helm install command can install from several sources:

A chart repository (as we’ve seen above) A local chart archive (helm install foo-0.1.1.tgz) An unpacked chart directory (helm install path/to/foo) A full URL (helm install https://example.com/charts/foo-1.2.3.tgz)

2.6 ‘helm upgrade’ AND ‘helm rollback’: UPGRADING A RELEASE, AND RECOVERING ON FAILURE

2.7 ‘helm delete’: DELETING A RELEASE

2.8 ‘helm repo’: WORKING WITH REPOSITORIES

3 CREATING YOUR OWN CHARTS

$ helm create deis-workflow $ helm package deis-workflow $ helm install ./deis-workflow-0.1.0.tgz

4 TILLER, NAMESPACES AND RBAC

In some cases you may wish to scope Tiller or deploy multiple Tillers to a single cluster. Here are some best practices when operating in those circumstances.

  1. Tiller can be installed into any namespace. By default, it is installed into kube-system. You can run multiple Tillers provided they each run in their own namespace.

  2. Limiting Tiller to only be able to install into specific namespaces and/or resource types is controlled by Kubernetes RBAC roles and rolebindings. You can add a service account to Tiller when configuring Helm via helm init –service-account . You can find more information about that here.

  3. Release names are unique PER TILLER INSTANCE.

  4. Charts should only contain resources that exist in a single namespace.

  5. It is not recommended to have multiple Tillers configured to manage resources in the same namespace.

5 configmap & security

ConfigMap for non-sensitive data

In the Deployment manifest, each entry within data appears within the container as an environment variable with the same name and the associated value, via envFrom. As all environment variables in the Deployment manifest must be strings, we have to quote any ambiguous values that could be inferred as another value type.

PORT: “4000”

CONDTIONAL_VARS: “true”


© 2015-2020 tendant