Come deployare applicazioni su Kubernetes con Helm: esempi pratici step-by-step

In questo tutorial, imparerai come creare e installare un custom Helm Chart e deployare un'applicazione su cluster Kubernetes di Aruba Cloud, per farlo utilizzeremo NGINX.

In questo tutorial vedremo:

• Cos'è Helm e come funziona - Comprendere l'architettura e i componenti principali di Helm;
• Installazione e configurazione di Helm - Preparare Helm per l'utilizzo con il proprio Aruba managed Kubernetes;
• Comprendere Helm Chart - Esplorare la struttura di un chart, i template e il file values.yaml;
• Scrivere un proprio Helm Chart - Guida passo passo alla creazione di un chart personalizzato;
• Distribuire applicazioni con Helm - Installare, aggiornare e gestire i rilasci, inclusi rollback.

Prerequisiti

Prima di iniziare, assicurati di avere:

• Un cluster Kubernetes attivo su Aruba Managed Kubernetes;
• kubectl installato;
• Il file kubeconfig per accedere al cluster;
• Conoscenze di base di Kubernetes e dei file YAML.

Cos'è un Helm Chart?

Un Helm chart è un pacchetto che descrive un'applicazione Kubernetes, completo di template per le risorse e di valori di configurazione predefiniti. Consente di distribuire applicazioni anche complesse con un solo comando, mantenendo al tempo stesso una struttura modulare, riutilizzabile e facilmente configurabile.

Ogni chart definisce:

• Quali risorse Kubernetes creare, come Deployment, Service, ConfigMap, etc.;
• Come configurarle: grazie a un file .yaml è possibile personalizzare facilmente il comportamento del chart;
• Metadati e dipendenze, utili per la gestione e l'installazione del pacchetto.

Grazie a Helm, puoi semplificare il rilascio di applicazioni nel tuo cluster, evitando configurazioni ridondanti e rendendo il processo più sicuro e ripetibile.

Come funziona Helm

Componenti e architettura di Helm

Helm adotta un'architettura nella quale interagisce direttamente con il Kubernetes API Server, senza richiedere componenti di backend. Di seguito i principali componenti di Helm:

• Helm CLI - L'interfaccia a riga di comando per gestire chart, release e repository;
• Helm Charts - Pacchetti applicativi per Kubernetes che definiscono risorse come Deployment, Service, ConfigMap e Secret;
• Helm Repository - Raccolta di Helm chart archiviati in un repository remoto o locale,
• Helm Release - Un'istanza di un Helm Chart.

Il workflow di Helm: come gestisce le distribuzioni

• Recupero dei chart: Helm scarica un chart da un repository locale o remoto, contenente i template e i valori predefiniti dell'applicazione;
• Templating e rendering: Helm sostituisce dinamicamente i valori all'interno dei template YAML utilizzando il file values.yaml, prima di applicarli o direttamente tramite CLI;
• Creazione di una release: Quando un chart viene installato, Helm assegna un nome univoco alla release e Helm registra una release con uno stato tracciabile all'interno di Kubernetes;
• Versionamento e rollback: Helm consente di aggiornare, monitorare, effettuare rollback e disinstallare la release con un singolo comando, mantenendo la cronologia completa.

Step 1: Installare Helm

1.1 Installare kubectl

1.2 Installare Helm

Procedi installando l'ultima versione di Helm:

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

Controlla che Helm sia installato correttamente:

  
    helm version
  

Step 2: Collegarsi al cluster Aruba Kubernetes

Se non hai ancora kubectl, puoi installarlo velocemente con questi comandi:

  
    curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"

    chmod +x kubectl
    
    sudo mv kubectl /usr/local/bin/
  

Verifica l'installazione:

  
    kubectl version --client
  

Scarica il file kubeconfig del tuo cluster. Puoi facilmente scaricarlo dalla Cloud Management Platform selezionando il tuo cluster e l'azione “scarica”.

Configura il file kubeconfig esportandolo nel terminale:

  
    export KUBECONFIG=/home/ubuntu/.kube/config
  

Verifica la connessione al cluster:

  
    kubectl get nodes
  

Se tutto è corretto, vedrai l'elenco dei nodi Kubernetes disponibili.

Step 3: Creare un nuovo Helm Chart

Ora crea il tuo primo Helm chart. Utilizza il comando:

  
    helm create my-nginx
  

Helm crea una cartella chiamata my-nginx con una serie di file e sottocartelle che rappresentano un chart "vuoto", ma pronto per essere utilizzato e personalizzato. Questo ti evita di scrivere manualmente tutti i file YAM. Il comando genera una struttura di cartelle come questa:

  
    ls -al

    my-nginx/
    ├── charts/
    ├── Chart.yaml
    ├── templates/
    │   ├── NOTES.txt
    │   ├── _helpers.tpl
    │   ├── deployment.yaml
    │   ├── hpa.yaml
    │   ├── ingress.yaml
    │   ├── service.yaml
    │   ├── serviceaccount.yaml
    │   └── tests/
    ├── values.yaml
  

Step 4: Capire e modificare i file YAML

Analizziamo insieme i file principali creati dal comando helm create.

4.1 Chart.yaml

Contiene le informazioni di base sul chart.

Esempio di Chart.yaml:

  
    apiVersion: v2
    name: my-nginx
    description: Un Helm chart per deployare NGINX su Kubernetes
    type: application
    version: 0.1.0
    appVersion: "1.25.3"
  

4.2 values.yaml

Qui trovi tutti i valori di configurazione predefiniti.

Esempio di values.yaml:

  
    replicaCount: 1
    
    image:
      repository: nginx
      tag: latest
      pullPolicy: IfNotPresent
    
    service:
      type: LoadBalancer
      port: 80
    
    ingress:
      enabled: false
    
    resources: {}
  

Questo file ti permette di personalizzare il comportamento del tuo chart senza dover modificare direttamente i template.

• replicaCount: definisce quante repliche di deployment saranno create
• image: configura il container.
• Repository: specifica il nome del repository dell'immagine. In questo caso, l'immagine pubblica nginx verrà utilizzata da Docker Hub;
• image.tag: latest Indica la versione. Con latest si userà sempre l'ultima versione disponibile del container nginx. Non è consigliato in produzione perché non è deterministico (potrebbe cambiare nel tempo);
• image.pullPolicy: IfNotPresent Questa opzione definisce quando Kubernetes deve scaricare l'immagine:
• IfNotPresent: scarica l'immagine solo se non è già presente nel nodo
• Always: scarica sempre l'immagine, anche se presente localmente;
• Never: non scarica mai l'immagine (usa solo immagini preesistenti);
• service: configura il tipo di service e port. In questo caso sfruttiamo il servizio di Load Balancer messo a disposizione da Aruba Cloud per accedere all'app dall'esterno. Verrà creato automaticamente un servizio di Load Balancer con un Elastic IP disponibile, precedentemente creato mediante la Cloud Management Platform di Aruba Cloud.

Possiamo verificare direttamente dalla console nella sezione networking del cluster Kubernetes.

4.3 templates/deployment.yaml

Definisce il deployment Kubernetes per avviare il container di NGINX.

Esempio di deployment.yaml:

  
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: {{ .Release.Name }}-deployment
    spec:
      replicas: {{ .Values.replicaCount }}
      selector:
        matchLabels:
          app: {{ .Release.Name }}
      template:
        metadata:
          labels:
            app: {{ .Release.Name }}
        spec:
          containers:
            - name: nginx
              image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
              ports:
                - containerPort: 80
  

I valori tra {{ }} vengono sostituiti dinamicamente usando le variabili definite in values.yaml o interne di Helm.

4.4 templates/service.yaml

Definisce il Service Kubernetes che espone il Deployment.

Esempio di service.yaml:

  
    apiVersion: v1
    kind: Service
    metadata:
      name: {{ include "my-nginx.fullname" . }}
      labels:
        {{- include "my-nginx.labels" . | nindent 4 }}
    spec:
      type: {{ .Values.service.type }}
      ports:
        - port: {{ .Values.service.port }}
          targetPort: {{ .Values.service.targetPort }}
          protocol: TCP
          name: http
      selector:
        {{- include "my-nginx.selectorLabels" . | nindent 4 }}
  

Step 5: Deployare il Chart su Kubernetes

Ora siamo pronti per deployare la chart appena creata.

Prima potresti eventualmente verificare la configurazione che sarà installata mediante il seguente comando:

  
    `helm template`
  

Procediamo quindi con il deploy mediante il seguente comando:

  
    helm install my-nginx ./my-nginx
  

• my-nginx: è il nome del rilascio (release)
• ./my-nginx: è il percorso del chart locale

Il comando esegue queste 3 macro attività

• Analizza i template;
• Sostituisce i segnaposto con i valori definiti in values.yaml;
• Applica le risorse al cluster Kubernetes.

Controlla i rilasci Helm. Per elencare tutti i rilasci nel namespace attivo:

  
    helm list
  

Per vedere i dettagli del rilascio:

  
    helm status my-nginx
  

Verifica le risorse create:

  
    kubectl get all
  

Dovresti vedere:

• un Deployment,
• un Pod,
• un Service.

Step 6: accedere all'Applicazione

Ora puoi aprire un browser e verificare la raggiungibilità dell'applicazione:

  
    http://"IP del LoadBalancer Creato":8080
  

Vedrai la classica pagina di benvenuto di NGINX!

Puoi verificare la creazione del servizio di Load Balancer dalla Cloud Management Platform di Aruba Cloud, accedi alla sezione Network del cluster Kuberenets.

Step 7: aggiornare o eliminare il deployment

1. Aggiornare un rilascio (Helm upgrade)

Per aggiornare l'app con nuove modifiche nel chart o nei valori, modifichiamo il numero di repliche nel file Values.yaml:

Esempio di values.yaml:

  
    replicaCount: 2
    
    image:
      repository: nginx
      tag: latest
      pullPolicy: IfNotPresent
    
    service:
      type: LoadBalancer
      port: 80
    
    ingress:
      enabled: false
    
    resources: {}
  

Procediamo con l'upgrade Helm esegue il rendering delle nuove risorse e applica solo le modifiche, mantenendo lo storico:

  
    helm upgrade my-nginx ./my-nginx
  

2. Vedere la cronologia delle modifiche

Ogni aggiornamento crea una nuova revisione. Puoi vedere lo storico con:

  
    helm upgrade my-nginx ./my-nginx
  

Verifichiamo i cambiamenti fatti:

  
    kubectl get all
  

3. Effettuare un rollback (helm rollback)

Se un aggiornamento fallisce, o crea problemi, puoi tornare a una versione precedente:

  
    helm rollback <release-name> <revision-number>
  

Torniamo alla release 1 con una sola replica.

  
    helm rollback my-nginx 1
  

Questo comando annulla le modifiche e ripristina la versione precedente.

Verifichiamo i cambiamenti fatti:

  
    kubectl get all
  

4. Disinstallare una release (helm uninstall)

Per rimuovere completamente l'app e le risorse collegate:

  
    helm uninstall my-nginx
  

Eliminazione eseguibile manualmente tramite Helm e folder my-nginx con i seguenti comandi:

  
    sudo rm /usr/local/bin/helm

    sudo rm -rf my-nginx
  

Controlla che le risorse siano state eliminate:

  
    kubectl get all
  

Comandi: suggerimenti utili

Comando	Descrizione
helm template	Mostra i file YAML che verrebbero generati
helm lint	Controlla la correttezza del chart
helm get values <release>	Visualizza i valori usati nel rilascio
helm diff upgrade (plugin)	Mostra le differenze tra due versioni