Write Helm Charts

Helm charts are the fundamental building blocks of Helm, acting as the blueprints for deploying applications in Kubernetes. A Helm chart packages together all the resources, configurations, and dependencies required to run an application or service on a Kubernetes cluster. Understanding the structure and components of a Helm chart is essential for effectively using Helm to deploy and manage applications. In this lesson, we’ll explore the anatomy of a Helm chart, dissect its key components, and lay the groundwork for creating, customizing, and deploying your own charts.

2.1.1 What is a Helm Chart?

A Helm chart is a collection of files that describe a set of Kubernetes resources. It serves as a template that defines how to deploy an application or service, including all the necessary Kubernetes objects, such as Pods, Services, ConfigMaps, and more. Charts are reusable, versioned, and can be customized to suit different deployment environments (e.g., development, staging, production).

Key Characteristics of Helm Charts:

• Reusable: Helm charts can be used to deploy the same application across different environments with consistent configurations.

• Versioned: Each chart has a version number, allowing you to track changes and manage upgrades.

• Configurable: Charts include default configurations, which can be overridden to customize deployments.

2.1.2 Anatomy of a Helm Chart

A typical Helm chart follows a well-defined directory structure, with each file serving a specific purpose. Let’s break down the key components of a Helm chart:

2.1.2.1 Chart.yaml

The Chart.yaml file is the metadata file for the Helm chart. It contains important information about the chart, such as its name, version, and description. This file is essential for identifying and managing the chart.

Example Chart.yaml:

yamlCopy codeapiVersion: v2
name: myapp
description: A Helm chart for Kubernetes
type: application
version: 1.0.0
appVersion: 1.16.0

• apiVersion: Specifies the API version of the Helm chart (e.g., v1, v2).

• name: The name of the chart.

• description: A brief description of what the chart does.

• type: The type of chart (e.g., application, library).

• version: The chart’s version number.

• appVersion: The version of the application being deployed.

2.1.2.2 values.yaml

The values.yaml file defines the default configuration values for the chart. These values can be overridden by the user during the installation or upgrade process, allowing for flexible and customizable deployments.

Example values.yaml:

yamlCopy codereplicaCount: 2
image:
  repository: nginx
  tag: 1.16.0
  pullPolicy: IfNotPresent
service:
  type: ClusterIP
  port: 80

• replicaCount: The number of replicas for the application’s Deployment.

• image: Configuration for the Docker image, including the repository, tag, and pull policy.

• service: Configuration for the Kubernetes Service, including the type and port.

2.1.2.3 templates/ Directory

The templates/ directory contains the Go templates that are rendered to create Kubernetes resource files. These templates are processed by Helm, using the values defined in values.yaml or provided by the user, to generate the final Kubernetes manifests.

Common Templates:

• deployment.yaml: Defines a Kubernetes Deployment resource.

• service.yaml: Defines a Kubernetes Service resource.

• configmap.yaml: Defines a Kubernetes ConfigMap resource.

Example deployment.yaml Template:

yamlCopy codeapiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-deployment
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Release.Name }}
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}
    spec:
      containers:
      - name: {{ .Release.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        ports:
        - containerPort: 80

• .Release.Name: A built-in template function that provides the name of the Helm release.

• .Values.replicaCount: Refers to the replicaCount value in values.yaml.

• .Values.image.repository and .Values.image.tag: Refer to the image repository and tag defined in values.yaml.

2.1.2.4 charts/ Directory

The charts/ directory is where any dependencies for your chart are stored. If your application relies on other Helm charts (sub-charts), they are included in this directory. This allows for modular and composable chart design, where complex applications can be built from smaller, reusable components.

2.1.2.5 README.md

The README.md file is a markdown file that provides documentation for the chart. It typically includes information on how to install, configure, and use the chart. This is not a mandatory file but is highly recommended, especially for public charts, to help users understand how to use the chart effectively.

2.1.3 How Helm Charts Work

When you install a Helm chart, Helm processes the templates in the templates/ directory, substituting the values from values.yaml (or those provided by the user) into the templates. The rendered templates are then sent to the Kubernetes API to create the corresponding resources in the cluster.

Steps in a Helm Chart Installation:

1. Rendering Templates: Helm takes the templates from the chart and renders them using the values from values.yaml.

2. Interacting with Kubernetes: The rendered templates are converted into Kubernetes manifests (YAML files) and sent to the Kubernetes API server.

3. Creating Resources: Kubernetes processes these manifests to create the specified resources (e.g., Pods, Services, ConfigMaps).

Example:

When you install a Helm chart for an Nginx server, Helm will:

• Render the templates to create a Deployment, Service, and any other required resources.

• Send these resources to the Kubernetes cluster to be created.

• Track the installation as a "release," which can be managed (upgraded, rolled back, etc.) using Helm.