Top Helm Chart frequently asked interview questions.

In this post we will look at Helm Chart Interview questions. Examples are provided with explanations.

Q: What is Helm and why is it used in Kubernetes?

A : Helm is a package manager for Kubernetes that helps you define, install, and manage Kubernetes applications. It is often referred to as "the Kubernetes package manager" similar to how apt is for Ubuntu or yum is for CentOS.

Helm uses a packaging format called charts. A chart is a collection of files that describe a related set of Kubernetes resources. A single chart might be used to deploy something simple, like a memcached pod, or something complex, like a full web app stack with HTTP servers, databases, caches, and so on.

Key benefits of using Helm:

Simplified Deployment - Allows you to deploy complex applications with a single command
Version Control - Provides versioning for your Kubernetes manifests
Reusability - Charts can be shared and reused across teams and organizations
Rollback Capability - Easy rollback to previous versions if something goes wrong
Configuration Management - Centralized management of configuration values

Q: What is the structure of a Helm chart?

A : A Helm chart is organized as a collection of files inside a directory. The directory name is the name of the chart (without versioning information). The typical structure of a Helm chart looks like this:

mychart/
  Chart.yaml          # A YAML file containing information about the chart
  LICENSE             # OPTIONAL: A plain text file containing the license for the chart
  README.md           # OPTIONAL: A human-readable README file
  values.yaml         # The default configuration values for this chart
  values.schema.json  # OPTIONAL: A JSON Schema for imposing a structure on the values.yaml file
  charts/             # A directory containing any charts upon which this chart depends
  crds/               # Custom Resource Definitions
  templates/          # A directory of templates that, when combined with values, will generate valid Kubernetes manifests
  templates/NOTES.txt # OPTIONAL: A plain text file containing short usage notes

The most important files are:

Chart.yaml - Contains metadata about the chart (name, version, description, etc.)
values.yaml - Default configuration values that can be overridden during installation
templates/ - Directory containing Kubernetes manifest templates that use Go templating

Q: What are the main differences between Helm 2 and Helm 3?

A : Helm 3 introduced several significant changes compared to Helm 2:

1. Removal of Tiller:
Helm 2 used a server-side component called Tiller that ran inside the Kubernetes cluster. Helm 3 completely removed Tiller, making Helm a fully client-side tool. This eliminates security concerns related to Tiller having elevated permissions.

2. Three-Way Strategic Merge Patches:
Helm 3 uses a three-way strategic merge patch strategy. This means Helm considers the old manifest, the live state, and the new manifest when generating a patch. This provides more accurate upgrades.

3. Release Names are now Scoped to the Namespace:
In Helm 2, release names had to be unique across the entire cluster. In Helm 3, release names are scoped to the namespace, allowing the same release name to be used in different namespaces.

4. Secrets as the Default Storage Driver:
Helm 3 stores release information in Secrets by default (Helm 2 used ConfigMaps). This is more secure and aligns with Kubernetes best practices.

5. Chart Dependencies:
Helm 3 moved chart dependencies from requirements.yaml to Chart.yaml, simplifying the chart structure.

6. JSON Schema Validation:
Helm 3 added support for values schema validation using JSON Schema, helping catch configuration errors early.

Q: How do you pass custom values when installing a Helm chart?

A : There are multiple ways to pass custom values when installing or upgrading a Helm chart:

1. Using a values file:

helm install myrelease mychart -f custom-values.yaml

2. Using --set flag for individual values:

helm install myrelease mychart --set image.tag=1.2.3

3. Using --set-string for forcing string values:

helm install myrelease mychart --set-string nodeSelector."kubernetes\.io/role"=master

4. Using multiple values files (later files override earlier ones):

helm install myrelease mychart -f values1.yaml -f values2.yaml

5. Combining multiple approaches:

helm install myrelease mychart -f custom-values.yaml --set image.tag=1.2.3

The order of precedence (highest to lowest) is:

Values passed via --set or --set-string
Values from files specified with -f
Default values from values.yaml in the chart

Q: What are Helm hooks and when would you use them?

A : Helm hooks allow chart developers to intervene at certain points in a release's lifecycle. Hooks work like regular templates but have special annotations that cause Helm to utilize them differently.

Available hooks include:

pre-install - Executes after templates are rendered, but before any resources are created in Kubernetes
post-install - Executes after all resources are loaded into Kubernetes
pre-delete - Executes on a deletion request before any resources are deleted from Kubernetes
post-delete - Executes on a deletion request after all release resources have been deleted
pre-upgrade - Executes on an upgrade request after templates are rendered, but before any resources are updated
post-upgrade - Executes on an upgrade request after all resources have been upgraded
pre-rollback - Executes on a rollback request after templates are rendered, but before any resources are rolled back
post-rollback - Executes on a rollback request after all resources have been modified
test - Executes when the Helm test subcommand is invoked

Example of a pre-install hook for database migration:

apiVersion: batch/v1
kind: Job
metadata:
  name: "{{ .Release.Name }}-db-migration"
  annotations:
    "helm.sh/hook": pre-install
    "helm.sh/hook-weight": "-5"
    "helm.sh/hook-delete-policy": before-hook-creation
spec:
  template:
    spec:
      containers:
      - name: db-migration
        image: "{{ .Values.dbMigration.image }}"
        command: ["migrate", "up"]
      restartPolicy: Never

Q: How do you manage chart dependencies in Helm?

A : In Helm 3, chart dependencies are managed through the Chart.yaml file. Dependencies are other charts that your chart requires to function properly.

Example Chart.yaml with dependencies:

apiVersion: v2
name: myapp
description: A Helm chart for my application
version: 1.0.0
dependencies:
  - name: postgresql
    version: 11.6.12
    repository: https://charts.bitnami.com/bitnami
    condition: postgresql.enabled
  - name: redis
    version: 16.8.7
    repository: https://charts.bitnami.com/bitnami
    alias: cache
    tags:
      - cache

Key fields for dependencies:

name - The name of the chart
version - The version of the chart (can use version ranges like "~1.2.3")
repository - The repository URL where the chart is located
condition - A YAML path to a boolean value that enables/disables the chart
tags - Labels that can be used to enable/disable groups of charts
alias - An alternative name for the chart, useful when including the same chart multiple times

To download dependencies:

helm dependency update mychart/

This downloads all dependencies into the charts/ subdirectory.

Q: What are Helm template functions and how do you use them?

A : Helm uses Go templates for generating Kubernetes manifests. It provides over 60 template functions (from Go and Sprig libraries) plus some Helm-specific functions.

Common template functions:

1. String Functions:

{{ upper .Values.name }}              # Convert to uppercase
{{ quote .Values.name }}              # Add quotes around value
{{ .Values.name | default "myapp" }}  # Provide default value
{{ printf "%s-%s" .Release.Name .Chart.Name }}  # String formatting

2. Type Conversion:

{{ .Values.replicas | int }}          # Convert to integer
{{ .Values.enabled | toString }}      # Convert to string

3. Conditional Functions:

{{ if .Values.enabled }}
  # content when enabled
{{ else }}
  # content when disabled
{{ end }}

{{ .Values.name | default "myapp" }}  # Use default if value is empty

4. List and Dictionary Functions:

{{ range .Values.items }}
  - {{ . }}
{{ end }}

{{ .Values.config | toYaml | nindent 2 }}  # Convert dict to YAML with indentation

5. Helm-Specific Functions:

{{ include "mychart.fullname" . }}    # Include named template
{{ .Release.Name }}                   # Release name
{{ .Release.Namespace }}              # Release namespace
{{ .Chart.Name }}                     # Chart name
{{ .Chart.Version }}                  # Chart version
{{ .Values.someValue }}               # Access values

6. File Functions:

{{ .Files.Get "config.txt" }}         # Read file content
{{ .Files.Glob "configs/*.yaml" }}    # Get files matching pattern

Q: How do you perform rollbacks in Helm?

A : Helm maintains a history of all releases, making it easy to rollback to a previous version if an upgrade causes issues.

1. View release history:

helm history myrelease

This shows all revisions with their status, chart version, app version, and description.

2. Rollback to the previous revision:

helm rollback myrelease

3. Rollback to a specific revision:

helm rollback myrelease 3

4. Rollback with additional options:

helm rollback myrelease 3 --wait --timeout 5m --cleanup-on-fail

Options include:

--wait - Wait until all Pods are ready before marking the rollback as successful
--timeout - Time to wait for Kubernetes commands to complete
--cleanup-on-fail - Delete new resources created during rollback if it fails
--force - Force resource updates through a delete/recreate
--recreate-pods - Perform pods restart for the resource if applicable

5. Get status of rollback:

helm status myrelease

Helm creates a new revision when rolling back, so you can see the complete history and even rollback a rollback if needed.

Q: What is the difference between 'helm install' and 'helm upgrade'?

A : helm install and helm upgrade are two fundamental Helm commands with distinct purposes:

helm install:

Creates a new release of a chart
Fails if a release with the same name already exists
Assigns a new revision number (always revision 1)
Used for first-time deployment of an application

Syntax:

helm install myrelease mychart/
helm install myrelease mychart/ -f custom-values.yaml
helm install myrelease mychart/ --create-namespace --namespace myns

helm upgrade:

Updates an existing release with new values or a new chart version
Fails if the release doesn't exist (unless using --install flag)
Increments the revision number
Used for updating deployed applications
Can rollback if the upgrade fails

Syntax:

helm upgrade myrelease mychart/
helm upgrade myrelease mychart/ -f updated-values.yaml
helm upgrade myrelease mychart/ --set image.tag=2.0.0

helm upgrade --install (Install or Upgrade):
A common pattern is to use --install flag with upgrade, which installs the release if it doesn't exist, or upgrades it if it does:

helm upgrade --install myrelease mychart/ -f values.yaml

This is useful in CI/CD pipelines where you don't know if the release already exists.

Q: How do you handle secrets and sensitive data in Helm charts?

A : Managing secrets in Helm charts requires careful consideration of security. Here are several approaches:

1. Kubernetes Secrets (Basic Approach):
Define secrets in templates/secret.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: {{ .Release.Name }}-secret
type: Opaque
data:
  password: {{ .Values.password | b64enc | quote }}
  apiKey: {{ .Values.apiKey | b64enc | quote }}

Pass values during installation (NOT RECOMMENDED for production):

helm install myrelease mychart/ --set password=mypassword

2. Using Helm Secrets Plugin:
The helm-secrets plugin encrypts values files using Mozilla SOPS:

# Install plugin
helm plugin install https://github.com/jkroepke/helm-secrets

# Encrypt a values file
helm secrets enc secrets.yaml

# Install using encrypted file
helm secrets install myrelease mychart/ -f secrets.yaml

3. External Secrets Operator:
Use External Secrets Operator to fetch secrets from external systems (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault):

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: {{ .Release.Name }}-external-secret
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: SecretStore
  target:
    name: {{ .Release.Name }}-secret
  data:
  - secretKey: password
    remoteRef:
      key: /path/to/secret
      property: password

4. Sealed Secrets:
Use Bitnami Sealed Secrets to encrypt secrets that can be safely stored in Git:

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: {{ .Release.Name }}-sealed-secret
spec:
  encryptedData:
    password: AgBghMq7... # encrypted value

Best Practices:

Never commit plain-text secrets to version control
Use external secret management systems for production
Limit access to values files containing secrets
Use RBAC to restrict who can view secrets in Kubernetes
Rotate secrets regularly
Consider using tools like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault

Q: What are some best practices for creating and maintaining Helm charts?

A : Creating maintainable and reliable Helm charts requires following several best practices:

1. Chart Structure and Organization:

Use meaningful names for templates and values
Keep templates modular and reusable using named templates (_helpers.tpl)
Organize templates logically (deployment.yaml, service.yaml, ingress.yaml, etc.)
Use consistent naming conventions across all resources

2. Values File Management:

Provide sensible defaults in values.yaml
Document all values with comments
Use values.schema.json for validation
Group related values together
Avoid deeply nested values structures

Example values.yaml:

# Image configuration
image:
  repository: myapp
  tag: "1.0.0"
  pullPolicy: IfNotPresent

# Resource limits
resources:
  limits:
    cpu: 100m
    memory: 128Mi
  requests:
    cpu: 100m
    memory: 128Mi

3. Template Best Practices:

Always quote strings in templates
Use the 'include' function instead of 'template' for better control
Validate required values using 'required' function
Use 'nindent' for proper YAML indentation
Add comments to complex template logic

4. Testing:

Use 'helm lint' to validate chart syntax
Use 'helm template' to render templates locally
Write Helm tests in templates/tests/
Use 'helm test' to validate deployments
Implement CI/CD pipelines for chart validation

5. Versioning and Documentation:

Follow Semantic Versioning for chart versions
Update Chart.yaml version and appVersion appropriately
Maintain a comprehensive README.md
Document breaking changes in CHANGELOG.md
Include upgrade instructions

6. Security:

Never hardcode secrets
Use proper RBAC configurations
Implement Pod Security Standards
Run containers as non-root users
Use security contexts appropriately

7. Resource Management:

Always define resource requests and limits
Implement health checks (liveness and readiness probes)
Use appropriate update strategies
Set meaningful labels and annotations

These best practices help create charts that are reliable, maintainable, secure, and easy to use across different environments.

Search Tutorials