Posté par oau .
En réponse à la dépêche Harbor 2.0.
Évalué à 1.
Je pense qu’on s’est mal compris. Le posgresql en sus qui tourne dans ceph et qui est un replica de la production qui tourne sur des disques en local n’est là que pour avoir la possibilité d’en faire un snapshot.
Mais tout est géré par k8s. Aussi bien le cluster de postgres de prod qui est géré par helm et qui a un Persistent Volume local géré aussi par k8s, et le postgres en sus qui est une image docker que j’ai faite mais qui est géré aussi par k8s (dans un statefulset) et qui a un Persistant Volume dans ceph et enfin les Snaphot de la base dans ceph sont eux aussi géré par k8s via la fonctionnalité de Snapshot de k8s. Je ne fais absolument rien hors de k8s.
Pour clarifier la gestion sur stockage dans k8s. Il y a plusieurs choses.
Le plus simple c’est le stockage éphèmere. Le container écrit sur le disque local du node qui le fait tourner. Quand le container s’arrête tout est perdu.
Ensuite on a la couche stockage persistant. On a d’abord un type storageclass. Dans mon cas j’en ai deux. Une locale et une pour ceph.
Pour la locale je dois créer à la main les lv et les assigner ensuite dans un Persistant Volume (PV), je ne crois pas qu’on puisse encore lui donner un vg et débrouille-toi pour créer les lv.
Pour ceph c’est plus simple. Je crée un Persistant Volume Claim (PVC) qui va créer automatiquement le PV avec la bonne taille.
Avec tout ça il y a un volumesnapshotclass et un volumespnashot qui vont me permettre de créer des snapshot de mes PVC et de les transformer en PV. Ça m’évite de copier 50G de base quand j’ai besoin d’une nouvelle pile pour tester une branche de notre dev.
Là je snapshot mon postgres qui tourne dans ceph et je démarre un nouveau postgres sur le PV créé à partir du snaphost. Merci à postgres d’être capable de se relancer proprement à partir d’un snapshot totalement inconsistant. J’ai vu qu’une commande fsfreeze existait mais pour le moment ça marche.
Donc maintenant j’ai mon pvc.
Si je l’utilise dans un déploiement tous mes pod vont pouvoir y accéder. J’ai donc un volume partagé entre tous mes pods.
Si je l’utilise dans un Statefulset un seul pod pourra utiliser mon pvc et le nom du pod sera fixe.
En tout cas, je note que l'on est loin d'avoir une solution pérenne et performante
pour gérer les données persistantes dans k8s.
Je ne suis pas d’accord avec ça. Depuis l’arrivée des Statefulset ce n’est plus le cas.
Tu ne peux pas avoir un soft qui se créait sa propre base de donnée et l'utilise (par > exemple avec helm).
Si tout à fait. C'est le cas de gitlab, de owncloud par exemple. Tu leur donnes le nom de ta storageclass et ils se débrouillent.
[^] # Re: container compatible OCI ?
Posté par oau . En réponse à la dépêche Harbor 2.0. Évalué à 1.
Je pense qu’on s’est mal compris. Le posgresql en sus qui tourne dans ceph et qui est un replica de la production qui tourne sur des disques en local n’est là que pour avoir la possibilité d’en faire un snapshot.
Mais tout est géré par k8s. Aussi bien le cluster de postgres de prod qui est géré par helm et qui a un Persistent Volume local géré aussi par k8s, et le postgres en sus qui est une image docker que j’ai faite mais qui est géré aussi par k8s (dans un statefulset) et qui a un Persistant Volume dans ceph et enfin les Snaphot de la base dans ceph sont eux aussi géré par k8s via la fonctionnalité de Snapshot de k8s. Je ne fais absolument rien hors de k8s.
Pour clarifier la gestion sur stockage dans k8s. Il y a plusieurs choses.
Le plus simple c’est le stockage éphèmere. Le container écrit sur le disque local du node qui le fait tourner. Quand le container s’arrête tout est perdu.
Ensuite on a la couche stockage persistant. On a d’abord un type storageclass. Dans mon cas j’en ai deux. Une locale et une pour ceph.
Pour la locale je dois créer à la main les lv et les assigner ensuite dans un Persistant Volume (PV), je ne crois pas qu’on puisse encore lui donner un vg et débrouille-toi pour créer les lv.
Pour ceph c’est plus simple. Je crée un Persistant Volume Claim (PVC) qui va créer automatiquement le PV avec la bonne taille.
Avec tout ça il y a un volumesnapshotclass et un volumespnashot qui vont me permettre de créer des snapshot de mes PVC et de les transformer en PV. Ça m’évite de copier 50G de base quand j’ai besoin d’une nouvelle pile pour tester une branche de notre dev.
Là je snapshot mon postgres qui tourne dans ceph et je démarre un nouveau postgres sur le PV créé à partir du snaphost. Merci à postgres d’être capable de se relancer proprement à partir d’un snapshot totalement inconsistant. J’ai vu qu’une commande fsfreeze existait mais pour le moment ça marche.
Donc maintenant j’ai mon pvc.
Si je l’utilise dans un déploiement tous mes pod vont pouvoir y accéder. J’ai donc un volume partagé entre tous mes pods.
Si je l’utilise dans un Statefulset un seul pod pourra utiliser mon pvc et le nom du pod sera fixe.
Je ne suis pas d’accord avec ça. Depuis l’arrivée des Statefulset ce n’est plus le cas.
Si tout à fait. C'est le cas de gitlab, de owncloud par exemple. Tu leur donnes le nom de ta storageclass et ils se débrouillent.