Déployer avec Helm

Helm est le gestionnaire de paquets de Kubernetes : un chart décrit une application complète (Deployments, Services, PVC…) que vous installez et paramétrez en une commande. La plupart des applications open source en proposent un.

Installer un chart

# Installer Helm : https://helm.sh/docs/intro/install/ (brew install helm)

# Ajouter le dépôt du chart, exemple avec Bitnami
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update

# Installer dans votre namespace, avec vos values
helm upgrade --install mon-blog bitnami/wordpress \
  -n <votre-namespace> \
  -f values.yaml

helm upgrade --install crée la release si elle n’existe pas et la met à jour sinon — la seule commande à retenir. Les autres verbes utiles :

helm list -n <namespace>              # les releases installées
helm rollback mon-blog -n <namespace> # revenir à la version précédente
helm uninstall mon-blog -n <namespace>

Les values à surveiller sur Kontainers

Les charts publics sont écrits pour un cluster générique : quatre réglages demandent presque toujours votre attention.

Value (nom usuel)	À mettre	Pourquoi
`service.type`	`ClusterIP` (+ un Ingress)	Beaucoup de charts proposent `LoadBalancer` par défaut — sur Kontainers c’est une option payante limitée à 1 ; l’Ingress mutualisé est inclus
`resources.requests` / `limits`	Requests réalistes, `limits.memory` = requests.memory	La plateforme aligne la limite mémoire sur la request — un chart qui les différencie verra sa limit modifiée
`persistence.storageClass`	`ceph-block-rwo` ou `ceph-filesystem-rwx`	Les deux classes disponibles — la valeur par défaut du chart n’existe pas ici
`ingress.*`	`enabled: true`, `ingressClassName: nginx`, annotation `cert-manager.io/issuer: letsencrypt`	Pour l’exposition HTTPS directement via le chart

Exemple de values.yaml pour un chart typique :

service:
  type: ClusterIP

resources:
  requests:
    cpu: 250m
    memory: 512Mi
  limits:
    memory: 512Mi

persistence:
  enabled: true
  storageClass: ceph-block-rwo
  size: 10Gi

ingress:
  enabled: true
  ingressClassName: nginx
  hostname: app.example.com
  annotations:
    cert-manager.io/issuer: letsencrypt
  tls: true

Si l’installation échoue

Deux causes plateforme reviennent souvent avec les charts publics :

Le chart déploie un composant privilégié (agent nœud, DaemonSet…) → rejet Pod Security ou quota. Cherchez une option pour désactiver le composant en cause ;
Le chart attend une StorageClass inexistante → PVC en Pending. Fixez storageClass comme ci-dessus.

Le diagnostic est le même que pour tout déploiement : checklist, en ajoutant :

helm status mon-blog -n <namespace>
helm get values mon-blog -n <namespace>   # les values réellement appliquées