Kubernetes Configuration Manager — Helm

For example, to deploy the Nginx-alpine application 4 resource manifests were necessary: Namespace, Deployment, Service, and Configmap. However, this suite of manifests represents the deployment to a single environment, e.g sandbox. The application should be propagated through staging and production environment, which reference a separate set of manifests. It is essential to ensure that the application configuration is tailored for each environment, such as allocating more CPU and memory to the application in production since it handles more traffic or has a different number of replicas for each cluster. In this case, an engineering team ends up managing 3 sets of manifests, 1 for each cluster.

However, the number of manifests grows exponentially when the application is distributed across multiple regions. As such, if the application is released in AP(Asia Pacific) and the US, a team ends up managing 9 different sets of manifests.

To Solve the challenge to manage multiple manifests we can take the help of Configuration Management tools like Helm

Helm is a package manager, that manages Kubernetes configuration with Charts. A Helm chart is a collection of YAML files that describe the state of multiple Kubernetes resources. These files can be parametrized using the Go template.

Pre-Configuration:

  1. Kubernetes Cluster
  2. Helm

Helm Chart

A Helm chart is composed of the following files:

.
├── Chart.yaml
├── templates
│ ├── configmap.yaml
│ ├── deployment.yaml
│ ├── namespace.yaml
│ └── service.yaml
├── values-prod.yaml
├── values-staging.yaml
└── values.yaml
  • Chart.yaml — expose chart details, such as description, version, and dependencies
  • templates/ folder — contains templates YAML manifests for Kubernetes resources
  • values.yaml — default input configuration file for the chart. If no other values file is supplied, the parameters in this file will be used.

Chart.yaml

A Chart.yaml file contains the apiVersion, description, description, version, and maintainer details.

Let’s take this as an example we are going to deploy Nginx deployment on Kubernetes with Helm

apiVersion: v1
name: nginx-deployment
description: Install Nginx deployment manifests
keywords:
- nginx
version: 1.0.0
maintainers:
- name: siva naik
email: sivanaikk0903@gmail.com
  • version is the version of the Chart

templates directory

The templates directory contains the templated manifest files of Kubernetes resources. The template files expect the input, we pass inputs with values files

templates/
├── configmap.yaml
├── deployment.yaml
├── namespace.yaml
└── service.yaml
  • configmap.yaml is contains the manifest to create a config map
apiVersion: v1
data:
{{ .Values.configmap.data }}
#version: alpine
kind: ConfigMap
metadata:
name: nginx-version
namespace: {{ .Values.namespace.name }}

The values in {{ .. }} syntax are the variables. we have to give the reference of variables present in values.yaml file

The Value for the variable namespace is from the file under the namespace block as the name. These manifests can be templated using Go template. For example, instead of hardcoding the name of the Namespace, it can be parameterized as follows:

namespace: {{ .Values.namespace.name }}
  • namespace.yaml

Namespace file contains the manifest for Kubernetes namespace for Nginx.

apiVersion: v1
kind: Namespace
metadata:
labels:
tier: test
name: {{ .Values.namespace.name }}
  • service.yaml

This file contains the manifest to create a service in Kubernetes

apiVersion: v1
kind: Service
metadata:
labels:
app: nginx
tag: alpine
name: nginx-alpine
namespace: {{ .Values.namespace.name }}
spec:
ports:
- port: {{ .Values.service.port }}
protocol: TCP
targetPort: {{ .Values.service.port }}
selector:
app: nginx
tag: alpine
type: {{ .Values.service.type }}
  • deployment.yaml

This file has the manifest to create Nginx deployment

apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
tag: alpine
name: nginx-alpine
namespace: {{ .Values.namespace.name }}
spec:
replicas: {{ .Values.replicaCount }}
selector:
matchLabels:
app: nginx
tag: alpine
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
labels:
app: nginx
tag: alpine
spec:
containers:
- image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
imagePullPolicy: {{ .Values.image.pullPolicy }}
name: nginx-alpine
resources:
{{ toYaml .Values.resources | indent 12 }}

values.yaml file

The values.yaml file contains default input parameters for a Helm chart. The parameters are consumed by the templated YAML manifests through the .Values object.

We can use multiple values files to pass as arguments based on the environment where we are going to deploy. Let’s say sandbox, stagging, and production.

  • values.yaml
namespace:
name: demo
service:
port: 8111
type: ClusterIP
image:
repository: nginx
tag: alpine
pullPolicy: IfNotPresent
replicaCount: 3
resources:
requests:
cpu: 50m
memory: 256Mi
configmap:
data: "version: alpine"
  • values-staging
namespace:
name: staging
service:
port: 8111
type: ClusterIP
image:
repository: nginx
tag: 1.18.0
pullPolicy: IfNotPresent
replicaCount: 1
resources:
requests:
cpu: 50m
memory: 128Mi
configmap:
data: "version: 1.18.0"
  • values-prod.yaml
namespace:
name: prod
service:
port: 80
type: ClusterIP
image:
repository: nginx
tag: 1.17.0
pullPolicy: IfNotPresent
replicaCount: 2
resources:
requests:
cpu: 70m
memory: 256Mi
configmap:
data: "version: 1.17.0"

The values files have different values based on the environment in the resource are deployed

Let’s Install the Helm chart we created

helm install  [name]  [ helm chart path ]
  • list installed helm charts
helm list

Thank you!

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store