Kubernetes Helm Charts 2026: Packaging, Deployment e Domande da Colloquio

I Kubernetes Helm Charts semplificano il deployment delle applicazioni raggruppando tutte le risorse Kubernetes in un singolo artefatto versionato. Helm 3, l'attuale release stabile, elimina la necessità di Tiller e introduce il supporto per registry OCI, rendendo la distribuzione dei chart più sicura e standardizzata. Questo tutorial copre la creazione dei chart, il templating, le strategie di deployment e le domande più comuni poste dai team di assunzione.

Comprendere la Struttura e i Componenti degli Helm Chart

Un Helm chart è una directory con una struttura predefinita. Il nome del chart diventa il nome della directory, e ogni file serve uno scopo specifico nel processo di packaging e deployment.

# Chart.yaml
apiVersion: v2
name: my-application
description: A production-ready web application
type: application
version: 1.0.0
appVersion: "2.1.0"
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled

L'apiVersion: v2 indica la compatibilità con Helm 3. Il campo version traccia le modifiche al chart, mentre appVersion riflette la versione dell'applicazione deployata. Le dipendenze dichiarano altri chart richiesti da questo chart, con condizioni opzionali per abilitarli o disabilitarli.

# values.yaml
replicaCount: 3

image:
  repository: myregistry.io/app
  tag: "2.1.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 8080

resources:
  limits:
    cpu: 500m
    memory: 512Mi
  requests:
    cpu: 100m
    memory: 128Mi

postgresql:
  enabled: true
  auth:
    database: appdb

I values definiscono i valori di configurazione predefiniti che gli utenti sovrascrivono durante l'installazione. Annidare i valori sotto chiavi significative mantiene le configurazioni organizzate e auto-documentanti.

Creare Kubernetes Deployment con Helm Templates

Gli Helm templates utilizzano il Go templating con le funzioni Sprig per generare dinamicamente i manifest Kubernetes. L'oggetto {{ .Values }} fornisce accesso al contenuto di values.yaml, mentre {{ .Release }} contiene i metadati del deployment.

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "my-application.fullname" . }}
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      {{- include "my-application.selectorLabels" . | nindent 6 }}
  template:
    metadata:
      labels:
        {{- include "my-application.selectorLabels" . | nindent 8 }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - containerPort: {{ .Values.service.port }}
          resources:
            {{- toYaml .Values.resources | nindent 12 }}

La funzione nindent aggiunge newline e indentazione, fondamentale per la generazione YAML. L'uso di include con template nominati (definiti in _helpers.tpl) mantiene i template DRY e manutenibili.

# templates/_helpers.tpl
{{- define "my-application.fullname" -}}
{{- if .Values.fullnameOverride }}
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" }}
{{- else }}
{{- $name := default .Chart.Name .Values.nameOverride }}
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" }}
{{- end }}
{{- end }}

{{- define "my-application.labels" -}}
helm.sh/chart: {{ include "my-application.chart" . }}
app.kubernetes.io/name: {{ include "my-application.name" . }}
app.kubernetes.io/instance: {{ .Release.Name }}
app.kubernetes.io/version: {{ .Chart.AppVersion | quote }}
app.kubernetes.io/managed-by: {{ .Release.Service }}
{{- end }}

I template helper standardizzano le convenzioni di naming e le label su tutte le risorse, garantendo coerenza con le label raccomandate da Kubernetes.

Dipendenze degli Helm Chart e Subchart

Le applicazioni complesse dipendono spesso da database, cache o message queue. Le dipendenze Helm permettono di incorporare questi come subchart, gestiti automaticamente durante l'installazione.

# Update dependencies before packaging
helm dependency update ./my-application

# Build dependencies (creates charts/ directory)
helm dependency build ./my-application

Il comando helm dependency update scarica le dipendenze nella directory charts/. Le dipendenze condizionali usano i values per controllare l'inclusione:

# values.yaml
postgresql:
  enabled: true

redis:
  enabled: false

# Chart.yaml
dependencies:
  - name: postgresql
    version: "15.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: postgresql.enabled
  - name: redis
    version: "19.x"
    repository: "https://charts.bitnami.com/bitnami"
    condition: redis.enabled

Questo pattern abilita configurazioni specifiche per ambiente dove la produzione utilizza servizi gestiti mentre lo sviluppo usa database in-cluster.

Deployare Helm Charts con Release Management

Helm traccia i deployment come release, abilitando rollback e upgrade versionati. Ogni release mantiene una cronologia per audit e recovery.

# Install a chart with custom values
helm install my-release ./my-application \
  --namespace production \
  --create-namespace \
  --values production-values.yaml \
  --set image.tag=2.1.1

# Upgrade an existing release
helm upgrade my-release ./my-application \
  --namespace production \
  --values production-values.yaml \
  --set image.tag=2.2.0 \
  --atomic \
  --timeout 5m

Il flag --atomic garantisce che gli upgrade falliti vengano automaticamente rollbackati. Il flag --timeout imposta quanto tempo Helm attende che le risorse diventino pronte prima di dichiarare un fallimento.

# View release history
helm history my-release -n production

# Rollback to previous revision
helm rollback my-release 2 -n production

# Uninstall a release
helm uninstall my-release -n production --keep-history

Il flag --keep-history preserva i record delle release anche dopo la disinstallazione, utile per compliance e debugging.

Strategie di Testing e Validazione degli Helm Chart

Testare gli Helm chart prima del deployment intercetta errori di template e problemi di configurazione in anticipo. Helm fornisce strumenti integrati per linting e test dry-run.

# Lint chart for errors and best practices
helm lint ./my-application

# Render templates locally without deploying
helm template my-release ./my-application \
  --values production-values.yaml \
  > rendered-manifests.yaml

# Dry-run against cluster API
helm install my-release ./my-application \
  --dry-run \
  --debug \
  --namespace production

Il comando helm template renderizza i manifest localmente, utile per pipeline CI che validano lo YAML generato. Il flag --dry-run invia i manifest al server API Kubernetes per la validazione senza creare risorse.

# templates/tests/test-connection.yaml
apiVersion: v1
kind: Pod
metadata:
  name: "{{ include "my-application.fullname" . }}-test"
  labels:
    {{- include "my-application.labels" . | nindent 4 }}
  annotations:
    "helm.sh/hook": test
spec:
  containers:
    - name: curl
      image: curlimages/curl:8.7.1
      command: ['curl']
      args: ['{{ include "my-application.fullname" . }}:{{ .Values.service.port }}/health']
  restartPolicy: Never

Gli Helm hook con helm.sh/hook: test vengono eseguiti dopo helm test my-release, validando che i deployment funzionino correttamente post-installazione.

Tecniche Avanzate di Helm Templating

I chart di produzione richiedono logica condizionale, loop e trasformazione dei dati. Le funzioni Sprig estendono i template Go con utility per manipolazione di stringhe, encoding e controllo del flusso.

# templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "my-application.fullname" . }}-config
data:
  {{- range $key, $value := .Values.config }}
  {{ $key }}: {{ $value | quote }}
  {{- end }}
  
  {{- if .Values.features.enabled }}
  FEATURE_FLAGS: {{ .Values.features.flags | join "," | quote }}
  {{- end }}

# templates/secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: {{ include "my-application.fullname" . }}-secrets
type: Opaque
data:
  {{- range $key, $value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc }}
  {{- end }}

La funzione range itera su map e liste. La funzione b64enc codifica in base64 i valori per i Kubernetes secrets. Gli operatori pipe concatenano funzioni per la trasformazione dei dati.

Domande e Risposte sui Helm Charts per Colloqui

I colloqui tecnici testano frequentemente la conoscenza di Helm attraverso domande concettuali e pratiche. Le seguenti coprono gli argomenti più comunemente chiesti.

Qual è la differenza tra helm install e helm upgrade --install?

helm install crea una nuova release e fallisce se la release esiste già. helm upgrade --install (con il flag --install) crea una nuova release se non esiste, o la aggiorna se esiste. Le pipeline CI/CD tipicamente usano helm upgrade --install per deployment idempotenti.

Come vengono passati i dati sensibili agli Helm chart?

Esistono tre approcci: secret manager esterni (Vault, AWS Secrets Manager), file values crittografati (SOPS, sealed-secrets), o Kubernetes secrets creati fuori da Helm e referenziati nei template. Memorizzare secret in file values.yaml in chiaro committati nel version control dovrebbe essere evitato.

Cosa sono gli Helm hook e quando dovrebbero essere usati?

Gli hook vengono eseguiti in punti specifici del ciclo di vita della release: pre-install, post-install, pre-upgrade, post-upgrade, pre-delete, post-delete, pre-rollback, post-rollback e test. Gli usi comuni includono migrazioni del database prima degli upgrade, invio di notifiche dopo i deployment, o esecuzione di test di integrazione.

Come viene gestito il versioning dei chart?

Il campo version in Chart.yaml traccia le modifiche al chart usando il semantic versioning. Il campo appVersion traccia la versione dell'applicazione deployata. La version dovrebbe essere incrementata per qualsiasi modifica al chart, anche se la versione dell'applicazione rimane la stessa.

Qual è lo scopo di .helmignore?

Simile a .gitignore, .helmignore esclude file dal packaging del chart. Le voci tipiche includono *.tgz (evita di pacchettizzare build precedenti), .git/, documentazione *.md non necessaria a runtime, e file di configurazione CI.

Per ulteriore preparazione ai colloqui Kubernetes, è possibile esplorare i moduli Kubernetes Basics e Kubernetes Advanced su SharpSkill.

Conclusione

Conclusioni pratiche per lavorare con gli Helm chart:

• Strutturare i chart con una chiara separazione tra metadati Chart.yaml, valori predefiniti values.yaml e directory templates contenente i manifest Kubernetes
• Usare template helper in _helpers.tpl per standardizzare naming e label su tutte le risorse
• Gestire le dipendenze attraverso Chart.yaml con abilitazione condizionale per configurazioni specifiche per ambiente
• Testare i chart con helm lint, helm template e helm install --dry-run prima del deployment in produzione
• Tracciare le release con nomi significativi e usare il flag --atomic per rollback automatico su upgrade falliti
• Memorizzare i secret in manager esterni piuttosto che in file values in chiaro