Hello,
Je suis en train de faire des tests sur le service kubernetes géré par OVH.
Bon, j'ai tout à apprendre, mais ça rentre doucement.
Toutefois, j'ai une question.
Si l'on souhaite monter un PVC rwx pour pouvoir le partager entre plusieurs pods/réplicas il faut un service externe (nas-ha, ceph, etc) et non pas les "disques additionnels" de base.
Mais comment intégrer ça convenablement à kubernetes ? Notamment la communication réseau, cela passerait par la gateway sur le vrack ? Par l'ip publique des nodes ?
D'après ce que je vois, seule l'entreprise file storage est compatible vrack... Or pour pouvoir bénéficier de la vitesse du rzo privé il faut passer par le vrack non ?
Et l'entreprise file storage 4k IOPS our 1TO.... mouais, pas foufou... Et non, je n'ai pas besoin de 10To...
Utiliser k8s uniquement avec des disques rwo réduit un peu l'utilité du truc... Même si, théoriquement, en cas de défaillance d'une node, le service est transféré en quelques minutes sur une autre node... Mais ça empêche de scaller horizontalement...
Autre question, est-il possible d'utiliser des ipv6 ? Il me semble que l'on peut associer un /64 à son vrack, mais quid de la compatbilité avec le lb k8s d'ovh...
Là actuellement qd je déclare un service de type lb, ça me crée automatiquement une ip flottage qui est rattachée à mon pod... Qui je présume va se connecter au lb k8s pour envoyer les requêtes sur le bon pod...
L'usage de l'ipv6 permettrait d'économiser les 2€ / ip et accessoirement d'être compatible ipv6... Vu que bon, il parait que c'est la fin d'ipv4 et que l'on doit faire un effort pour être compatible ipv6...
Accessoirement pour des sites derrière cloudflare, on peut être full ipv6 sans risque...
Bonjour Sich,
Désolé pour ce retour tardif. As-tu trouvé réponses à tes questions?
FabL
Salut,
Alors, où j'en suis dans mes tests.
Je suis en train de tester d'avoir mon propre cluster mixte entre PCI (master) et baremetal (worker).
- N'avoir que des vms pci revient trop cher (rapport puissance / prix).
- Ne pas pouvoir gérer les hosts limite ce que je peux faire (worker qui font cluster ceph également pour démarrer).
Pour les réponses que j'ai trouvé, tu me dis si je me trompe.
- Pour les disques rwx, c'est forcément du cephfs ou nfs, la connexion passe par la sortie "publique" de l'host. En utilisant un bloc d'ipfo l'host utilise sa carte rzo vrack, donc 25Gbs sur de l'adv. Par conséquent, pas besoin d'avoir de l'entreprise storage compatible vrack, sauf effectivement à rester sur un cluster k8s ovh avec auto scalling, là, il faut vraiment passer l'entreprise storage je pense.
- Les disques rwo only posent trop de limitation (pas de scalling horizontal). Les disques rwo associé au PCI sont trop lent pour les bdds (quasiment seul intérêt de ces disques). En ayant mon propre cluster, je peux faire du local storage avec un cluster mariadb galera, voir mon propre cluster ceph (en test, mais devrait être + performant).
- Pour les ips publiques, le load balancer, je passe par metal lb et j'utilise des ips du range ipfo avec lequel je configure les ips publiques des worker, ça répond parfaitement à mon besoin.
- Pour l'ipv6, idem, on rattache un /64 au vrack et on l'utilise directement, super pratique.
- Pour utiliser plusieurs GW je n'ai pas encore testé + que ça, c'est du "mode avancé" que je laisse de côté pour le moment.
Je fais mes tests sur mon temps libre, donc je n'avance pas tjrs aussi vite que je le souhaiterai, surtout que je suis tout nouveau dans le monde de l'orchestration et j'apprends progressivement.
Je passe en mode réponse pour remonter le topic.
J'avance sur l'utilisation de k8s, ça a ses avantages/inconvénients.
Concernant l'offre managed, je n'ai rien trouvé dans la doc à propos de la montée de version majeur, c'est possible ? Seules les majs mineurs sont possibles ?
Dans ce cas, comment se passe la bascule sur une nouvelle version ? On configure un autre cluster, on déploie les services, mais pour les datas ? Je présume qu'on ne peut pas rattacher les disques storage existants (- gênant pour un storage centralisé), idem pour les IP associées, on peut "facilement" les transférer sur le nouveau cluster ?
Vu que les ips sont "commandées" directement via kubectl, je présume qu'il y a quelques manips à faire.
A la limite, configurer un nouveau cluster, déployer la config, n'est pas + mal que d'upgrader ce qui est déjà en prod, mais pouvoir transférer facilement data (additionnal disk) et IPs publiques, ça c'est important.
Côté storage partagé, qu'est ce qui est préconisé ? Cloud Disk Array powered by Ceph ? L'offre n'a pas l'air compatible vrack, en tout cas je n'ai rien lu à ce sujet.
On peut monter des disques RWX facilement avec ça ? Il n'existe rien en + petit ? 3To c'est assez important... Quid des perfs ?
Prendre un baremetal pour avoir du storage centralisé "casse" un peu l'intérêt du k8s en remettant un SPOF, et une machine à gérer soi-même... Là où avec le k8s managé, je délègue une partie du boulot à OVH...
Je pose bcp de questions, dsl :)