Structure d'un chart

Un Chart est un dossier organisé selon une hiérarchie stricte. Helm fusionne les templates/ avec les values.yaml pour produire le YAML envoyé au cluster.

---

Arborescence standard

mon-chart/
├── Chart.yaml          ← métadonnées (nom, version, type, dépendances)
├── values.yaml         ← variables de configuration par défaut
├── charts/             ← sous-charts (dépendances téléchargées)
└── templates/
    ├── _helpers.tpl    ← fonctions réutilisables (Named Templates)
    ├── deployment.yaml
    ├── service.yaml
    ├── ingress.yaml
    └── NOTES.txt       ← message affiché après helm install

---

Chart.yaml — carte d’identité

Champ	Obligatoire	Description
apiVersion	Oui	v2 pour Helm 3
name	Oui	Nom du Chart
version	Oui	Version du Chart (à incrémenter à chaque modification)
appVersion	Non	Version de l’application (souvent utilisé comme tag d’image)
type	Non	application (défaut) ou library
description	Non	Description courte
dependencies	Non	Liste des sous-charts requis

apiVersion: v2
name: ma-super-app
description: Un chart Helm pour mon application web
type: application
version: 0.1.0
appVersion: "1.16.0"
dependencies:
  - name: mariadb
    version: "11.x.x"
    repository: https://charts.bitnami.com/bitnami

---

values.yaml — configuration par défaut

replicaCount: 2
 
image:
  repository: nginx
  pullPolicy: IfNotPresent
  tag: "stable"
 
service:
  type: ClusterIP
  port: 80
 
resources:
  limits:
    cpu: 100m
    memory: 128Mi

Bonne pratique : Ne jamais modifier values.yaml en déploiement. Créer un fichier par environnement : helm install mon-app ./chart -f values-prod.yaml

---

charts/ — dépendances

Contient les sous-charts téléchargés par helm dependency update. Si ton app a besoin de Redis, Helm télécharge le chart Redis ici.

---

Fichiers spéciaux

Fichier	Rôle
values.schema.json	Valide le format des values.yaml (erreur avant deploy si type incorrect)
.helmignore	Exclut des fichiers du package .tgz (comme .gitignore)

---

Workflow : du template à la release

1. helm install       → Helm télécharge le Chart + dépendances
2. Templating         → Fusion templates/ + values.yaml
3. Envoi API K8s      → YAML généré envoyé au cluster
4. Release créée      → Helm stocke l'historique des versions

---

En relation avec

• Architecture — Vue d’ensemble — hub architecture
• _helpers.tpl — fonctions réutilisables dans templates/
• Commandes Helm — helm install, upgrade, rollback