Logo
Overview
Un Talos européen de qualité - Part IV - Infra stockage

Un Talos européen de qualité - Part IV - Infra stockage

October 31, 2025
9 min read
part-04

Objectif 🎯

À la fin de la section précédente, nous sommes arrivés à un kube pleinement opérationnel. Il nous reste cependant à mettre en place une réelle solution de stockage distribuée. Il existe les solutions simples telles que local-path-provisioner , nfs-subdir-external-provisioner, ou encore hetznercloud/csi-driver. Mais ce ne sont pas des solutions réellement viables en production pour des raisons évidentes telles que la résilience, la haute disponibilité, la sauvegarde/restauration, etc.

Les 3 solutions de stockage distribuées les plus connues sont :

Dans le cadre de ce guide, nous partirons sur Longhorn, qui me semble le plus équilibré au regard des capacités en ressources des VPS Hetzner et de la taille de notre cluster.

Longhorn

clusters/dev-kube/locals.tf
locals {
cluster_name = "ohmytalos-dev"
internal_domain = "dev.ohmytalos.com"
s3_endpoint = "https://s3.gra.io.cloud.ovh.net"
s3_region = "gra"
}
clusters/dev-kube/module-storage.tf
module "kube_storage" {
source = "../../modules/kube/storage"
internal_domain = local.internal_domain
longhorn_crypto_key_value = var.longhorn_crypto_key
longhorn_backup_s3_endpoint = "https://${local.s3_endpoint}"
longhorn_backup_s3_access_key = var.longhorn_backup_s3_username
longhorn_backup_s3_secret_key = var.longhorn_backup_s3_password
longhorn_backup_s3_region = local.s3_region
longhorn_backup_s3_bucket = local.cluster_name
longhorn_default_local_replica_count = 2
longhorn_default_volume_replica_count = 2
longhorn_default_taint_tolerations = [
"node-role.kubernetes.io/storage:NoSchedule"
]
}
Explanation

Bien que tous les volumes physiques de base soient déjà chiffrés au niveau OS, nous utiliserons également des volumes chiffrés côté longhorn. Cela ne coûte pas bien plus cher en ressource et permet de notamment de chiffrer les backups, ces derniers étant effectués en mode block.

Configurer les accès S3 pour le stockage des backups. Nous utiliserons OVH, mais n’importe quel fournisseur compatible S3 fera l’affaire. Prenez le même bucket déjà dédié à ce cluster ohmytalos-dev.

La définition du nombre de réplicas selon le niveau de résilience des données est importante. Dans notre configuration actuelle du cluster, nous définissons :

  • 2 réplicas par défaut pour les volumes locaux, qui vivent à travers l’ensemble du cluster. Mettre à 3 si besoin pour plus de résilience.
  • 2 réplicas pour les volumes externes, requis car nous sommes limités à 2 disques externes (un dans chaque nœud) dans la définition du pool de storage de l’étape 2.

La définition des teintes est importantes pour s’assurer que les composants longhorn (manager et engine) soient bien programmés sur tous les nœuds workers.

Plus qu’à lancer un terraform apply pour déployer Longhorn, et tout devrait automatiquement se mettre en place.

Longhorn UI

Sans attendre d’avoir un ingress fonctionnel, vous pouvez déjà vérifier que tout est en ordre en accédant à l’interface web de Longhorn via un kpf -n longhorn-system svc/longhorn-frontend 8000:http et en vous rendant sur http://localhost:8000.

Note

Partie importante en rouge, vous devriez avoir 5 nœuds schedulables.

Longhorn Dashboard

Longhorn Nodes & Disks

Note

Selon la configuration faite à l’étape 2 via les annotations node.longhorn.io/default-disks-config et node.longhorn.io/default-node-tags, chaque nœud doit être correctement étiqueté et avoir un disque local monté sur /var/lib/longhorn, tandis que les nœuds du pool storage doivent avoir en plus un disque externe monté sur /var/mnt/longhorn.

Longhorn Nodes

Longhorn Backup

Note

Assurez-vous que le backup target ait bien un statut Available, afin de valider l’accès au S3.

Longhorn Backup

Nous définirons les backups plus tard dans une prochaine section dédiée du guide.

CloudNativePG

Nous allons maintenant nous pencher sur le déploiement de l’opérateur CloudNativePG, qui nous permettra de monter et gérer des clusters de bases de données PostgreSQL, avec réplication, sauvegarde et restauration automatisées.

modules/kube/storage/cnpg.tf
resource "kubernetes_namespace_v1" "cnpg" {
metadata {
name = "cnpg-system"
}
}
resource "helm_release" "cnpg" {
repository = "https://cloudnative-pg.github.io/charts"
chart = "cloudnative-pg"
version = "0.27.0"
name = "cnpg"
namespace = kubernetes_namespace_v1.cnpg.metadata[0].name
max_history = 2
set = [
{
name = "monitoring.podMonitorEnabled"
value = "true"
},
{
name = "monitoring.grafanaDashboard.create"
value = "true"
}
]
}
resource "helm_release" "cnpg_barman_plugin" {
repository = "https://cloudnative-pg.github.io/charts"
chart = "plugin-barman-cloud"
version = "0.4.0"
name = "plugin-barman-cloud"
namespace = kubernetes_namespace_v1.cnpg.metadata[0].name
max_history = 2
depends_on = [
helm_release.cnpg
]
}
Explanation

En plus de cnpg, nous installons également l’opérateur plugin-barman-cloud, l’outil de prédilection pour la sauvegarde et restauration de PostgreSQL, avec support du PITR. Il s’intègre parfaitement avec CloudNativePG pour gérer les sauvegardes hors cluster.

Le mode plugin est la nouvelle façon recommandée d’utiliser barman cloud sur les dernières versions de cnpg. De fait, nous utiliserons donc les nouvelles images standard de PostgreSQL fournies par cnpg et dénuées du binaire barman cloud. En mode plugin, le barman cloud s’exécute dans un sidecar séparé, ce qui est plus propre et plus flexible. L’explication ici.

L’activation de monitoring.grafanaDashboard.create permet d’exposer des dashboards Grafana pour les clusters PostgreSQL, que l’on utilisera plus tard dans la section dédiée au monitoring.

Un petit coup de terraform apply et voilà, l’opérateur CloudNativePG est prêt à être utilisé pour la création de clusters PostgreSQL. Nous verrons cela plus tard dans une section dédiée aux bases de données.

Conclusion

Les principaux composants critiques réseaux, CSI et opérateurs de stockage sont désormais en place. Assurez-vous d’avoir un terraform apply propre avant de continuer sur la prochaine partie. Il est enfin temps d’accéder à notre cluster depuis l’extérieur. Suite à la prochaine section pour l’installation de la partie ingress.