Forem: Manjunath Kotabal

Packaging and Installing Helm Chart with ArgoCD

Manjunath Kotabal — Sun, 26 Jan 2025 07:30:27 +0000

In the previous blog, we discussed building deployment-ready Helm charts by creating common Kubernetes resources such as Deployment, Ingress, ConfigMap, Secrets, and Service. We also explored customizing Helm chart templates and creating reusable helpers to make charts production-ready.

In this blog, we will dive into:

Packaging and sharing Helm charts.
CI/CD integration with ArgoCD.
Best practices for storing and managing Helm charts.
Deploying Helm charts using ArgoCD by creating an application definition.

Packaging and Sharing Helm Charts

After creating a Helm chart, the next step is to package and distribute it. Helm provides a simple way to package charts into a .tgz archive for easy sharing and deployment.

Packaging a Helm Chart

Run the following command to package your Helm chart:

helm package myapp

This will generate a file like myapp-1.0.0.tgz, depending on the version specified in your Chart.yaml.

Storing Helm Charts

Once packaged, Helm charts can be stored in various locations for easy access and deployment. Here are the most common options:

1. OCI (Open Container Initiative) Registry

OCI registries like AWS Elastic Container Registry (ECR) or Docker Hub allow you to store Helm charts in a container-like repository.

Example: Storing a Helm Chart in AWS ECR

aws ecr get-login-password --region us-west-2 | \
helm registry login --username AWS --password-stdin 123456789012.dkr.ecr.us-west-2.amazonaws.com

helm push my-chart-1.0.0.tgz oci://123456789012.dkr.ecr.us-west-2.amazonaws.com/

2. Chart Repositories

Tools like ChartMuseum or public Helm repositories such as Artifact Hub provide an easy way to host and share Helm charts.

3. Git Repositories

Storing charts in Git alongside your application code allows for:

Version control: Track changes and manage different versions of your Helm charts effectively.
Easy collaboration and updates: Team members can contribute and review changes seamlessly.
Integration with CI/CD pipelines: Automate the deployment and update process using CI/CD tools.

4. Self-Hosted Solutions

You can host your Helm charts on a web server or object storage (e.g., AWS S3) by generating an index.yaml file. Use the following command to create the index file:

helm repo index /path/to/helm-charts --url https://example.com/charts/

Upload the charts and the index.yaml file to your hosting service, and your repository is ready for use!

CI/CD Integration with ArgoCD

Overview of ArgoCD

ArgoCD is a declarative GitOps tool for Kubernetes. It continuously monitors the state of a Git repository and applies the defined manifests to your cluster. It also supports Helm charts directly, making it a powerful tool for managing Kubernetes applications.

Automating Helm Chart Deployment with ArgoCD

To deploy a Helm chart using ArgoCD, follow these steps:

1. Prepare Your Helm Chart

Ensure your chart is packaged and stored in a repository accessible to ArgoCD, such as AWS ECR.

2. Create an Application in ArgoCD

Define the Helm chart deployment in a Kubernetes manifest file. Here's an example:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: helm-app
  namespace: argocd
spec:
  ignoreDifferences:
  - kind: "ConfigMap"
    jsonPointers:
    - /data
  - kind: "Secret"
    jsonPointers:
    - /data
  project: default
  sources:
    - chart: my-chart
      repoURL: oci://123456789012.dkr.ecr.us-west-2.amazonaws.com
      targetRevision: 1.0.0
      helm:
        valueFiles:
        - $value/values/us/helm-app.yaml
        releaseName: my-chart
    - repoURL: 'https://github.com/<github_username>/repository'
      targetRevision: prod
      ref: value
  destination:
    server: "https://kubernetes.default.svc"
    namespace: ivms-helm-app-prod
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: true
    syncOptions:
    - CreateNamespace=true
    - PrunePropagationPolicy=background
    - PruneLast=true
    - ApplyOutOfSyncOnly=true

3. Apply the Application Manifest

Deploy the application manifest to the ArgoCD namespace:

kubectl apply -f application.yaml -n argocd

4. Monitor the Deployment

Use the ArgoCD UI or CLI to monitor the application sync status and logs.

NOTE : Your repositories(both github and helm repo) should be connected to ArgoCD.

Helm Chart Installation Using ArgoCD

ArgoCD makes it simple to install and manage Helm charts by automating the entire deployment process. With the above example, you have defined:

Chart Source: The Helm chart stored in AWS ECR.
Values File: Custom configuration for the deployment.
Sync Policy: Automated synchronization with options for pruning, self-healing, and creating namespaces.

Wrapping Up

By packaging and sharing your Helm chart, and integrating it with ArgoCD for automated deployments, you achieve:

Consistency: Helm charts ensure consistency across environments.
Automation: ArgoCD automates deployments, reducing manual intervention.
Scalability: ArgoCD scales well with multiple applications and clusters.

In the next blog, we will explore advanced Kubernetes topics, such handling secrets securely and writing cron jobs for refreshing aws sts tokens.

Building Deployment-Ready Helm Charts

Manjunath Kotabal — Sun, 26 Jan 2025 05:22:13 +0000

Helm is a powerful tool for managing Kubernetes applications, enabling you to package, configure, and deploy resources efficiently. In this guide, we’ll walk you through creating deployment-ready Helm charts by building reusable templates for common Kubernetes components.

Recap of Previous Blogs

Building Your First Helm Chart:
- Explained the basics of Helm, including installation, chart structure, and deploying your first application.
Advanced Helm Chart Components:
- Covered advanced templating techniques, conditional logic, and usage of values.yaml to make charts dynamic and flexible.

Common Components for Deployment

To deploy an application using Kubernetes, you typically need the following resources:

Deployment:
- Manages the desired state of application pods, ensures scalability, and enables rolling updates.
Service:
- Exposes your application within the cluster or externally.
Ingress:
- Handles HTTP/S traffic routing to services using custom domains and paths.
ConfigMap:
- Stores non-sensitive configuration data in key-value format.
Secrets:
- Securely stores sensitive information like database credentials or API keys.
Service Account:
- Provides an identity for application pods to interact with the cluster or external systems.

Steps to Build a Deployment-Ready Helm Chart

Step 1: Create a Helm Chart

Run the following command to generate a Helm chart structure:

helm create myapp

Delete all files in the myapp/templates/ folder to start fresh.

Step 2: Define Templates

Use the following templates to define reusable and configurable resources.

`_helpers.tpl`

{{- define "namespace" -}}
{{- printf "%s-%s-%s" .Values.productName .Values.clientName .Values.envName -}}
{{- end -}}

{{- define "serviceAccountName" -}}
{{- printf "%s-%s-%s-sa" .Values.productName .Values.clientName .Values.envName -}}
{{- end -}}

These helpers define reusable patterns for naming resources dynamically based on values.yaml.

namespace: Constructs a namespace identifier by combining productName, clientName, and envName.
serviceAccountName: Generates a unique name for the service account using the same components.

Purpose: These functions dynamically generate names for namespaces and service accounts based on values defined in values.yaml.
Usage: The template keyword invokes these functions in other templates.

`Deployment Template`

{{- range $key, $service := .Values.services }}
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ $key }}-deploy
  labels:
    app: {{ $key }}
spec:
  replicas: {{ $service.replicas | default 2 }}
  selector:
    matchLabels:
      app: {{ $key }}
  template:
    metadata:
      labels:
        app: {{ $key }}
    spec:
      serviceAccountName: {{ template "serviceAccountName" $ }}
      containers:
      - name: {{ $key }}
        image: {{ $.Values.ecr }}/{{ $key }}:{{ $service.version }}
        ports:
        - containerPort: {{ $service.port }}
        resources:
          requests:
            memory: {{ $service.requestMemory | default $.Values.defaultRequestMemory | default "1024Mi"}}
{{- end }}

For Loop: The range function iterates over each item in the .Values.services object from values.yaml.
- For each service key-value pair, a Deployment resource is created.
Dynamic Values: {{ $key }} is the name of the service. {{ $service.<property> }} retrieves properties (like replicas, port, etc.) from the corresponding entry in values.yaml.

`ConfigMap Template`

{{- range $key, $cm := .Values.configmaps }}
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ $key }}
  annotations:
    ssm-loader:  "true"
    ssm-parameter-name: {{ $cm | default "null" }}
    region: {{ $.Values.region | default "us-west-2" }}
{{- end -}}

This template loops through .Values.configmaps to create Configmap resources for each application.
You can use annotations.ssm-parameter-name for fetching the config from aws parameter store or any other configuration management system.
And add other annotations to serve your application needs

`Service Template`

{{- range $key, $service := .Values.services }}
---
apiVersion: v1
kind: Service
metadata:
  name: {{ $key }}-service
spec:
  selector:
    app: {{ $key }}
  ports:
  - protocol: TCP
    port: {{ $service.port }}
    targetPort: {{ $service.port }}
{{- end }}

This template loops through .Values.services to create a Service resource for each application.
The selector ensures the Service routes traffic to the correct pods (matched by app: {{ $key }}).

`Ingress Template`

{{ $c := 1 | int }}
{{- range $key, $service := .Values.services }}
{{- $albdomain := printf "%s-%s-%s.%s" $key $.Values.clientName $.Values.envName $.Values.topLevelDomain -}}

{{- if $service.alb }}
---
# ALB Ingress Configuration
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {{ $key }}-alb-ingress
  annotations:
    kubernetes.io/ingress.class: "alb"
    alb.ingress.kubernetes.io/group.name: {{ template "namespace" $}}-ingress-group
    alb.ingress.kubernetes.io/group.order: '{{ $c }}'
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}]'
    alb.ingress.kubernetes.io/certificate-arn: {{ $.Values.certArn }}
    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
    alb.ingress.kubernetes.io/healthcheck-port: '{{ $service.port }}'
    alb.ingress.kubernetes.io/healthcheck-path: {{ $service.healthCheck | default "/util/health" }}
    alb.ingress.kubernetes.io/healthcheck-interval-seconds: {{ $service.healthCheckInterval | default "'30'" }}
    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: {{ $service.healthCheckTimeout | default "'5'" }}
    alb.ingress.kubernetes.io/success-codes: {{ $service.healthCheckSuccessCode | default "'200'" }}
    alb.ingress.kubernetes.io/healthy-threshold-count: '2'
    alb.ingress.kubernetes.io/unhealthy-threshold-count: '2'
    alb.ingress.kubernetes.io/load-balancer-attributes: 'routing.http2.enabled=true,idle_timeout.timeout_seconds=600'
    alb.ingress.kubernetes.io/target-group-attributes: 'deregistration_delay.timeout_seconds=30, slow_start.duration_seconds=0'
    alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS-1-2-Ext-2018-06
spec:
  # ALB Ingress specification
  rules:
  - host: {{ default $albdomain $service.domain }}
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: {{ $key }}-service
            port:
              number: {{ $service.port }}
    # ALB spec continues...
{{ $c = add1 $c }}
{{- end }}

{{- if $service.nlb }}
---
# NLB Ingress Configuration
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {{ $key }}-nlb-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/use-forwarded-headers: "true"
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
    nginx.ingress.kubernetes.io/rewrite-target: /$2
spec:
  # NLB Ingress specification
  rules:
  - host: {{ $service.nlbdomain }} 
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: {{ $key }}-service
            port:
              number: {{ $service.port }}
    # NLB spec continues...
{{ $c = add1 $c }}
{{- end }}
{{- end }}

Creates an Ingress for each service.
Routes HTTP traffic to the correct Service.

`Secrets Template`

{{- range $key, $secret := .Values.secrets }}
---
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: {{ $key }}
  annotations:
    secret-loader: "true"
    secret-name: {{ $secret | default "null" }}
    region: {{ $.Values.region | default "us-west-2" }}
{{- end }}

This template loops through .Values.secrets to create Secret resources for each application.
You can use annotations.secret-name for fetching the secrets from aws secrets manager or any other secrets management system.
And add other annotations to serve your application needs

`ServiceAccount Template`

{{- if .Values.createServiceAccount }}
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: {{ template "serviceAccountName" . }}
  annotations:
    eks.amazonaws.com/role-arn: {{ .Values.serviceAccountRole }}
{{- end }}

Step 3: Customize `values.yaml`

Here’s an example values.yaml for reference:

productName: myapp
clientName: generic
envName: dev
ecr: mydockerhub.io
certArn: arn:aws:acm:<region>:<account_id>:certificate/<certificate_id>
region: us-west-2
defaultRequestMemory: 512Mi
services:
  app-service:
    replicas: 3
    port: 8080
    healthCheck : /actuator/health
    version: latest
    configList:
      - app-config
    secretList:
      - db-secret
    nlb: true
    nlbdomain: app-service.example.com
  frontend-service:
    replicas: 3
    port: 8080
    healthCheck : /actuator/health
    version: latest
    configList:
      - app-config
    secretList:
      - db-secret
    alb:true
configmaps:
  app-config: myapp-config
secrets:
  db-secret: myapp-db-credentials
createServiceAccount: true
serviceAccountRole: arn:aws:iam::123456789012:role/myapp-role

How the Templates Work

Dynamic Loops: The range function loops over .Values.<key> to generate resources for each defined service in values.yaml.
Placeholders: Variables like {{ $key }} dynamically inject values.
Defaults: | default ensures fallback values if specific properties are not set in values.yaml.

Step 4: Testing Templates Without Deployment

You can validate and render templates without applying them using helm template or helm install --dry-run:

View Rendered Templates:

  helm template myapp/

This outputs the fully rendered Kubernetes manifests for inspection.

Dry Run Installation:

  helm install myapp ./myapp --values external_values.yaml --dry-run --debug

Simulates the deployment and provides rendered manifests and potential issues.

NOTE : here external_values.yaml can be used to override you default values.yaml

Step 5: Deploying the Chart

Once verified, deploy the chart to your Kubernetes cluster:

helm install myapp ./myapp --values values.yaml

This will:

Render the templates using values from values.yaml.
Apply the resulting Kubernetes manifests to the cluster.

To upgrade an existing deployment:

helm upgrade myapp ./myapp --values values.yaml

Conclusion

This guide has shown how to build a reusable Helm chart, explaining the templates and their dynamic behavior. By using loops and placeholders, you can define a single, flexible chart that scales with your application needs. Use helm template and --dry-run to validate before deploying, ensuring a smooth rollout to your Kubernetes environment.

Checkout my article on packaging and installing helm charts with argocd : https://dev.to/manjunath_kotabal_3d1e736/packaging-and-installing-helm-chart-with-argocd-3n7a

Advanced Concepts in Helm Templates

Manjunath Kotabal — Sat, 25 Jan 2025 14:18:04 +0000

In our previous blogs, we covered the basics of Helm and how to set up your environment and create your first Helm chart. In this blog, we’ll dive deeper into Helm’s templating capabilities, focusing on advanced techniques that make Helm charts dynamic, reusable, and powerful.

Purpose of Advanced Helm Templating

Advanced templating allows you to:

Use loops and conditionals to create resources dynamically.
Create reusable logic through helper templates.
Dynamically configure ConfigMaps, Secrets, and environment variables.

Using Loops and Conditional Statements

1. Iterating Over a List of Values

Loops in Helm are used to dynamically generate resources for a list of items. This is achieved using the range function.

Example: Generating a list of environment variables for a ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-configmap
  namespace: {{ .Release.Namespace }}
data:
  {{- range $key, $value := .Values.envVars }}
  {{ $key }}: {{ $value | quote }}
  {{- end }}

values.yaml:

envVars:
  APP_MODE: production
  LOG_LEVEL: debug

The above template will create a ConfigMap with the keys and values from the envVars list in values.yaml.

2. Conditional Creation of Resources

Helm allows conditional logic using if, else, and else if statements to determine whether or not a resource should be created.

Example: Conditionally creating a Service:

{{- if .Values.service.enabled }}
apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}-service
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.targetPort }}
  selector:
    app: {{ .Release.Name }}
{{- end }}

values.yaml:

service:
  enabled: true
  type: ClusterIP
  port: 80
  targetPort: 8080

This approach ensures that a Service is only created if service.enabled is set to true.

Implementing Helper Templates

Helper templates are reusable snippets of logic defined in the _helpers.tpl file. They simplify repetitive tasks and improve code readability.

Example: Defining and using a helper template for resource labels:

_helpers.tpl:

{{- define "common.labels" -}}
app: {{ .Chart.Name }}
release: {{ .Release.Name }}
env: {{ .Values.environment | default "dev" }}
{{- end }}

Using the helper in a Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-deployment
  labels:
    {{ include "common.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Chart.Name }}
  template:
    metadata:
      labels:
        {{ include "common.labels" . | nindent 8 }}
    spec:
      containers:
        - name: {{ .Release.Name }}
          image: {{ .Values.image.repository }}:{{ .Values.image.tag }}

Helper templates make your chart modular and easier to maintain.

Handling ConfigMaps, Secrets, and Environment Variables Dynamically

1. Dynamic ConfigMaps

ConfigMaps can be generated dynamically using loops and values defined in values.yaml.

Example:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  {{- range $key, $value := .Values.configurations }}
  {{ $key }}: {{ $value | quote }}
  {{- end }}

values.yaml:

configurations:
  APP_ENV: production
  DEBUG_MODE: "false"

2. Managing Secrets

Secrets can also be templated dynamically for sensitive data.

Example:

apiVersion: v1
kind: Secret
metadata:
  name: {{ .Release.Name }}-secret
data:
  {{- range $key, $value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc }}
  {{- end }}

values.yaml:

secrets:
  DB_PASSWORD: my_secure_password
  API_KEY: my_api_key

This template ensures all secret values are base64-encoded.

3. Environment Variables in Multi-Container Pods

Helm makes it easy to configure environment variables for multi-container pods dynamically.

Example:

spec:
  containers:
    {{- range $index, $container := .Values.containers }}
    - name: {{ $container.name }}
      image: {{ $container.image }}
      env:
        {{- range $key, $value := $container.env }}
        - name: {{ $key }}
          value: {{ $value | quote }}
        {{- end }}
    {{- end }}

values.yaml:

containers:
  - name: app-container
    image: nginx:latest
    env:
      NODE_ENV: production
      LOG_LEVEL: debug
  - name: sidecar-container
    image: busybox:latest
    env:
      MONITORING: enabled

This configuration dynamically generates the container definitions and their respective environment variables.

Conclusion

Helm’s advanced templating features make it an invaluable tool for Kubernetes deployments. By leveraging loops, conditional statements, helper templates, and dynamic configurations, you can create reusable, flexible, and efficient charts tailored to your application’s needs. In the next blog, we’ll explore building deployment-ready Helm charts with best practices for production environments.

Checkout article on building deployment ready helm charts : https://dev.to/manjunath_kotabal_3d1e736/building-deployment-ready-helm-charts-3b08

Building Your First Helm Chart

Manjunath Kotabal — Sat, 25 Jan 2025 13:57:04 +0000

In the previous blog, we discussed the challenges of deploying and managing applications on Kubernetes using raw manifests and Kustomize. We also introduced Helm as a powerful tool to simplify application deployment through templating, packaging, versioning, and dependency management. In this blog, we’ll walk you through setting up your environment for Helm, and guide you through building your very first Helm chart.

In this blog, we’ll explore:

Installing Kubernetes with Kind (Kubernetes in Docker).
Installing kubectl (Kubernetes command-line tool).
Installing Helm.
Setting up your first Kubernetes cluster and deploying your first Helm chart.

Prerequisites

Before diving into Helm, you’ll need a few tools installed and configured:

Docker: Since we’re using Kind (Kubernetes in Docker), Docker is required.
Kubectl: Kubernetes command-line tool for interacting with your cluster.
Helm: Helm command-line tool to manage Helm charts.

Step 1: Install Docker

If Docker is not already installed on your machine, download and install Docker from docker.com.

To verify Docker is installed properly:

docker --version

Step 2: Install Kind (Kubernetes in Docker)

Kind is a tool for running Kubernetes clusters in Docker containers, ideal for testing Kubernetes applications locally.

To install Kind:

On macOS (using Homebrew):

brew install kind

On Linux (using curl):

curl -Lo /usr/local/bin/kind https://github.com/kubernetes-sigs/kind/releases/download/v0.17.0/kind-linux-amd64 chmod +x /usr/local/bin/kind

Verify the installation:

kind --version

Step 3: Install kubectl

kubectl is the command-line tool used to interact with your Kubernetes cluster.

To install kubectl:

On macOS (using Homebrew):

brew install kubectl

On Linux (using curl):

curl -LO "https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl" chmod +x ./kubectl sudo mv ./kubectl /usr/local/bin/kubectl

Verify the installation:

kubectl version --client

Step 4: Install Helm

Helm is the Kubernetes package manager that simplifies deployment and management of applications.

To install Helm:

On macOS (using Homebrew):

brew install helm

On Linux (using curl):

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Verify the installation:

helm version

Step 5: Create a Kubernetes Cluster with Kind

Now that you have Kind installed, let’s create a local Kubernetes cluster.

Create a Kubernetes Cluster with Kind:

Create a new cluster:

kind create cluster --name my-first-cluster

Check the cluster status: After the cluster is created, you can check the status by running:

kubectl cluster-info --context kind-my-first-cluster

You should now have a running Kubernetes cluster locally, and kubectl will be configured to interact with it.

Step 6: Initialize Helm in Your Cluster

To start using Helm with your Kind cluster, you need to initialize Helm's default configurations and repositories.

Initialize Helm:

helm repo add stable https://charts.helm.sh/stable helm repo update

This will add the default Helm repository containing a collection of publicly available charts.

Verify Helm Initialization:

helm search repo nginx

This command should return a list of available charts from the stable repository, confirming that Helm is set up correctly.

I'll help you convert the content into markdown format. Here's the markdown version:

Step 7: Create Your First Helm Chart

With Helm set up, it’s time to create your first chart!

Create a new Helm chart:

Navigate to the directory where you want to store your Helm charts and run:

helm create my-first-chart

This will generate a folder structure with the following contents:

my-first-chart/
├── Chart.yaml          # Metadata for the chart
├── values.yaml         # Default configuration values
├── charts/             # Dependencies (if any)
├── templates/          # Kubernetes manifest templates
│   ├── deployment.yaml
│   ├── service.yaml
│   └── ...
└── README.md           # Documentation

Chart.yaml: Metadata about the chart (name, version, description).

values.yaml: Default configuration values for your chart.

templates/: A folder containing YAML files for the Kubernetes resources (e.g., Deployment, Service).

Inspect the generated files: In my-first-chart/, you’ll see templates for the most common Kubernetes resources, such as a Deployment and Service.

Chart.yaml: Defines basic chart metadata.

values.yaml: Contains default values, such as the number of replicas and the container image.

templates/deployment.yaml: Defines the Deployment resource, with dynamic values pulled from values.yaml.

templates/service.yaml: Defines the Service resource for exposing your application.

Here’s an example snippet from templates/deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
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 }}"

Edit the values.yaml: Modify values.yaml to adjust configuration parameters like the container image, replicas, etc.

Example:

replicaCount: 2
image: 
  repository: nginx
  tag: stable

Install the Helm Chart: Now, deploy the chart to your cluster using the following command:

helm install my-app ./my-first-chart

Verify the Deployment: To ensure that your deployment was successful, check the status of your pods:

kubectl get pods

You should see your my-app pod running.

Checkout my article on adavanced concepts of helm chart: https://dev.to/manjunath_kotabal_3d1e736/advanced-concepts-in-helm-templates-1oo6

Introduction to Helm and Why It Matters

Manjunath Kotabal — Sat, 25 Jan 2025 09:14:56 +0000

As Kubernetes becomes the go-to solution for container orchestration, developers often face challenges in managing the complexity of deploying and maintaining applications. Kubernetes deployments involve multiple YAML manifests for resources like Deployments, Services, ConfigMaps, and Secrets, which can quickly become difficult to manage as applications grow. This is where Helm, the package manager for Kubernetes, becomes invaluable.

In this blog, we’ll explore:

Common approaches to deploying applications in Kubernetes.
The challenges of these methods.
How Helm addresses these challenges and provides significant advantages.
Advanced Helm templating concepts like loops, conditionals, and helpers.

Common Approaches to Kubernetes Deployment

1. Kubernetes Manifests

The simplest way to deploy an application to Kubernetes is by writing raw YAML manifests for each resource. For example, a typical application might include:

A Deployment manifest for the application pods.
A Service manifest for exposing the application.
ConfigMaps and Secrets for configuration and sensitive data.

Challenges:

Managing multiple YAML files is tedious.
Hardcoding values makes it difficult to reuse configurations across environments (e.g., dev, staging, prod).
Updating or rolling back changes involves manual intervention.

2. Kustomization

Kustomize, which is now integrated with kubectl, allows you to customize Kubernetes manifests without modifying the original files. It introduces the concept of overlays to handle environment-specific configurations.

Advantages:

Reusability: Base manifests can be reused across multiple environments.
Declarative: Overlays clearly define environment-specific changes.

Challenges:

Limited templating capabilities.
Managing secrets and ConfigMaps still requires additional tools.
Lack of versioning or packaging support for deployment configurations.
Adding a new microservice requires building a separate base for deploying its specific version, increasing maintenance overhead.

Why Helm?

Helm introduces the concept of charts, which are packaged collections of Kubernetes manifests combined with templates and default configurations. Helm charts enable you to deploy, manage, and version applications in a standardized way.

Advantages of Helm

1. Simplified Application Deployment

Helm packages all Kubernetes manifests into a single chart, making it easier to manage and deploy applications. A single helm install command can set up an entire application stack.

2. Templating for Reusability

Helm charts use Go templates, allowing developers to parameterize values and generate dynamic configurations. For example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-app
spec:
  replicas: {{ .Values.replicas }}
  template:
    spec:
      containers:
      - name: app
        image: {{ .Values.image.repository }}:{{ .Values.image.tag }}

This template dynamically adjusts based on input values, enabling reuse across environments.

3. Versioning and Rollbacks

Helm tracks deployments as releases. Each release is versioned, making it easy to:

Roll back to a previous state.
Audit changes made to the deployment over time.

4. Dependency Management

Helm charts can define dependencies on other charts. For example, a microservices application can have a parent chart that includes subcharts for individual services.

5. Seamless Upgrades

Helm makes it easy to upgrade applications by applying changes incrementally while maintaining a consistent state. For example:

helm upgrade my-app ./my-chart

This updates only the resources that have changed.

6. Ecosystem and Community

Helm has a rich ecosystem with a large collection of public charts available in repositories like the Artifact Hub. Developers can quickly adopt and customize these charts for common applications like NGINX, PostgreSQL, and Redis.

Advanced Concepts in Helm Templating

Helm’s templating system is one of its most powerful features, allowing you to use loops, conditionals, and helpers to create dynamic configurations. Let’s explore some advanced concepts:

1. Using Loops in Helm

Helm templates support range for looping over lists or maps. For example, creating multiple ConfigMaps dynamically:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
  labels:
    app: {{ .Chart.Name }}
data:
{{- range .Values.configs }}
  {{ .key }}: {{ .value | quote }}
{{- end }}

Here, range loops through the configs array in values.yaml.

2. Conditional Statements

Conditionals let you include or exclude resources based on values. For example:

{{- if .Values.enableService }}
apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}-service
spec:
  ports:
    - port: 80
{{- end }}

If enableService is set to false, the Service resource is excluded.

3. Using Named Templates (Helpers)

Named templates, defined in _helpers.tpl, promote reusability. Example:

{{- define "app.labels" -}}
app: {{ .Chart.Name }}
release: {{ .Release.Name }}
{{- end -}}

Usage in other templates:

metadata:
  labels:
    {{ include "app.labels" . | indent 4 }}

4. Combining Templates and Values

Helm allows you to dynamically combine multiple features for complex scenarios. For instance:

apiVersion: v1
kind: Secret
metadata:
  name: {{ .Release.Name }}-secret
stringData:
  {{- range $key, $value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc }}
  {{- end }}

This creates a Secret with keys and values base64-encoded from values.yaml.

Comparison: Helm vs. Manifests vs. Kustomize

Feature	Raw Manifests	Kustomize	Helm
Templating	None	Limited (overlays)	Advanced (Go templates)
Reusability	Manual	High (overlays)	Very High (charts)
Dependency Management	None	None	Yes
Versioning	Manual	Manual	Built-in (releases)
Rollbacks	Manual	Manual	One command (`helm rollback`)
Ecosystem	None	None	Extensive (public charts)

When to Use Helm?

Helm is ideal for:

Complex applications with multiple resources and dependencies.
Scenarios requiring templating and dynamic configurations.
Teams managing multiple environments with different configurations.
Applications requiring robust upgrade and rollback mechanisms.

For simpler setups or environments where templating isn’t needed, Kustomize or raw manifests might suffice. However, as the complexity of your application grows, Helm becomes indispensable.

Conclusion

Helm revolutionizes how applications are deployed and managed in Kubernetes. By combining templating, packaging, versioning, and an extensive ecosystem, it simplifies the complexities of Kubernetes deployments. Whether you're managing a single application or an entire ecosystem, Helm is a powerful tool to have in your Kubernetes toolkit.

By leveraging advanced templating features like loops, conditionals, and helpers, you can build highly dynamic and reusable Helm charts tailored to your application’s needs. In the next post, we’ll dive into setting up your environment for Helm and getting started with your first Helm chart. Stay tuned!

Check my new blog on https://dev.to/manjunath_kotabal_3d1e736/setting-up-your-environment-for-helm-and-building-your-first-helm-chart-34ko

Forem: Manjunath Kotabal

Packaging and Installing Helm Chart with ArgoCD

Packaging and Sharing Helm Charts

Packaging a Helm Chart

Storing Helm Charts

1. OCI (Open Container Initiative) Registry

Example: Storing a Helm Chart in AWS ECR

2. Chart Repositories

3. Git Repositories

4. Self-Hosted Solutions

CI/CD Integration with ArgoCD

Overview of ArgoCD

Automating Helm Chart Deployment with ArgoCD

1. Prepare Your Helm Chart

2. Create an Application in ArgoCD

3. Apply the Application Manifest

4. Monitor the Deployment

Helm Chart Installation Using ArgoCD

Wrapping Up

Building Deployment-Ready Helm Charts

Recap of Previous Blogs

Common Components for Deployment

Steps to Build a Deployment-Ready Helm Chart

Step 1: Create a Helm Chart

Step 2: Define Templates

_helpers.tpl

Deployment Template

ConfigMap Template

Service Template

Ingress Template

Secrets Template

ServiceAccount Template

Step 3: Customize values.yaml

How the Templates Work

Step 4: Testing Templates Without Deployment

Step 5: Deploying the Chart

Conclusion

Advanced Concepts in Helm Templates

Purpose of Advanced Helm Templating

Using Loops and Conditional Statements

1. Iterating Over a List of Values

2. Conditional Creation of Resources

Implementing Helper Templates

Handling ConfigMaps, Secrets, and Environment Variables Dynamically

1. Dynamic ConfigMaps

2. Managing Secrets

3. Environment Variables in Multi-Container Pods

Conclusion

Building Your First Helm Chart

Prerequisites

On macOS (using Homebrew):

On Linux (using curl):

On macOS (using Homebrew):

On Linux (using curl):

On macOS (using Homebrew):

On Linux (using curl):

Create a new cluster:

Check the cluster status: After the cluster is created, you can check the status by running:

Initialize Helm:

Verify Helm Initialization:

Create a new Helm chart:

Introduction to Helm and Why It Matters

Common Approaches to Kubernetes Deployment

1. Kubernetes Manifests

2. Kustomization

Why Helm?

Advantages of Helm

1. Simplified Application Deployment

2. Templating for Reusability

3. Versioning and Rollbacks

4. Dependency Management

5. Seamless Upgrades

6. Ecosystem and Community

Advanced Concepts in Helm Templating

1. Using Loops in Helm

2. Conditional Statements

3. Using Named Templates (Helpers)

4. Combining Templates and Values

Comparison: Helm vs. Manifests vs. Kustomize

When to Use Helm?

`_helpers.tpl`

`Deployment Template`

`ConfigMap Template`

`Service Template`

`Ingress Template`

`Secrets Template`

`ServiceAccount Template`

Step 3: Customize `values.yaml`