Cloud Native OCI

Helm

🖨️

Created with ❤ by Oracle A-Team

Helm

Helm is one the best ways to find, share, and use software built for Kubernetes.

Why use Helm.

Create new charts from scratch
Package charts into chart archive (tgz) files
Interact with chart repositories where charts are stored
Install and uninstall charts into an existing Kubernetes cluster
Manage the release cycle of charts that have been installed with Helm

Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on.

Helm renders your templates and communicates with the Kubernetes API
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)

Concepts in Helm

The chart is a bundle of information necessary, like templates for kubernetes manifests, to create an instance of a Kubernetes application.
The config contains configuration information that can be merged into a packaged chart to create a releasable object.
A release is a running instance of a chart, combined with a specific config.

Creating a Helm chart


helm create mychart

Examine the files created by helm for your starter helm chart.


cd mychart
ls -ltr
ls -ltr templates
cat templates/deployment.yaml
cat values.yaml

Installing a Helm chart

The default chart is real and usable, it sets up an nginx deployment. Lets install it.


cd ..
helm install mychart ./mychart/ --set service.port=$RANDOM

The chart is installed, using the configuration provided in the values.yaml that was included in the chart.

A single value - service.port has been overridden using the --set flag.
A separate yaml file containing just the overrides can be provided as well, using the -f flag.

Using Helm charts


    helm list

The release is running nginx, but uses ClusterIP, meaning the service is only available within the cluster. Can we test it ?


helm status mychart

Get the service IP and port

      
kubectl get svc

How can we connect to this IP that is only valid within the cluster ? Perhaps if we had a shell that was inside the cluster ? Running as another pod ?


kubectl run -i --rm --tty debug --image=busybox --restart=Never -- sh

We create a second pod, thats in the the same cluster, and is hence visible to the other pods. From within this pod, the ClusterIPs are visible.


wget -O- [service_ip]:[service_port]