Kubernetes Configuration Manager - Helm

Challenge

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: [email protected]        

• 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!