Lorsque l'on parle d'hébergeur français, on pense rapidement à OVHcloud, Scaleway ou même Gandi. Mais bien d'autres acteurs de taille « intermédiaire » existent et cherchent à se démarquer tant par leur offre que leur approche des produits. Ikoula est l'un d'eux, et il prépare quelques nouveautés.
Créé en 1998, Ikoula est un hébergeur français disposant de ses propres datacenters à Reims (2006) et Eppes (2014), présent dans différents pays d'Europe tout comme dans plusieurs grandes villes françaises.
Il propose de l'hébergement classique (jusqu'à la colocation), des services, de la messagerie, des serveurs dédiés, VPS, instances via un cloud public, du cloud privé/hybride. Mais aussi des services plus clé en main, comme ses applications en déploiement « one-clik », son Cloud PRA (pour Plan de Reprise d’Activité) ou via des partenariats avec Acronis et VMWare. Il est aussi l'un des rares à proposer des NAS Synology (DS115J, DS216J ou RS815+) hébergés.
Il y a quelques années, la société s'est fait remarquer en proposant son offre Micro Serveur, des dédiés à petit prix basée... sur des Raspberry Pi 4, avec seulement une IPv6 (IPv4 en option). Une offre à l'aventure peu banale, à laquelle nous avons consacré un article dans notre magazine papier #3, actuellement en cours de financement.
Lors de notre entretien, Joaquim Dos Santos, le patron de la R&D d'Ikoula, a également accepté de nous parler d'autres projets de l'entreprise, qui a récemment intégré le groupe Sewan.
Cap sur le 10/100 Gb/s
Outre l'évolution de l'offre Micro Serveur, un projet qui doit avancer dans le courant de l'année prochaine, Ikoula est actuellement occupée à une migration de son cœur de réseau. Il était jusqu'à maintenant en 40 Gb/s et passe progressivement à 100 Gb/s, avec de l'agrégation pour les liens de peering lorsque c'est nécessaire.
L'idée défendue par les équipes est de faire monter d'un cran toutes les interfaces réseau, et donc de profiter de l'occasion pour généraliser le 10 Gb/s au niveau des serveurs. Là aussi tout va se faire de manière progressive, le passage à 100 Gb/s ayant déjà pris un peu de retard, il devrait néanmoins être finalisé d'ici la mi-2022 si tout va bien.
Est-ce que l'équipe prévoit l'ouverture d'un nouveau datacenter ? Lors de notre échange, c'est un sujet qui était évoqué, plutôt pour s'étendre hors du nord-est de la France, mais rien de plus concret n'était décidé.
k8s et BMaaS au programme
Du côté des services, il était plutôt question d'un Kubernetes managé, comme le proposent déjà d'autres fournisseurs de services cloud (CSP), notamment en France. Cela doit permettre à ses clients de gérer leurs déploiements en se reposant de plus en plus sur des services internes à Ikoula. Mais aussi à des solutions multi-cloud plus simples à mettre en place, par exemple en utilisant le service Kosmos de Scaleway, désormais ouvert à tous.
Comme ailleurs, la migration des offres vers une dynamique cloud est l'un des points d'attention de l'hébergeur, qui espère bientôt proposer du Bare Metal-as-a-Service (BMaaS), soit des serveurs dédiés mais louables à l'heure plutôt qu'au mois. L'idée semble de tester ce dispositif avec les Micro Serveur RPi 4 avant d'éventuellement l'étendre.
Aucune date précise ne nous a été donnée pour la mise en place de ces nouveautés.
Commentaires (14)
#1
A part pour faire de l’intégration continue, y a des gens ici qui font vraiment de la prod sérieuse sur du k8s?
#2
Chut, tu vas réveiller Sheep
#3
C’est curieux ce passage intermédiaire par le 40G.
Ils passent d’un ratio coeur/accès de 40 à 10, donc il y a certainement un changement de topologie, une augmentation des liens, autre… ? Ça aurait été sympa d’en savoir plus.
#4
Mouai…. On viens de tester et la location de “vrais” serveurs dédiés c’est pas encore ça hein.
Sans parler des très nombreux problèmes de L’IHM web qui complexifie à outrance les trucs les plus simples (changement d’OS…), il faut savoir qu’il n’y a pas de KVM et donc pas d’accès à la console.
Enfin si, c’est prévu, en option… A 30€ PAR JOUR !
Donc si c’est pour un hébergement web pas trop critique, c’est surement très bien. Mais si vous voulez de la prod sérieuse, je suis pas sur qu’ils soient encore vraiment prêts.
#5
Oui, il y a des sites e-commerce du top 10 français qui sont sur k8s en production.
Et depuis plusieurs années. ^^
Ce n’est plus un gadget, hein.
EDIT : C’était un troll, non ?
#6
Et oui, prod k8s, on met même des GPUs en prod sur k8s de nos jours
Au passage, vous avez 2 manières de gérer une prod sous k8s ou autre: soit aucune machine ne doit tomber, soit n’importe quelle machine peut tomber, et ça ne doit pas être un problème. k8s est très pratique dans le second cas.
Et dans le second cas, un kvm n’est pas très utile. Quand la machine tombe, on regarde d’où vient le pb, on change ce qui a cassé, on relance la machine et c’est reparti
#7
Au passage, vous avez 2 manières de gérer une prod sous k8s ou autre: soit aucune machine ne doit tomber, soit n’importe quelle machine peut tomber, et ça ne doit pas être un problème. k8s est très pratique dans le second cas.
#8
Oui progressivement.
On a commencé par du stateless (web, micro-services), et devons y mettre la bdd (et ses sauvegardes) 2022T1
Nous ne sommes pas en avance, mais comme d’autres nous avançons et sans heurt notoire.
C’est plus simple sur des nouveautés, ou avec un début “sans risques” comme du stateless, pour se faire la main en Prod.
Tu peux aussi commencer avec un K8S managé.
Il y a plusieurs façons de faire.
#9
Il y a pour moi des problèmes majeurs qui n’ont pas de solutions. Rien que le split-brain, il n’y a pas de moyen de gérer ça correctement, donc ça rend casse-gueule l’utilisation d’un cluster réparti sur 3, 5, 7 datacenters. Et en faisant un cluster par datacenter, on se retrouve à devoir load balancer les load balancer, on perd aussi l’intérêt à pouvoir résoudre les autres pods sur le sdn ou faire des déploiements canary simplement, etc…
Après la “magie” du départ, on se retrouve à devoir tout réinventer pour compenser toutes les promesses de simplification de k8s, mais qui nécessite un cluster local pour être fonctionnelles. Tant et si bien qu’en prenant du recul, si on y ajoute la perte de maitrise sur tout ce qui est réseau/dns à l’intérieur du cluster, le fait que finalement, k8s n’a rien remplacé de la “legacy”, les mises à jours où tu transpires à grosse goute que ca se passe sans soucis, pour peu qu’il y ai des addons externes aïe (je pense surtout au CNI), et on ne va pas se le cacher, la complexité du debug quand ca ne se passe pas si magiquement… A la fin, je trouve l’intérêt de k8s tout relatif. Responsable = maitrise, je ne me sens pas suffisamment en maitrise pour prendre la responsabilité de mettre en prod du k8s pour du 5 “9”.
En face de Kubernetes, je trouve plus sain d’utiliser un orchestrateur type Marathon, ou tout simplement Ansible + docker-compose. Quitte à tout devoir réinventer, autant le faire simplement.
Après mes quelques années d’expériences (et y en a pas mal), je ne crois plus en la magie. Alors sur un nouveau projet simple développé by-design pour kubernetes, ca pourrait marcher. Mais ça n’arrive jamais, sauf à vouloir ne démarrer que des frontaux web stateless.
Ces dernières années, les conteneurs docker (pro) et lxc (lab, perso) sont une partie de mon quotidien, mais k8s pour les orchestrer, après des semaines à tourner le truc dans tous les sens, j’en conclu que le ratio temps/emerdement/complexité/coût de sortie, par rapport à ce que ça apporte, n’est pas du tout rentable.
En l’état actuelle, je pense que k8s n’est pas adapté à faire tourner une prod à plus de 99.5% / 99.9%.
#10
k8s & compagnie ne sont bons que pour le dimensionnement client, pas pour le coeur de cerveau. Ca ne remplace pas un cluster de BDD écrivable, mais ça permet de faire des micro-clusters de BDD en lecture servant de cache.
Après oui, un orchestrateur maitrisé, c’est bien mieux. Mais faire un seul cluster pour remplacer une infra, c’est surtout une erreur de design ^_^ Tu devrais pouvoir te passer d’un cluster, d’un morceau de cluster, d’un service, … sans problème.
#11
Tout ce que tu dis se défend.
De mon côté k8s a obligé les développeurs à faire du code/logs propres, et surtout des services surveillables, avant c’était un veux pieux. Donc même en ajoutant la complexité de k8s, les exploitants sont gagnants.
K8S a obligé de gros changement dans le(S) processus de livraison. Les développeurs sont gagnants.
K8S offre des possibilités d’ajouter presque n’importe quel outil, pour peu que son image réponde à quelques canons/interfaces. Les architectes et développeurs sont gagnants (plus d’outils standards, moins de code maison…).
Par contre, nous ne visons pas le multi datacenters, ou sinon je le ferais cool genre au niveau DNS. Mais nous ne visons pas plus de 99.9% effectifs.
Et tu auras compris que nous ne commençons pas par le coeur de métier.
#12
Oui. Kubernetes est mon quotidien, et correctement implémenté, avec les bons principes, ça fournis exactement ce que ça doit, et c’est adapté à un usage en production.
Par contre, si on veut en faire ce que ce n’est pas, ça devient très vite casse-gueule.
Un des gros faux-départs de kubernetes est effectivement que les entreprises se sont vite imaginées faire des méga-clusters hétéroclites et répartis tout en les redécoupant en multi-tenant… en pratique, cette approche a peu de sens dans la majorité des cas, fait exploser la complexité et le risque.
Il faut penser 12 facteurs, écarter les applications qui ne savent pas s’y tenir un minimum. Une application qui n’est par exemple pas configurable via variables d’environnement, configmap/secret ou un opérateur et des crd’s, ne devrait sans-doutes pas être déployée sur kubernetes.
Le plus important pour une gestion efficace est de maîtriser toutes les définitions via un système de réconciliation GitOps ( par exemple FluxCD), les déploiements à la main sont à proscrire coûte que coûte dès qu’on quitte la phase prototypage si on veut des garanties de pouvoir retomber sus ses pattes (tu définis tes déploiements, secrets, … une seule fois dans un git, et le déploiement de l’application est fait en “pull” par chaque cluster )
… et aussi, éviter de parquer les bijoux de la couronne du stockage directement sur kubernetes, ce n’est pas fait pour ça, même si de nombreuses entreprises essayeront de fourguer des solutions dans ce sens. Kubernetes, c’est avant-tout fait pour le stateless, plus on s’éloigne de ça, plus ça se transforme en usine à gaz à haut risque.
#13
Si je ne dis pas de connerie, certains services de Google sont sur K8s.
Donc, oui on peut l’utiliser en production.
#14
Aux dernières nouvelles, Google utilise Borg, leur orchestrateur maison.
Si j’étais complotiste, je dirais que Google pousse k8s aux dev en leur disant “regardez comment c’est facile avec minikube”, puis au moment de passer en prod, si les considérations que j’ai énumérées (et bien d’autres) dans mon précédent commentaire n’ont pas été prise en compte, ca devient ingérable coté HA… Du coup on va le mettre chez Google Cloud Platform…