Also at Deasil Works · txn2 · Plexara
Profiles GitHub · X · LinkedIn
Theme Light · Auto · Dark
imti.co
Professional notes by Craig Johnston
long-form, short-form, working drafts · since 2008
VOL. XIX · MMXXVI
81 NOTES IN PRINT
FOLIO XVI 17 MAY 2018 · 3 MIN · SHORT-FORM

Helm on Custom Kubernetes

Kubernetes package management.

Diagram · folio xvi
mindmap
  root((Helm))
    Concepts
      Chart
      Release
      Repository
      Values
    Lifecycle
      install
      upgrade
      rollback
      uninstall
    Chart structure
      Chart yaml
      values yaml
      templates folder
      charts subfolder
    Common operations
      helm repo add
      helm install
      helm upgrade
      helm list
      helm uninstall

Helm is the de facto package manager for Kubernetes. If you are looking to start using Helm or want to test its capabilities, I suggest you set up a Production Hobby Cluster. This article is a continuation of the Production Hobby Cluster configuration but should be entirely useful on its own.

From https://github.com/kubernetes/helm

  • Helm has two parts: a client (helm) and a server (tiller)
  • Tiller runs inside of your Kubernetes cluster and manages releases (installations) of your charts.
  • Helm runs on your laptop, CI/CD, or wherever you want it to run.
  • Charts are Helm packages that contain at least two things:
  • A description of the package (Chart.yaml)
  • One or more templates, which contain Kubernetes manifest files
  • Charts can be stored on disk, or fetched from remote chart repositories (like Debian or RedHat packages)

Start with installing Helm on your local workstation. Read the Helm installation instructions or merely follow along below.

# on MacOS using homebrew (http://brew.sh)
brew install kubernetes-helm

# on windows using https://chocolatey.org/
choco install kubernetes-helm

Since our Production Hobby Cluster uses RBAC Roles, we start by adding a ServiceAccount called tiller. Tiller is Kubernetes service that manages Helm installs on the cluster.

The following configuration creates a ServiceAccount named tiller and a ClusterRoleBinding between the new tiller account and the cluster-admin role. Of course, you can define your own Role and permissions, however, the cluster-admin role has admin access, and that is what we want for a Production Hobby Cluster. Permissions can always become more restrictive in the future should our hobby become more sophisticated.

You can apply the configuration with the following command:

kubectl create -f https://gist.githubusercontent.com/cjimti/9fab60c0b21a97cbe15688f5e28d940f/raw/29cbeff70bc528e5212ebc3f63e08fb5a24d5ecd/00-tiller-rbac.yml

Next initialize Helm while specifying the ServiceAccount to use. Use the new tiller ServiceAccount we setup above.

helm init --service-account tiller

To see what Helm just installed on your cluster run:

kubectl get all -l app=helm -n kube-system

As this point you can see a Deployment, a ReplicaSet, a Pod and a Service named tiller-deploy in the kube-system namespace.

If in a few days you find yourself setting up a cluster in Japan or Germany on Linode, and another two in Australia and France on vultr, then you may have just joined the PHC (Performance Hobby Clusters) club. Some people tinker late at night on their truck, we benchmark and test the resilience of node failures on our overseas, budget kubernetes clusters. It’s all about going big, on the cheap.

k8s performance hobby clusters

§Port Forwarding / Local Development

Check out kubefwd for a simple command line utility that bulk forwards services of one or more namespaces to your local workstation.

§Resources

· 17 May 2018 ← back to all notes