❯ storage · Running

Stockage objet compatible S3 avec MinIO S3-Compatible Object Storage with MinIO

Déploiement de MinIO sur Kubernetes comme stockage objet compatible S3 auto-hébergé — utilisé pour les backups Longhorn et le stockage d'artefacts. Deploying MinIO on Kubernetes as a self-hosted S3-compatible object store — used for Longhorn backups and general artifact storage.

· 2 min de lecture 2 min read ·
k3s-clusterstorageminios3backup
🇬🇧 Read this article in English

MinIO : S3 sans le cloud

Le premier RecurringJob de backup Longhorn n’a jamais backupé quoi que ce soit — pas d’erreur bruyante, juste un job qui tournait dans le vide, parce que le bucket longhorn-backups n’existait pas encore. MinIO ne crée aucun bucket automatiquement, contrairement à ce qu’on attend d’un backend S3 “prêt à l’emploi”.

MinIO est un serveur de stockage objet open-source dont l’API est entièrement compatible avec AWS S3. Déployé sur le cluster, il permet d’utiliser des outils conçus pour S3 (AWS CLI, SDK, intégrations Longhorn) sans dépendance externe.

Cas d’usage dans ce homelab :

  • Backups Longhorn : destination S3 pour les snapshots de volumes
  • Stockage d’artefacts : images Docker buildées localement, archives, logs
  • Expérimentation : tester des intégrations S3 sans coût cloud

Déploiement en mode standalone

Pour un homelab, MinIO en mode standalone (un seul nœud, pas de distributed mode) est suffisant. La résilience est assurée par Longhorn sur le PVC sous-jacent.

containers:
- name: minio
  image: minio/minio:latest
  args:
  - server
  - /data
  - --console-address
  - :9001
  env:
  - name: MINIO_ROOT_USER
    valueFrom:
      secretKeyRef:
        name: minio-credentials
        key: access-key
  - name: MINIO_ROOT_PASSWORD
    valueFrom:
      secretKeyRef:
        name: minio-credentials
        key: secret-key
  ports:
  - containerPort: 9000   # API S3
  - containerPort: 9001   # Console web

Note : minio/minio:latest n’est pas figé — préférer un tag de version explicite pour la reproductibilité des déploiements.

Intégration avec Longhorn

Ce bucket sert de cible aux RecurringJobs décrits dans Stockage bloc distribué avec Longhorn. Configuration dans Longhorn Settings → General :

Backup Target: s3://longhorn-backups@us-east-1/
Backup Target Credential Secret: minio-s3-credentials

Le secret doit contenir les clés AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, et AWS_ENDPOINTS (pointant vers MinIO) :

kubectl create secret generic minio-s3-credentials \
  --from-literal=AWS_ACCESS_KEY_ID=<access-key> \
  --from-literal=AWS_SECRET_ACCESS_KEY=<secret-key> \
  --from-literal=AWS_ENDPOINTS=http://minio.minio.svc.cluster.local:9000 \
  --namespace longhorn-system

Le flux de backup, en mouvement

Le va-et-vient snapshot/backup est plus parlant animé qu’en prose. Les trois temps du cycle s’illuminent à tour de rôle : le snapshot local quotidien (rapide mais lié au disque), l’export hebdomadaire vers le bucket S3 via l’API MinIO, puis la rétention des 4 derniers backups avec restauration possible.

Leçons apprises

Buckets à créer manuellement : créer les buckets nécessaires (longhorn-backups, loki, etc.) via la console web ou le CLI mc avant de configurer les intégrations.

--console-address :9001 est obligatoire depuis MinIO RELEASE.2022-x : sans cet argument, la console web partage le port 9000 avec l’API S3, causant des conflits. Exposer les deux ports via des Services distincts simplifie le routing Traefik.

Chiffrement au repos : pour les données vraiment sensibles, activer le chiffrement côté serveur MinIO. Pour les backups Longhorn, le chiffrement est optionnel si le volume Longhorn source est déjà chiffré.

k3s-clusterstorageminios3backup