Node Autoscaling / K8s dans une autre région: est-ce que K8s vaut le coup ?

QuentinM15 2020-01-23 16:40:31 UTC #1

Bonjour,
je dois créer un projet pour lequel j'ai une workload variable, qui peut vite grandir. Je pensais utiliser le Kubernetes Managed services, mais je me heurte à deux problèmes:

ce service n'existe pas dans la région dans laquelle mon projet est actuellement (GRA3), je devrais donc créer un nouveau projet. Je ne compte pas migrer de région, car j'ai une DB dont j'ai besoin. Il n'y a à ma connaissance pas de possibilité de créer un private network à travers deux projets, ce qui veut dire que mes instances devraient communiquer avec la DB hors private network, ce qui est lent et peu sécurisé
il n'existe pas de système de node auto-scaling pour le moment. Certains des jobs peuvent être CPU-intensifs/RAM-intensifs, déployer un nouveau pod ne suffit donc pas, il faudrait donc que j'implémente une stratégie de gestion des instances à la main

Étant donné ces problématiques, est-ce que j'aurai loupé une solution simple à l'un de ces problèmes ? Est-ce que k8s est la bonne solution tout de même ou vaut-il mieux que je développe un système de gestion d'instances hors k8s ?
Merci,
Quentin

MaximeH1 2020-01-23 17:22:53 UTC #2

Bonjour !

Le node autoscaling est bien prévu plus tard dans l'année. Nous allons tout prochainement exposer la notiond e nodes pools pour faciliter votre propre resising en attendant le cluster autoscaling.

Concernant le premier point, vous pouvez demander au support d'ajouter la région GRA7 à votre projet actuellement à GRA3 (une inteface sera disponible prochainement aussi pour vous permettre de le faire). Le service Kubernetes managé n'est effecttivement pas encore compatible avec le vRack (prévu également en roadmap) pour la connection à votre database, il faudra donc plutot utiliser le chiffrage et/ou le whitelisting d'IP entre temps s vous partez sur cette solution.

QuentinM15 2020-01-24 07:45:52 UTC #3

Bonjour,
Merci de votre réponse rapide, effectivement ce service manque un peu de features...
Pour ce qui est de la node pools, pouvez vous préciser une deadline, pas que je recode une feature qui sort dans une semaine ;-)
Je vous remercie pour l'idée du chiffrage/whitelisting, cela règle en effet le problème de sécurité mais pas celui de la performance..
Merci,
Quentin

MaximeH1 2020-01-24 08:01:11 UTC #4

Merci de cotre confiance ! Je vous confirme qu' on fait tout pour proposer le vRack au plus vite mais c est un changement de fond qui impacte de nombreuses equipes chez OVH.
Pour les node pools, L'ETA est dans 1 mois, à 2 semaines près.

ENTSOEC 2020-03-04 08:19:45 UTC #5

Bonjour @MaximeH1,

Quelle est la roadmap pour le vRack entre dedicated server et KMS? Et pour le Node Pool?

Merci

MaximeH1 2020-03-04 13:12:54 UTC #6

Bonjour @ENTSOEC pour Node pool, c'est dans le mois qui vient. Pour vRack entre dédiés et Kubernetes, je n'ai aps encore d'ETA avec commit des équipes, mais je confirme que ça sera fait et est dans nos priorités.

ENTSOEC 2020-03-05 05:46:12 UTC #7

Bonjour @MaximeH1,

Donc, on peut parler pour Mars ou Avril pour le Node Pool?

pour le vRack, c'est dommage que cela ne soit pas implémenté, surtout quand on sélectionne l'option à la fois sur un dedicated et sur le kubernetes, parce que je ne pense pas que cela soit indiqué dans l'option que le vRack ne couve pas ces deux produits.

MaximeH1 2020-03-06 18:53:56 UTC #8

@ENTSOEC Mars ou Avril oui, je ne peux pas m'engager plus précisément, le developpement restant (UI) n'est pas directement dans mon équipe ;)

Je vous confirme que le vRack sera proposé, là aussi j'ai une dépendance à une autre équipe dont j'attends un ETA ;)

PaulG4 2020-05-27 14:44:07 UTC #9

Bonjour,

Y a-t-il un update d'ETA pour le node autoscaling ?

Merci

MaximeH1 2020-05-27 15:09:51 UTC #10

Nos targetons actuellement le 22 Juin pour les nodes pools (à quelques jours près). A noter que dès cette date, vous pourrez resizer un node pool par un simple changement de paramètre sur une proprieté d'une CRD dans le cluster Kubernetes.
L'ETA pour l'autoscaling fonction CPU/RAM est maintenant plutot pour Juillet/Aout

CyrilB30 2020-05-29 13:27:59 UTC #11

Bonjour des news du Nodepool ?

MaximeH1 2020-05-30 20:32:54 UTC #12

xorel 2020-06-20 13:06:41 UTC #13

Hello, est-ce que l'on est toujours sur une date prévue pour la semaine prochaine ? Je croise les doigts car ce serait la cerise sur le super boulot que vous avez effectué jusqu'à présent sur k8s :)
Du coup, je me dis que vous allez de même apporter les modifications suivantes :
- création d'un noeud plus rapide, maintenant pour créer un nouveau noeud dans un cluster il faut compter environ 10 minutes voir parfois plus. Pour de l'autoscaling horizontal de noeuds il est évident que ceci n'est pas viable si on a une montée en charge, le temps que le nouveau noeud s'ajoute la charge sera sûrement terminée. Du moins c'est le comportement que j'ai quand j'ajoute simplement un noeud de mon côté.
- ajout du ReadWriteMany. Si j'ai bien suivi pour le moment ovh ne supporte que le RWO et du coup si on a une montée en charge avec autoscaling horizontal sans RWMany on perdrait alors en utilité.
Me confirmez-vous ceci ?

Merci à vous :)

MaximeH1 2020-06-20 16:41:39 UTC #14

Bonjour

La mise en production va glisser de quelques jours, surement tout début juillet. Nous sommes actuellement en QA et traduction de la feature, et nous peaufinons le focntionnement de la CRD qui vous permettra de piloter directement les nodes pools via kubectl, sans installation de plugin.

Je comprends votre retour sur la création de noeuds. Vous avez du normalement noter une première amélioration ces derniers jours, et nous devons dans la plupart des cas tomber sous les 10 minutes mais oui nous avons encore du travail à faire pour améliorer cela. Nous allons aussi permettre la parallélisation des créations des noeuds d'un node pool.

Concernant un stockage en RWX, c’est effectivement une demande très récurrente que nous avons prévu de couvrir dans l'année à venir avec nos collègues qui travaillent sur un FSaaS. Je n'ai malheureusement pas de date à ce stade. Un contournement actuel est d'utiliser les NAS-HA proposés par OVHcloud (avec le RWX, la performance mais pas la granularité des block storages). On est entrain de peaufiner un guide : https://github.com/mhurtrel/docs/blob/patch-3/pages/platform/kubernetes-k8s/configuring-multi-attach-persistent-volumes-with-ovh-nas-ha/guide.en-gb.md (en cours de relecture)

xorel 2020-06-20 19:27:42 UTC #15

Ma foi ce lien a l'air intéressant je vais essayer cela de suite. Comme cela je verrai si je peux attendre le RWX pour la mise en production. Un tout grand merci.

GuilhemB2 2020-11-03 11:46:03 UTC #16

Des nouvelles de l'auto-scaler ?

A noter que j'ai aperçu un auto-scaler OpenStack dans les sources Kubernetes : https://github.com/kubernetes/autoscaler (cf. cluster-autoscaler/cloudprovider/magnum/). Est-ce une solution utilisable ? Ou déjà utilisée par d'autres clients ?

MaximeH1 2020-11-25 10:56:52 UTC #17

Bonjour

Vous pouvez désormais suivre ces features sur https://github.com/ovh/public-cloud-roadmap/projects/1 et être notifié de leurs avancées

Propulsé par Discourse, le rendu est meilleur avec le JavaScript activé

OVHcloud Community

Bienvenue sur votre espace communautaire. Posez des questions, recherchez des informations, publiez du contenu et interagissez avec d’autres membres d'OVHcloud Community.