Installation

1. Creating a Kubernetes cluster (1.6+ & RBAC)

Using kubectl config current-context or kubectl cluster-info for verification. (GCP k8s cluster)

1. Security
2. Helm(client) and Tiller(cluster side)

rbac-config.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: tiller
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tiller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: tiller
    namespace: kube-system

kubectl create -f rbac-config.yaml

helm init --service-account tiller --history-max 200

helm init --upgrade

helm repo update

helm install stable/mysql

Whenever you install a chart, a new release is created. So one chart can be installed multiple times into the same cluster. And each can be independently managed and upgraded.

helm ls

Pillars

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.

Search

helm search mysql

Customizing

helm inspect values stable/mariadb

$ cat << EOF > config.yaml
mariadbUser: user0
mariadbDatabase: user0db
EOF
$ helm install -f config.yaml stable/mariadb

Install

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)

There are five different ways you can express the chart you want to install:

1. By chart reference: helm install stable/mariadb
2. By path to a packaged chart: helm install ./nginx-1.2.3.tgz
3. By path to an unpacked chart directory: helm install ./nginx
4. By absolute URL: helm install https://example.com/charts/nginx-1.2.3.tgz
5. By chart reference and repo url: helm install –repo https://example.com/charts/ nginx

Upgrade

helm upgrade -f panda.yaml happy-panda stable/mariadb

Rollback

helm rollback happy-panda 1

Delete

helm delete happy-panda

List

helm list --all

Repo

helm repo list

helm repo add dev https://example.com/dev-charts
helm repo update

Creation

helm create deis-workflow

Package

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

Dependency

Helm charts store their dependencies in ‘charts/’. For chart developers, it is often easier to manage a single dependency file (‘requirements.yaml’) which declares all dependencies.

# requirements.yaml
dependencies:
- name: nginx
  version: "1.2.3"
  repository: "https://example.com/charts"
- name: memcached
  version: "3.2.1"
  repository: "https://another.example.com/charts"

# requirements.yaml
dependencies:
- name: nginx
  version: "1.2.3"
  repository: "file://../dependency-chart/nginx"

helm dependency build [flags] CHART

helm dependency list [flags] CHART

helm dependency update [flags] CHART

Inspect

Inspect prints the contents of the Chart.yaml file and the values.yaml file.

helm inspect [CHART] [flags]

Uninstall

Uninstalls Tiller from a cluster

helm reset [flags]

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.

Charts

Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources.

Charts are created as files laid out in a particular directory tree, then they can be packaged into versioned archives to be deployed.

A chart is organized as a collection of files inside of a directory. The directory name is the name of the chart (without versioning information). Thus, a chart describing WordPress would be stored in the wordpress/ directory.

TEMPLATES AND VALUES

All template files are stored in a chart’s templates/ folder. When Helm renders the charts, it will pass every file in that directory through the template engine.

Values for the templates are supplied two ways:

• Chart developers may supply a file called values.yaml inside of a chart. This file can contain default values.

• Chart users may supply a YAML file that contains values. This can be provided on the command line with helm install.

When a user supplies custom values, these values will override the values in the chart’s values.yaml file.

Draft

USING THE ‘REQUIRED’ FUNCTION

The above will render the template when .Values.foo is defined, but will fail to render and exit when .Values.foo is undefined.

Debugging Commands

helm install ./mychart --debug --dry-run

Using –dry-run will make it easier to test your code, but it won’t ensure that Kubernetes itself will accept the templates you generate. It’s best not to assume that your chart will install just because –dry-run works.

helm lint is your go-to tool for verifying that your chart follows best practices

helm install --dry-run --debug: We’ve seen this trick already. It’s a great way to have the server render your templates, then return the resulting manifest file.

helm get manifest: This is a good way to see what templates are installed on the server.

Golang Template

• Previous
  Programming With Google Go
• Next
  Golang Low Level Programming