kubernetes helm - ghdrako/doc_snipets GitHub Wiki

Helm is similar to package manager in example dnf. A Helm chart can be thought of as a Kubernetes package. Charts contain the declarative Kubernetes resource files required to deploy an application. Similar to an RPM package, it can also declare one or more dependencies that the application needs in order to run.

Helm relies on repositories to provide widespread access to charts. Chart developers create declarative YAML files, package them into charts, and publish them to chart repositories. End users then use Helm to search for existing charts to deploy onto Kubernetes, similar to how end users of dnf will search for RPM packages to deploy to Fedora.

Helm Chart Repository

Run Chart

helm install [NAME] [CHART] [flags]
  • The NAME parameter is the name you would like to give your Helm release. A release captures the Kubernetes resources that were installed with a chart and tracks an application’s life cycle. We will explore how releases work throughout this chapter.
  • The CHART parameter is the name of the Helm chart that is installed. Charts from a repository can be installed using /.
  • The flags option in helm install allows you to further customize the installation. flags allows users to define and override values, specify the namespace to work against, and more.

List parameters

helm show values bitnami/wordpress --version 12.1.6

Create file with modified parameters

$cat wordpress-values.yaml
wordpressUsername: helm-user
wordpressPassword: my-password
wordpressEmail: [email protected]
wordpressFirstName: Helm_is
wordpressLastName: Fun
wordpressBlogName: Learn Helm!
service:
type: NodePort

Run installation

$ helm install wordpress bitnami/wordpress --values=wordpress-
values.yaml --namespace chapter3 --version 12.1.6

Get a list of the Kubernetes resources that were created as part of the installation

$ helm get manifest wordpress --namespace chapter3

view the list of releases in the chapter3 namespace:

$ helm list --namespace chapter3

helm install redis bitnami/redis --namespace=redis
helm upgrade redis bitnami/redis --namespace=redis
helm rollback redis 1 --namespace=redis
helm uninstall redis --namespace=redis

$ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
$ helm install stable/prometheus

The basic configuration item in Helm is the chart. A template that consists of a Kubernetes application that is used by Helm, is called a chart. The chart has a standard file and directory structure, shown next. You can use the $ helm create command to create this structure:

mychartname/
|
|- .helmignore
|
|- Chart.yaml
|
|- values.yaml
|
|- charts/
|
|- templates/
  • The .helmignore file works like a .gitignore file and specifies files or directories to be ignored by the Helm command.
  • The Chart.yaml file holds metadata about the chart you are packaging, such as your version of the chart itself.
  • The values.yaml file stores any values used for the deployment. You will normally see one file, the default values, but multiple value files can be used for different environments.
  • The charts directory is used to store other charts that your chart may depend on.
  • The templates directory holds the actual manifest you have created to support the deployment of your application. This may consist of multiple YAML files to deploy pods, config maps, secrets, and so on.

Values are transposed into the chart using the {{ define }} directive, which means the templates are significantly more flexible than standard Kubernetes manifests. What follows is an example of Helm manifest that shows a resource, in this case, a ConfigMap can be modified:

apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Release.Name }}-configmap
data:
myvalue: "Hello World"

In this example, the name of the ConfigMap will be a combination of Release.Name and the -configmap string. For example, if your chart name is CM1, the resulting ConfigMap will be named CM1-configmap.

Install binnary

$ curl -L https://git.io/get_helm.sh | bash -s -- --version v3.8.2

Install helm Nginx ingress

$ helm repo add nginx-stable
$ helm repo update
$ helm search repo nginx-stable
$ helm install my-release nginx-stable/nginx-ingress
$ helm list
$ helm history my-release
kubectl api-resources --verbs=list -o name | xargs -n 1 kubectl get --show-kind -l

Creating own chart

$ helm create myhelmchart
$ helm install example ./myhelmchart --set service.type=NodePort
$ kubectl api-resources --verbs=list -o name | xargs -n 1 kubectl get --show-kind -l

Manage own chart

  • modify values.yaml
  • modify Chart.yaml - update version
  • validate chane: $ helm lint
  • roll out the changes $ helm upgrade example ./myhelmchart
  • validate the deployment: $ helm history example
  • show history helm history example
  • rollback to previous revision helm rollback example 1
  • show all the revisions in the cluster helm list
  • helm uninstall example

Configuring declarative resources in a dynamic fashion

Values can be thought of as parameters for charts. Templates are dynamically generated files based on a given set of values. These two constructs give chart developers the ability to write Kubernetes resources that are generated based on values that end users provide.

Values and templates allow users to do things such as this:

  • Parameterize common fields, such as the image name in a deployment and the ports in a service.
  • Generate long pieces of YAML configuration based on user input, such as volume mounts in a deployment or the data in a ConfigMap.
  • Include or exclude resources based on user input. The ability to dynamically generate declarative resource files makes it simpler to create YAML-based resources while still ensuring that applications are deployed in an easily reproducible fashion.

Using Helm’s values construct, users can provide configuration changes across an application’s life cycle by managing a small number of parameters instead of multiple full-length YAML resources. When the local state (values/parameters) is updated, Helm propagates the configuration change out to the relevant resources in Kubernetes. This workflow keeps Helm in control of managing intricate Kubernetes details and encourages users to manage the state locally instead of updating live resources directly.

Helm simplifies application deployments by having a pre-determined order in which Kubernetes resources need to be created. This ordering exists to ensure that dependent resources are deployed first. For example, Secret instances and ConfigMap instances should be created before deployments, since a deployment would likely consume those resources as volumes. Helm performs this ordering without any interaction from the user, so this complexity is abstracted and prevents users from needing to understand the order in which resources should be applied.

⚠️ **GitHub.com Fallback** ⚠️