Que vaut Kapsule, le Kubernetes autogéré de Scaleway ?
Après 3 ans de bons et loyaux services, mon cluster Kubernetes a lâché. Il a fallu que je trouve une solution pour remettre mon blog ,gitea, et autres services sur pattes sans y passer des heures. J’ai essayé Kapsule, le Kubernetes autogéré de Scaleway - voilà ce que j’en pense.
EDIT 22/04/2020: Si vous avez déjà lu cet article, j’ai corrigé une partie de ce que je disais sur le LoadBalancer, voir plus bas.
EDIT 14/05/2020: Scaleway a pris en compte le manque de documentation à propos du LoadBalancer et je les en remercie. Voir plus bas, je vous donne le lien vers la documentation.
Scaleway est un service “cloud”, fournisseur européen d’infrastructure aussi connu sous le nom de Online SAS. Fondée par Xavier Niel, c’est une filiale du groupe Iliad. Vous savez, Free… tout ça…
Scaleway est un IaaS (Infrastructure as a Service), un peu comme Amazon AWS mais avec des prix nettement inférieurs. Soyons honnêtes, il y a encore 4 ou 5 ans, l’offre était plutôt limitée. Peu de machines proposées, et rien de bien fou coté stockage à part des disques à monter sur celles-ci.
Par contre, l’idée était intelligente. J’ai beau avoir un vrai souci avec Free pour ses offres aussi cassées que son réseau, là on parle d’un service de location de serveurs pour pas cher, avec des options de préinstallation bien fichues et qui fonctionnaient (à peu près) bien.
Pour chaque machine que vous créez, vous avez le choix de la distribution à installer, ou carrément de demander une installation d’un service prêt à l’emploi. En clair, vous pouvez tout aussi bien demander une Fedora, une Debian ou une CentOS que d’avoir une instance avec Gitlab, OpenVPN ou Redmine. En quelques clics, tout est réglé.
Et soyons clairs, c’est vraiment pas cher du tout. Les machines virtuelles 2CPU 2Go de RAM à 2.99€ je trouve que c’est vraiment à la porté de tous.
Scaleway a beaucoup évolué pour proposer, depuis quelques temps, d’autres services tels qu’un service d’Object Storage de type S3, un Load Balancer, un Postgres à la demande, des machines GPU (pour le machine learning), et dernièrement Kapsule qui propose la gestion d’un cluster Kubernetes autogéré.
Et je vais être honnête, une fois de plus je ne suis pas fana de X.Niel, ni de Free, mais Scaleway a vraiment fait un effort de qualité pour un prix toujours aussi bas - sans pour autant être le fameux “AWS du pauvre” comme je l’ai entendu. Non, là vraiment, c’est pas mal du tout.
Alors pour mon cluster pété, les solutions proposées étaient donc:
- soit de passer à des nouvelles machines (et donc de me retaper une installation de Kubernetes)
- soit de passer à Kapsule - ce fameux nouveau service Kubernetes autogéré de Scaleway.
Kapsule
Le principe est super simple, au lieu de vous taper l’installation de Kubernetes manuellement (avec Rancher, Kubespray, ou ce que vous voulez), vous n’avez ici qu’à demander la création du cluster. Après quelques minutes (en fait moins d’une minute dans mon cas) le cluster est prêt à l’emploi.
Le prix de base est vraiment pas cher, pour un “node” DEV 1M (3cpu, 4Go RAM) vous en aurez pour 7,99€/mois.
Une option très intéressante est que vous pouvez activer l’auto scaling avec une limite maximum de Nodes. Le tout dans des Pools de machines dimensionnées selon vos besoins. On en parle après.
Par exemple, dans mon cas, j’ai demandé à avoir maximum 3 machines en cas de besoin. Bien entendu, ces machines sont facturées à l’heure (0.016€/h) jusqu’à une limite de 2€99, et seulement si elles sont démarrées.
Notez que, à cela, vous allez certainement ajouter quelques euros si vous avez besoin de stockage, car Kapsule propose de base un “StorageClass” qui permet de créer des disques SSD réseaux. Donc en gros, si vous démarrez une base de donnée sur votre cluster, il faudra stocker les données sur un “Persitent volume”, et donc passer un par un “Claim” - le prix des stockages n’est pas douloureux (environ €0.08/GB/mois).
La présentation de l’offre est ici : Kapsule
Pour résumé, Kapsule associé quelques services Scaleway, ça peut se représenter ainsi:
Maintenant, faisons le point sur ce que je trouve vraiment bien, et ce que je trouve un peu moins cool…
Création d’un cluster
L’interface de création est vraiment bien fichue.
Une des choses que j’apprécie particulièrement chez Scaleway, c’est le fait de voir le prix que vous allez payer en bas de la page de création - c’est d’ailleurs ce qui m’agace chez AWS qui ne permet pas de calculer clairement le coût d’une création de machine ou de cluster. Scaleway ne se fout pas de nous, en plus de proposer un service pas cher, il indique clairement les informations de prix (remarquez, c’est peut-être lié…)
Autres options, vous pouvez demander à avoir accès au Dashboard et d’installer un Ingress Controller de type NGinx ou HAProxy. Pas besoin du Dashboard pour ma part, mais j’ai opté pour Nginx afin de ne pas avoir à le faire moi-même.
Finalement, vous avez :
- les masters gérés par Scaleway
- des nodes dans au moins un “Pool” (on en parle après)
- un fichier pour
kubectl
- au choix, un dashboard et/ou un ingress-controller
Kapsule est donc un soulagement pour la création du cluster. C’est rapide, pas cher, et je vais enfin m’abstraire de pas mal de tâches de gestions.
Le principe de Pool
Kapsule propose un système de Pool de machines qui est assez clair et pas mal pensé.
Un Pool est en fait un groupe de machines (node) à attacher à votre cluster Kubernetes. Chaque Pool défini le type de machine que vous voulez (DEV 1 M, GPU, Bare Metal…) auquel vous pouvez définir l’auto scaling ou non. Ces nodes seront labellisés correctement ce qui va vous permettre d’utiliser des “nodeAffinity” lors des déploiements de service.
Et ça c’est une sacrée bonne idée.
Pour ma part j’ai estimé qu’une seule machine dans un seul Pool me suffit, mais que je peux potentiellement monter en charge. J’ai donc réglé ce Pool pour avoir maximum 3 machines qui seront démarrées automatiquement si le besoin apparait. Pas de surprise au niveau du prix, je sais que mon cluster me coûtera 7.99€/mois minimum, ou 23.97€/mois si le Pool grossi. Pas plus !
Si vous avez quelques sites à démarrer avec plusieurs services gourmands, il vous suffit de créer un pool avec des machines légères (DEV 1 M par exemple), et un autre plus costaud avec des machines robustes pour faire tourner des BDD, un Elastic Search ou je ne sais quel glouton de CPU/RAM que vous voulez démarrer. Les Pools peuvent être créés ou supprimés à tout moment. Ce qui est en soit une excellente manière d’éviter de vous ruiner alors que votre besoin en CPU s’est tout à coup réduit pour des mois.
Petite chose que je viens de remarqué, on me propose des mises à jour à faire facilement:
Il suffit de cliquer sur le lien “upgrade” et de choisir de faire la mise à jour vers la version proposée.
Bref, la gestion de Pool est vraiment agréable, facile à gérer, et économique.
Le StorageClass
Il est difficile d’utiliser un cluster Kubernetes sans avoir du stockage persistant.
Pour ceux qui ne connaissent pas le principe, une petite piqûre de rappel:
Un conteneur est dit “stateless”, cela veut dire qu’il est sensé pouvoir être détruit sans garder un état. Du coup, toutes les données stockées au sein du conteneur disparaissent avec le conteneur quand il est éteint. Cela est vrai pour Docker, Podman, mais aussi Kubernetes. Vous pensez que c’est une mauvaise chose ? NON, c’est voulu !
Le but est que vous puissiez perdre une machine du cluster et voir votre conteneur démarrer sur une autre machine viable. Il ne faut pas que les données soient stockées sur l’hôte.
Alors comment on fait ?
La réponse est d’avoir des volumes de stockage qui sont montés sur le conteneur. On appelle cela un volume persistant.
Or, si vous voulez servir une base de données (e.g. MariaDB, Mongo, SQLite…), la vieille méthode est de créer ce volume, puis de le définir dans le déploiment pour indiquer où le monter. C’est pas marrant…
Bonne nouvelle ! Kubernetes propose un système de “réclamation”, appelé “Persistent Volume Claim”.
En gros, au lieu de créer un volume, vous créez une “demande de volume”. À charge d’un système de génération de volume de vous créer l’espace demandé et de vous fournir le volume que Kubernetes va monter pour vous. Pas de prise de tête. C’est super pratique…
Mais ?
… mais y’a un hic.
Tout n’est jamais aussi simple 😤
Comme le volume doit être monté sur n’importe quel conteneur de n’importe quelle machine, il faut que ce système de stockage soit “réseau”. On en connait quelques’uns:
- Ceph,
- Gluster,
- NFS,
- et bien d’autres…
Et par conséquent, il faut une API qui sache prendre en charge la demande de création. Bref…
Pour ajouter une couche de stress supplémentaire, certains types de volumes ne peuvent pas se monter sur plusieurs conteneurs en même temps. Cela veut dire que quand vous allez scaler un service, le volume ne pourra se monter que sur un seul hôte. Par exemple, GlusterFS n’a aucun souci à se monter sur plusieurs conteneurs positionnés sur plusieurs machines, aucun souci (à part la lenteur d’écriture), NFS pareil, mais Ceph RBD, lui, ne veut pas.
Il y a donc plusieurs modes:
- ReadWriteOnce ⇒ veut dire que le mode de montage est sur un seul hôte à la fois, et pas plus
- ReadWriteMany ⇒ peut être monté sur autant d’hôte en parallèle
OK, reveneons à Scaleway.
Scaleway propose des disques BSSD (donc en réseau), et a préconfiguré ce fameux StorageClass, ouf ! 🎉🕺🎊
Les BSSD, ce sont ces fameux volumes proposés depuis des lustres qui sont ici simplement créés et montés dans les Pods que vous allez démarrer. Ils sont plutôt rapides en écriture, et ne coûtent vraiment pas cher. Et par défaut, votre cluster aura ce “StorageClass” préparamétré - vous n’avez rien à faire de plus, c’est là, clef-en-main je vous dis. C’est la fête hein ! hein… non ?
Heu en fait y’a encore un hic… 😒
Seulement voilà, ces disques sont ReadWriteOnce…
Alors, on se calme hein, c’est fréquent. Parce que les services de stockage distribués sont rarement capables de proposer du ReadWriteMany en garantissant une bonne vitesse d’écriture.
Généralement les services de stockage rapides ne gèrent que le mode ReadWriteOnce. Cela n’est pas une grosse contrainte en soi. C’est un choix basé sur ce qui existe déjà et aussi pour éviter que vous pétiez un câble lors de l’écriture.
Pour la petite histoire, j’adore Gluster qui sait faire du ReadWriteMany, mais sitôt que j’ai eu besoin d’écrire des donnnées rapidement, j’ai déchanté. Et dans les faits, je n’avais pas tant besoin de monter du ReadWriteMany.
Si vraiment vous voulez avoir un service de stockage ReadWriteMany, il faudra l’installer par vous-même sur votre cluster, ou sur des instances séparées. Scaleway propose ce qu’il vous faut pour 99% des besoins, c’est déjà très bien ! Coté AWS vous pouvez utiliser un EFS (Elastic File Système) mais souvenez vous que c’est du NFS, donc lent… Sinon c’est du EBS qui est un équivalent de ce que propose Scaleway. Donc voilà… (Voir la liste ici)
Notez que c’est un sujet récurrent dans le monde de Kubernetes, et je préfère désormais ruser lorsque j’ai besoin d’avoir plusieurs Pods en parallèle qui doivent utiliser un espace de stockage commun. Par exemple, si je veux scaler un site qui dessert des fichiers statiques, ils se trouve sur un S3 - et si le framework ne le gère pas, je me débrouille pour faire tourner un truc léger, genre NFS, pour monter un volume dans le Pod. Il exite d’autres techniques, comme par exemple ajouter un sidecar qui fait la synchro des volumes, ou Mongo qui sait stocker des fichier en GridFS, et j’en passe…
Ce n’est pas vraiment une spécificité de Scaleway. Le principe est donc de s’adapter. Utiliser Kubernetes demande tout de même un peu de boulot.
Bref, la côté positif, c’est que Scaleway propose un StorageClass qui fonctionne très bien. Les volumes sont créés à la demande et monté en BSSD. Et quand vous supprimez l’application, le volume est recyclé. Si votre cluster à plus d’un node en marche, et que le Pod décide de passer d’un node à l’autre, le volume est très vite remonté dans sur l’hôte cible. Et pour ma part, je me passe plutôt facilement du ReadWriteMany.
La gestion du cluster
Là on entre dans la partie un peu moins agréable.
Si vous connaissez bien Kubernetes, vous n’aurez potentiellement pas
trop de soucis de ce côté. Pour ma part, kubectl
et helm
me
suffisent à faire ce que je veux. Je n’ai pas besoin de plus.
Mais si vous êtes à la recherche d’une solution interfacée pour permettre à des équipes de Dev de déployer des projets, il va falloir installer quelque chose. Par exemple, un Rancher sur une instance dédiée.
Et pour le coup, vous risquez une petite déception, car puisque vous n’avez pas accès aux nodes en SSH, il en pourra pas tourner sur une de ces machines. Et puisque vous n’avez pas non plus accès aux “masters”, Rancher va vous claquer des gros blocs rouges bien terrifiants sur la page de gestion puisqu’il n’arrivera pas à accéder à toutes les ressources.
Alors ce n’est pas si grave en soi… C’est même normal et pas bloquant du tout.
Ce n’est pas grave car votre but est justement de ne pas avoir à gérer ces parties. Le monitoring est proposé par Scaleway, vous pourrez donc utiliser Rancher normalement pour tout le reste (installation de services, gestion des droits utilisateurs, monitoring des conteneurs, etc.)
Finalement, le souci n’est pas vraiment Scaleway, mais Rancher qui ne propose pas (à ce que je sache) de désactiver ces erreurs de monitoring. Toujours est-il qu’il vous faudra une machine de plus pour ça. Donc ajoutez à la balance de 3 à 8€.
Sécurité et Load Balancer
Cette partie est un peu plus problématique. Rien de très grave, mais cela peut entrer en conflit avec vos besoins.
D’abords, les nodes ont forcément une IP publique. Impossible de mettre ces machines derrière un bastion. Ce qui est gênant c’est que cela implique que vos machines peuvent avoir un “NodePort” ouvert par un service qui sera accessible.
Alors, en soit c’est pratique et ce n’est pas si grave, cela permet
d’utiliser facilement nginx-controller
et faire pointer vos domaines
sur un de vos Nodes. Mais aussi d’utiliser des NodePort pour des
services non HTTP. Par exemple avec Gitea pour accéder au protocole git
en SSH et non en HTTPS, je peux binder sur un NodePort.
C’est plus compliqué avec un bastion devant avec une configuration de Load Balancer à régler au poil (ce qui est possible avec le LB de Scaleway, on en parle tout de suite). Effectivement, ici, pas besoin de se battre puisque les nodes sont accessibles.
Ça vous gène niveau sécurité ? Je peux le comprendre mais dans les faits ce n’est pas si “open bar” que ça en à l’air. Les nodes n’acceptent pas de shell SSH, ils sont gérés par Scaleway.
Là où ça pêche, c’est si vous ne maitrisez pas Kubernetes et que, pour des raisons pratiques, vous décidiez d’ouvrir des NodePort sur des services sensibles. C’est de votre responsabilité !. Il est évident que vous devez faire un peu de travail pour que vos services tournent proprement. Donc, si vous avez une base de données qui tourne sur votre cluster, il serait complètement fou d’ouvrir son port d’accès en NodePort, il faut bien entendu utiliser un type ClusterIP
Reste la question des accès HTTP(s) puisque vous avez certainement demandé d’avoir un Ingress Controller (NGinx ou Traefik). Je me suis posé la question un moment, et je deais être un peu fatigué ce jour là parce que, quand on connait Kubernetes, la réponse tombe sour le sens…
Scaleway propose un service de LoadBalancer haute dispo, et au sein de votre cluster il y a déjà un controller qui repère les “Services” qui ont un type “LoadBalancer”. Si vous en créez un, alors un LoadBalancer va être créé coté Scaleway avec une IP fixe. Du coup, si vous faite tomber un node et qui redémarre, ou si vous ajoutez des nodes, le loadbalancer sera reconfiguré pour faire son travail.
Si vous voulez que votre IngressController puisse être utilisé par un LoadBalancer, il suffit de lui ajouter un “Service” de type “LoadBalancer” (non vraiment je ne comprends pas pourquoi je n’y ai pas pensé…).
Changement au 14/05/2020 Scaleway à donné une très bonne page pour expliquer comment activer un load-balancer wildcard.
J’ai signalé un manque d’informations sur ce sujet, et j’en avais parlé avec ScaleWay sur leur Slack et Twitter. Par chance, chez Scaleway, les DevOps et admins sont très sympas et prennent le temps de répondre de manière détaillée. Vraiment, merci à eux. J’ai donc eu la réponse, mais j’ai surtout eut la surprise d’avoir cette réponse sur mon Twitter:
{{< twitter 1260510424178601984 >}}
Là pour le coup, je tire mon chapeau. Il ne manquait vraiment que cette page. Donc, la voici, elle contient ce dont vous avez besoin:
Using a load balancer to expose your Kubernetes Kapsule ingress controller service
En résumé, pour Nginx-ingress, il suffit de pousser cette configuration sur votre cluster une fois pour toute:
apiVersion: v1
kind: Service
metadata:
name: nginx-ingress
namespace: kube-system
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
spec:
type: LoadBalancer
ports:
- port: 80
name: http
targetPort: 80
- port: 443
name: https
targetPort: 443
selector:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/part-of: ingress-nginx
En appliquant ce fichier, on a bien une IP pour notre ingress-controller:
nginx-ingress LoadBalancer 10.45.150.14 51.XX.XX.XX 80:31468/TCP,443:30454/TCP 10s
Le tour est joué, cette IP peut maintenant être assigné dans les DNS, on la perdra pas, et le LB va faire le boulot comme demandé.
Ce serait bien cool que Scaleway documente cela, car mon article est resté plusieurs jours avec une mauvaise info… Mais je ne vais pas faire le lourdingue, les équipe de Scalexay répondent rapidement et avec des vraies bonne infos.
Donc, on résume:
Le LoadBalancer est utilisable, fiable, fait le boulot, c’est automatique et ça coute pas si cher.
Je vais conclure (© J.C. Duss)
Kapsule est un très bon service de création et de gestion de cluster Kubernetes. Il est économique, prêt à l’emploi, et facile à manipuler. Il est parfait pour les freelances qui veulent déployer des démos de site, ou pour des petites entreprises qui veulent héberger leurs services dans un PaaS.
Tout est là, y compris la création de volume.
Les plus grosses entreprises pourront l’utiliser notamment pour l’hébergement de démo et/ou pour l’intégration continue, mais cela demande un petit effort supplémentaire pour intégrer des outils de gestion PaaS tels que Rancher (afin d’avoir une gestion de droits par utilisateurs).
Les pools élastiques sont clairement efficaces et économiques. C’est beaucoup moins compliqué et moins cher que chez AWS.
En ce qui concerne l’hébergement de services pour les grosses entreprises avec de gros besoins, je ne vais pas trop m’avancer. Cela-dit, je gère déjà des clusters pour des grosses structures et je dois bien avouer que Kapsule peut répondre à certains clients d’envergure. Si mon avis vous intéresse, je place Kapsule au dessus de la solution EKS de Amazon, que ce soit en terme d’interface, de prix, d’aide et de tenu de route. C’est bien entendu mon avis personnel.
Le fait de pouvoir gérer des pools de machines adaptées à la puissance nécessaire, et de pouvoir les couper à tout moment permet de faire de sacrées économies.
Kapsule peut donc clairement être utilisé par une entreprise de grande envergure, tout comme un particuier, un freelance ou une petite entreprise. C’est selon moi la meilleure offre du marché de par son prix, sa souplesse et sa simplicité.
Scaleway propose un S3 et un registre docker privé qui, couplés à Kapsule, permettent en tout cas de faire 99% du travail attendu en ce qui concerne un hébergement PaaS Kubernetes. Le fait que les machines soient monitorées et que Kubernetes soit géré par une équipe dédiée en prestation est un vrai plus. Le prix du stockage d’image est de 0.025€ mais je trouve que le prix de la bande passante inter-région un peu élevé. 0.03€ par push/pull ça peut devenir vite angoissant. Par contre, en intra-région, c’est grauit. J’ai mis en place un Drone qui construir les images et les pousse sur le registre. Donc de ce coté, je ne paye rien car les pulls effectués par mes noeud Kubernetes se trouve sur la même région (Paris) que le registre.
Je ne vois plus qu’un seul bémol: l’absence de possibilité d’utiliser un bastion. Si cela est votre besoin, vous devriez plutôt passer par Scaleway Datacenter qui propose aussi une gestion de Kubernetes mais bien plus adaptée à la production niveau “entreprise”.
Bref, si vous avez envie de tester un hébergement Kuberenetes pour pas cher, et qui fonctionne bien, Kapsule est une bonne solution alternative à AWS EKS. Et en plus, c’est Européen ! (et largement géré par une boite Française).