Retour d'expérience Kubernetes

Salut,

avoir de la HA pour passer des soirées / weeks + serein, et accessoirement pouvoir se couper du net 2/3 jours sans crainte d'avoir un serveur down... L'astreinte permanente c'est usant dans le temps (et pourtant les pannes sont rarissimes).

OK, je pense qu'on a un peu le même genre de vie :D
Le HAProxy j'y ai pensé aussi pour faire de la haute dispo.
Le truc c'est que les problèmes proviennent très souvent des parties mal maîtrisées. Et j'avance plus que prudemment quand je fait évoluer ma gestion des infras.

Tu comptes t'appuyer sur https://help.ovhcloud.com/csm/fr-load-balancer-loadbalancer-introduction?id=kb_article_view&sysparm_article=KB0044252 ?

Je crains d'un côté que la montée en complexité pose + de problèmes qu'elle n'apporte de solution...

Oui voilà. Ensuite tout dépend de la typologie de tes clients. Ont-il vraiment besoin de haute dispo sachant que cela va leur coûter plus cher ?

De l'autre je me dis qu'il va bien falloir un jour que j'évolue sur ma façon de bosser... Le bon vieux baremetal et les scripts bash c'est passé de mode :)

Mouuuuai. Je pense qu'il y a encore qq belles années devant nous car
- le "cloud" ça reste incroyablement cher quand tu compares le rapport prix/perf.
- c'est complexe, et ça peux ajouter des SPOF
- ça enferme les utilisateurs quand tu veux migrer sans parler des frais de sortie.

Perso je n'ai pas du tout les moyens d'embaucher, et mon idée serait plutôt de trouver un partenariat pour assurer des astreintes à ma place. J'avais un candidat (un de mes partenaires) mais il fait faillite...

Aucun client ne t'a demandé ce qu'il se passait s'il t’arrivais qq chose de grave ? Perso j'ai 2 potes "historiques" qui font de la presta et qui assureront les tâches techniques. Mais ce n'est pas l'idéal.

PS : en ce moment je réfléchi à améliorer mon PRA en ayant une machine (avec des DD méca) sur laquelle j'ai un slave Mariadb répliquant toutes les BDD de tous les serveurs + synchro Rsync toutes heures ou moins.
En cas de problème grave, je n'ai qu'à modif l’affectation de l'IP pour que la prod reprennent en mode dégradé. Avec l'API il doit aussi être possible d'automatiser ça avec une sorte de watchdog.
Pas sur que ce genre de solution soit vraiment chouette, l'idée, comme toi c'est de pouvoir avoir des week-end et des vacances plus tranquilles.

Hello,

Alors côté "infra" je pense à un système du genre 3 serveurs maître en PCI, avec un anti affinité pour que les 3 vms soient sur des hosts différents.
Ensuite du baremetal, adv1 ou 2, l'idée étant d'avoir plusieurs serveurs moyens plutôt que peu de gros, histoire de perdre - en % si un serveur tombe.
Pour la couche réseau, l'ensemble des offres cloud ici : https://www.ovhcloud.com/fr/public-cloud/network/
- Le vrack pour le rzo privé entre les serveur.
- la gateway pour assurer l'accès du net vers le vrack, tout en pouvant utiliser les "Floating IP".
- le LB pour l'accès aux nodes master, et éventuellement pour les clients qui auraient plusieurs frontaux.

Mon soucis étant que concrètement, les pannes sont rarement pour des questions matérielles, mais essentiellement logicielle. Cette infra est censée me "protéger" contre les soucis hardware... La partie software il y a bien des mécanismes d'auto restart des pods en cas de problème, mais pas dit que ce soit bien utile.

Et comme dit, rajouter de la complexité risque en fait d'augmenter le travail de maintenance, pour ça qu'il faut 1 gros cluster et virer les VMs autonomes.
Quand on voit qu'une debian on la pose, et on l'oublie pour 5 ans. K8s lui est mit à jour tous les trimestres, et il faut impérativement faire la montée de version 1x / an mini... Avec des changements sur l'API et tout...

Côté client j'ai commencé à en parler aux + gros, mais vu que pour le moment je n'ai pas pu chiffrer ce que je vais pouvoir facturer c'est difficile de dire avec précision pour quel client ça peut être intéressant. Je ferai un mail généralisé début janvier avec les voeux de nouvelle année pour leur demander leur avis.

Pour le moment les clients qui m'ont demandé de la HA, qd j'ai fait le devis, ils ont tous fait marche arrière... Car oui, c'est bcp + cher, pour un uptime guère + intéressant (surtout que ça ne protège pas d'un hack sur un site par exemple).

Le côté HA / infra évolutive c'est + pour moi...
L'idée étant d'avoir mon cluster, que je fait monter progressivement, pour au final n'avoir qu'une infra à gérer et pas 50+ serveurs. Permettre à mes clients une + grande flexibilité (scalling vertical / horizontal).
L'autre intérêt c'est les montées de version côté OS, et séparer au maximum la partie app et la partie OS. Mais ça à la limite je peux avoir des résultats proches avec des containers. C'est une alternative à laquelle je réfléchis...
A la migration on déplace tt le container avec sa conf et ses datas, et ça tourne de la même façon quelque soit l'os en dessous...


Bref, c'est vraiment une réflexion de fond, pour une mise en prod pas avant 2025, voir septembre 2025 avec la fin du support de deb11 l'année suivante...


----------


Côté PRA pour le moment j'ai mon serveur de backup qui rassemble tout.
En dehors de l'incendie je n'ai jamais vraiment eu le besoin de spawn une VM en urgence pour remonter un service. J'ai bien du le faire 1x ou 2 pour pouvoir bosser tranquillement sur un baremetal avec un soucis hardware, mais c'est exceptionnel.
Et pour réinstaller une VM j'ai des scripts qui font quasiment tt le job... Donc commande de la VM, scripts de réinstall, on réinjecte les datas, c'est assez efficace...



----------


Ensuite pour le partenariat. Oui j'y pense aussi depuis lgtps... Le soucis étant de trouver quelqu'un de fiable / de confiance. Pis faut harmoniser les process pour pouvoir facilement prendre le relais en cas de problème, documenter un max pour ne pas laisser l'autre dans la mer... en cas de problème...
Et à voir le type de partenariat, uniquement en période de congés / maladie ? Astreinte alternées les week end ? Prendre de + gros projets ?
Mais ça c'est un autre sujet, qui mériterait pourquoi pas un sujet ici... Un genre de groupement d'indépendants pour pouvoir partir en vacance :)
Je plaisante, mais ça mérite réflexion, passé le cap de la confiance vu qu'on donne l'accès aux datas des clients !

Je remets une pièce dans la machine.
Pour le moment, + je creuse, - cette solution (kubernetes) m'intéresse.
Elle n'est pas adaptée à mon usage (des clients sans compétences techniques qui vont gérer du wordpress essentiellement).
C'est complexe (même si ça, on peut apprendre), c'est bcp trop instable avec de nbreuses mise à jour / an.

Bref, je creuse sur d'autres solutions. J'ai proxmox qui me fait de l'oeil en mode cluster, mais là pareil, qd je prends la calculatrice, que je fais mes simulations c'est de suite + cher, et qd j'en parle aux clients, ils ne sont franchement pas motivé de payer +.
Vu que de toute façon, même sans HA mes serveurs sont tous à 99% d'uptime mini, et souvent 99,9%.... La HA me permettrait de gratter le 99,99%, mais ça, mes clients s'en tapent...

bref, reste à faire le distinguo entre la volonté de se faire plaisir techniquement, et le fait de livrer des solutions qui répondent aux besoins clients pour le meilleur prix...

Dans tous les cas, creuser de nvlles solutions c'est tjrs intéressant pour sa veille techno !

Bonjour,

Je mets une petite pièce moi aussi, car je dirais que les technos genre Kubernetes sont quand même faits pour des "use case" relativement spécifique et à partir d'une certaine échelle.

Pour faire du cluster proxmox (pas chez OVH), c'est quand même plus "simple" sur le principe (== suivre les MàJ proxmox qui eux-mêmes suivent le cycle Debian) et notre cas d’utilisation et si on reste sur un "petit cluster" (je parle de 100 à 200 VMs) ou les VMs elles ne bougent pas, mais sont en mode HA car si on perd un nœud la VM se fait reboot sur un autre nœud en moins de 5 minutes avec un "simple" restart d'un point de vue OS (comme si l'os a perdu le courant), les données étant sur du stockage ceph lui aussi gérer via l'interface proxmox.

Note : après c'est peut être dû au fait que je n'utilise pas ces technos, même les containers style docker je n'utilise pas (sauf si l'éditeur nous l'impose).
Faut pas oublier qu’à l'intérieur d'un docker reste construit sur base d'une image d'os (si j'ai compris cette doc : https://docs.docker.com/get-started/02_our_app/)
Attention par contre je trouve cette techno super pour un dev qui veut être sûr de fournir une application qui marche sur n'importe quel infra (ou presque) et surtout souhaite la maintenir "facilement" (encore une fois, de ce que je comprends de la techno).

Cordialement, janus57

Yep proxmox c'est vraiment bien.
Entre la réplication, le storage CEPH géré par proxmox, ou le stockage externe, on arrive assez facilement à faire de la HA avec un downtime très faible.
Et on reste sur de la techno très "standard". Et comme dit, le cycle de vie est long ce qui évite d'avoir à courir derrière la dernière version en permanence.

Les containers ont aussi leurs use case, notamment pour les dev c'est le top.
Et kubernetes répond bien à la gestion de container, mais il faut en avoir l'utilité.

Bonjour,

Et on reste sur de la techno très "standard".

je dirais totalement standard vu que KVM c'est intégré au noyau Linux depuis la version 2.6.20 et CEPH est pour moi utilisé par pas mal de boites et surtout largement soutenu (Cf : https://ceph.io/en/foundation/members/).

Et kubernetes répond bien à la gestion de container, mais il faut en avoir l'utilité.

Il faut surtout avoir une infra qui soit capable de tourner à 100% dans des containers pour pouvoir l'associer a du cluster K8S.

Cordialement, janus57

Salut @Sich,

Tu as réussit à avancer ce le sujet ?

Alors, j'ai creusé oui.

Côté k8s aucun intérêt dans mon use case au final.
ça rajoute de la complexité pour rien, et vu le "cycle de développement" c'est un vrai bordel à maintenir, vu qu'en + il faut maintenir tout ce qui tourne autour.
A la limite partir sur une solution maintenue par OVH, pour réduire ce boulot de gestion, mais même là, pas intéressant (dans mon cadre de fonctionnement).

Côté proxmox c'est vraiment une bonne solution, et ça conviendrait parfaitement à mes besoins. Sauf que mes clients, au vu du climat économique actuel, ne sont pas motivés par de la HA. Leur baremetal (voir VPS selon les cas), fonctionnent très bien, les downtimes sont exceptionnels, et au vu de leur activité, ils préfèrent avoir un down de temps à autre, plutôt que de payer x2 voir x3 toute l'année.
En gros, la différence de coût pour passer de 99% (voir 99,9%) d'uptime à 99,99% n'est pas pertinent (pour mes clients en tt cas).

Moi j'avoue que j'aurai préféré partir sur une infra "ha" pour mes clients, à base d'host sous proxmox et des vms pour les clients. Mais, comme je dis souvent, c'est celui qui paie qui décide :)

Après il y a la solution de monter des VMs dans le même scénario mais sans la HA. Mais là bof, les VPS OVH sont vraiment pas mal, avec un rapport puissance / prix très intéressant, et ça m'évite à la fois la maintenance de l'infra et le coût initial (même si au vu de mes clients j'ai de quoi remplir quelques baremetals de vms)...

Donc standby, on verra si les "prévisions économiques nationales" reviennent dans le vert. Entre l'inflation qui a bien tué le pouvoir d'achat, l'IA qui mets à mal le monde du SEO, et Macron qui veut jouer au petit soldat, ce n'est pas très pertinent de se lancer dans des investissements et de perturber "ce qui fonctionne".

Je ferai probablement un "point de situation" l'année prochaine.

Merci pour ton retour !

Je suis en train de réfléchir à prendre un serveur de spare avec des disques mécaniques.
Dessus je :
- met un mariaDB configuré en slave (tunellé sur la master avec Wireguard)
- configure tous les hébergements client de prod avec une synchro rsync ssh régulière (régulière)
- Rsync également des vhost, pool PHP etc.
- toutes les adresses IP FO des serveurs de production seront déjà configurées dessus

Un serveur de prod me claque un disque ou autre
- Je reçois l'alerte SMS
- Je me connecte sur le manager et route l'IP FO Apache et Postfix sur le serveur de spare

La prod peut continuer... En mode dégradé, mais c'est déjà ça.

Le coût de cette solution est minime, je ne compte même pas augmenter les tarifs, juste me donner de la tranquillité.
Je me goure dans mon raisonnement ?

c'est pas mal, après t'as une solution proxmox avec ça, où tu peux définir une synchro vers un autre serveur. Après tu peux basculer d'un serveur à l'autre assez facilement.
J'ai commencé à réfléchir à ça aussi.
Avec 3 serveurs tu peux avoir une bascule automatique. Prévoir le vrack et les ips "flottantes" pour gérer la bascule des IPFO + facilement.

Du genre 3 serveurs, divisé en 2, l'un avec sql, l'autre avec apache/php et le 3° avec nginx en reverse proxy/cache. Avec serveur A copié régulièrement sur B, serveur B sur C et C sur A. ça permet d'automatiser un peu le truc et que chaque serveur "bosse" en permanence.

Mais me semble que la synchro comme ça n'est pas très "mysql friendly" et qu'il est en effet recommandé d'utiliser les tools sql (cluster, slave, etc) plutôt que de la réplique au niveau disque.

Mais ta solution est probablement + économique, et te permet de garder intégralement le contrôle de la situation.
Après de mon côté chaque client est sur son serveur, je n'ai pas un gros serveur à moi avec tous mes clients dessus. Donc "au pire" c'est 1 client down. Et, en dehors d'un incendie (hum), un down complet est exceptionnel.

C'est tjrs le problème de faire la part des choses entre le coût (complexité + financier) et la disponibilité. Perso j'ai une 60aine d'hosts à gérer (du vps au baremetal), donc gérer une "réplique" pour chaque serveur risque de devenir rapidement chronophage.
D'où mon idée de monter un gros "cluster" avec des baremetal à moi et rassembler mes clients dessus. Mais j'ai beau tourner le truc dans tous les sens, en prévoyant du spare en cas de défaillance d'un host, mes coûts sont forcément + élevés qu'une solution tt simple...
Et le coût additionnel à ce jour les clients ne veulent pas en entendre parler...

Mais ta solution est probablement + économique, et te permet de garder intégralement le contrôle de la situation.

J'exploite des serveurs SYS... Pas de vrack.

Après de mon côté chaque client est sur son serveur, je n'ai pas un gros serveur à moi avec tous mes clients dessus. Donc "au pire" c'est 1 client down.

Ha effectivement.
Mon chiffre est principalement généré par de l'hébergement mutu.

Perso j'ai une 60aine d'hosts à gérer (du vps au baremetal), donc gérer une "réplique" pour chaque serveur risque de devenir rapidement chronophage.

Ha oui quand même !
22 pour moi. L'immense majorité est strictement identique (matériel et config) ce qui accélère vraiment l'info gestion. Je suppose que dans ton cas chaque machine est plus ou moins unique.

D'où mon idée de monter un gros "cluster" avec des baremetal à moi et rassembler mes clients dessus. Mais j'ai beau tourner le truc dans tous les sens, en prévoyant du spare en cas de défaillance d'un host, mes coûts sont forcément + élevés qu'une solution tt simple...

Je comprends. il te faudrait un cluster avec un hyperviseur en fait.

Merci bcp d'avoir pris le temps de me répondre :)

Les serveurs ont des configs "par lot".
Dans le sens où j'ai des config de Debian10 à Debian12.
Les Deb10 en cours de suppression.

Mais au sein d'un groupe les configs sont très proches, quelques ajustements parfois pour les besoins client, mais ça reste assez "cohérent" dans l'ensemble.

Et oui, soit du private cloud (mais ça coûte un bras), soit un cluster proxmox avec des vms répliquées sur 2 serveurs, voir via un storage centralisé (j'étais plutôt parti là dessus).
Mon idée était de prendre des adv2, démarrer à 3, les remplir avec les clients qui ont des VPS, augmenter progressivement le nbr de serveur host, pour ensuite passer aux clients sur baremetal, quitte à leur faire des configs en load balancing pour "répartir" la charge sur plusieurs vm/serveurs.

Mais comme dit, je n'arrive pas à sortir quelque chose de pertinent à des prix proches, le surcoût peut être conséquent (surtout sur les + gros clients).
Dommage, car le confort de travail aurait été nettement meilleur pour moi.

Ce sujet a été automatiquement fermé après 180 jours. Aucune réponse n'est permise dorénavant.