Mise à jour !. Dans les commentaires, l'un des lecteurs a proposé d'essayer (peut-être qu'il travaille dessus lui-même), donc j'ai ajouté une section sur cette solution. J'ai aussi écrit , car le processus est très différent des autres.
Honnêtement, j'ai renoncé et j'ai abandonné (en tout cas, pour l'instant). Je vais utiliser . Pourquoi ? À cause du stockage ! Qui aurait pensé que je passerais plus de temps à gérer des stockages qu'à travailler avec Kubernetes. J'utilise , car c'est peu coûteux et la performance est bonne, et dès le départ, j'ai déployé des clusters avec . Je n'ai pas essayé les services gérés de Kubernetes de Google/Amazon/Microsoft/DigitalOcean et autres, car je voulais apprendre par moi-même. Et puis je suis économe.
Donc, oui, j'ai passé beaucoup de temps à essayer de décider quel stockage choisir lorsque j'évaluais la pile possible pour Kubernetes. Je préfère les solutions open source, non seulement pour le prix, mais j'ai aussi exploré quelques options payantes par curiosité, car elles ont des versions gratuites avec des limitations. J'ai noté quelques chiffres des derniers tests que j'ai réalisés en comparant différentes options, et ils pourraient intéresser ceux qui étudient le stockage dans Kubernetes. Bien que personnellement, je me sois pour l'instant éloigné de Kubernetes. Je veux aussi mentionner , qui permet de préparer directement les volumes de Hetzner Cloud, mais je ne l'ai pas encore essayé. J'ai étudié les stockages cloud définis par logiciel, car j'avais besoin de réplication et de la capacité de connecter rapidement des volumes persistants sur n'importe quel nœud, surtout en cas de défaillance de nœud ou de situations similaires. Certaines solutions offrent des snapshots à un moment donné et des sauvegardes hors site, ce qui est pratique.
J'ai testé 6 à 7 solutions de stockage :
Comme je l'ai déjà mentionné , après avoir testé la plupart des options de la liste, j'ai au départ opté pour OpenEBS. OpenEBS est très simple à installer et à utiliser, mais honnêtement, après des tests avec de vraies données sous charge, sa performance m'a déçu. C'est open source, et les développeurs sur leur Ils m'ont toujours beaucoup aidé lorsque j'avais besoin d'assistance. Malheureusement, sa performance est très inférieure par rapport à d'autres options, donc j'ai dû effectuer les tests à nouveau. Actuellement, OpenEBS dispose de 3 moteurs de stockage, mais je publie les résultats des benchmarks pour cStor. Pour l'instant, je n'ai pas de chiffres pour Jiva et LocalPV.
En gros, Jiva est un peu plus rapide, tandis que LocalPV est très rapide, pas moins performant qu'un benchmark de disque direct. Le problème avec LocalPV est que l'accès est uniquement possible sur le nœud sur lequel il a été configuré, et il n'y a pas de réplication. J'ai rencontré quelques problèmes pour restaurer une sauvegarde via sur un nouveau cluster, car les noms des nœuds étaient différents. En ce qui concerne les sauvegardes, cStor dispose d'un , qui permet de réaliser des sauvegardes off site des snapshots à des moments donnés, ce qui est plus pratique que les sauvegardes au niveau des fichiers avec Velero-Restic. J'ai écrit , afin de simplifier la gestion des sauvegardes et des restaurations avec ce plugin. Dans l'ensemble, j'aime beaucoup OpenEBS, mais sa performance…
Rook est également open source, et il se distingue des autres options de la liste par le fait qu'il s'agit d'un orchestrateur de stockage qui effectue des tâches complexes de gestion de stockage avec différents backends, tels que , et d'autres, ce qui simplifie considérablement le travail. J'ai eu des problèmes avec EdgeFS lorsque je l'ai essayé il y a quelques mois, donc j'ai principalement effectué des tests avec Ceph. Ceph propose non seulement du stockage par blocs, mais aussi un stockage d'objets compatible avec S3/Swift et un système de fichiers distribué. Ce que j'apprécie dans Ceph, c'est la possibilité de répartir les données d'un volume sur plusieurs disques, permettant au volume d'utiliser plus d'espace disque que ce qui est disponible sur un seul disque. C'est pratique. Une autre fonctionnalité intéressante est que lorsque des disques sont ajoutés au cluster, il redistribue automatiquement les données sur tous les disques.
Ceph propose des snapshots, mais, à ma connaissance, ils ne peuvent pas être utilisés directement avec Rook/Kubernetes. En revanche, je n'ai pas approfondi ce sujet. Il n'y a pas non plus de sauvegardes hors site, donc il va falloir utiliser quelque chose comme Velero/Restic, mais cela ne permet que des sauvegardes au niveau des fichiers et non des snapshots instantanés. En revanche, ce que j'ai beaucoup apprécié dans Rook, c'est la simplicité d'interaction avec Ceph – il cache presque tous les aspects complexes et propose des outils pour interagir directement avec Ceph pour résoudre les problèmes. Malheureusement, lors de mes tests de stress sur les volumes Ceph, j'ai constamment rencontré , rendant Ceph instable. Il n'est pas encore clair s'il s'agit d'un bug dans Ceph lui-même ou d'un problème avec la façon dont Rook gère Ceph. J'ai joué avec les paramètres de mémoire, et cela s'est amélioré, mais le problème n'est pas complètement résolu. Ceph offre de bonnes performances, comme le montrent les benchmarks ci-dessous. De plus, il dispose d'un bon tableau de bord de surveillance.
J'apprécie beaucoup Longhorn. C'est, à mon avis, une solution prometteuse. Cependant, les développeurs eux-mêmes (Rancher Labs) admettent qu'elle n'est pas encore adaptée à un environnement de production, et cela se voit. Son code est ouvert et ses performances sont correctes (bien qu'elles n'aient pas encore été optimisées), mais les volumes mettent très longtemps à se connecter au pod, et dans les pires cas, cela peut prendre 15 à 16 minutes, surtout après la restauration d'une grande sauvegarde ou d'une mise à jour de charge de travail. Elle dispose de snapshots et de sauvegardes hors site de ces snapshots, mais elles ne concernent que les volumes, donc vous aurez tout de même besoin de quelque chose comme Velero pour sauvegarder les autres ressources. Les sauvegardes et les restaurations sont très fiables, mais incroyablement lentes. Sérieusement, c'est juste affolant comme c'est lent. L'utilisation des ressources processeur et la charge système grimpent souvent lors du traitement de quantités de données moyennes dans Longhorn. Il existe un tableau de bord pratique pour gérer Longhorn. J'ai déjà mentionné que j'apprécie Longhorn, mais il faut vraiment y travailler de manière approfondie.
StorageOS est le premier produit payant de la liste. Il existe une version pour développeurs avec une taille maximale de stockage géré de 500 Go, mais il me semble qu'il n'y a pas de limite sur le nombre de nœuds. Dans le service commercial, on m'a dit que le prix commençait à partir de 125 $ par mois pour 1 To, si je me souviens bien. Il y a un tableau de bord de base et un CLI pratique, mais la performance est un peu étrange : dans certains benchmarks, elle est plutôt bonne, mais lors des tests de stress, la vitesse ne m'a pas du tout plu. En gros, je ne sais pas quoi en dire. Je ne me suis donc pas vraiment penché sur le sujet. Il n'y a pas de sauvegardes hors site, et je devrai également utiliser Velero avec Restic pour sauvegarder les volumes. Étrange, car c'est un produit payant. De plus, les développeurs n'étaient pas très disposés à communiquer sur Slack.
J'ai découvert Robin sur Reddit grâce à leur directeur technique. Je n'en avais jamais entendu parler auparavant. Peut-être parce que je cherchais des solutions gratuites, alors que Robin est payant. Ils ont une version gratuite assez généreuse avec un stockage de 10 To et trois nœuds. En général, le produit est tout à fait respectable et offre de bonnes fonctionnalités. Il y a une excellente interface en ligne de commande, mais ce qui est vraiment impressionnant, c'est la possibilité de faire un instantané et une sauvegarde de l'ensemble de l'application (dans le sélecteur de ressources, cela s'appelle des versions Helm ou « flex apps »), y compris les volumes et d'autres ressources, ce qui permet d'éviter Velero. Tout serait parfait s'il n'y avait pas un petit détail : si l'on restaure (ou « importe », comme cela s'appelle dans Robin) une application sur un nouveau cluster, par exemple dans le cas d'une restauration après sinistre, la restauration fonctionne parfaitement, mais il n'est pas possible de continuer la sauvegarde de l'application. Dans cette version, c'est tout simplement impossible, et les développeurs l'ont confirmé. C'est, pour le dire poliment, étrange, surtout compte tenu des autres avantages (par exemple, des sauvegardes et des restaurations incroyablement rapides). Les développeurs promettent de tout corriger pour la prochaine version. La performance est globalement bonne, mais j'ai remarqué une anomalie : si je lance un benchmark directement sur le volume connecté à l'hôte, la vitesse de lecture est beaucoup plus élevée que sur le même volume, mais à l'intérieur d'un pod. Tous les autres résultats sont identiques, mais en théorie, il ne devrait pas y avoir de différence. Même s'ils y travaillent, je suis déçu par le problème de restauration et de sauvegarde – j'avais l'impression d'avoir enfin trouvé une solution adéquate, et j'étais même prêt à payer pour cela quand j'aurai besoin de plus d'espace ou de plus de serveurs.
Je n'ai pas grand-chose à dire à ce sujet. C'est un produit payant, tout aussi impressionnant que cher. La performance est tout simplement incroyable. Pour l'instant, c'est la meilleure référence. On m'a dit sur Slack que le prix commence à 205 $ par mois par nœud, comme indiqué dans le Google GKE Marketplace. Je ne sais pas si ce serait moins cher si j'achetais directement. Quoi qu'il en soit, je ne peux pas me le permettre, donc j'étais très, très déçu que la licence développeur (jusqu'à 1 To et 3 nœuds) soit pratiquement inutile avec Kubernetes, à moins que vous ne vous contentiez d'un déploiement statique. J'espérais que la licence entreprise descendrait automatiquement au niveau développeur à la fin de la période d'essai, mais ce ne fut pas le cas. La licence développeur ne peut être utilisée que directement avec Docker, et la configuration dans Kubernetes est très complexe et limitée. Bien sûr, je préfère l'open source, mais si j'avais l'argent, je choisirais sans aucun doute Portworx. Pour l'instant, sa performance ne peut tout simplement pas être comparée à d'autres options.
J'ai ajouté cette section après la publication du post, lorsqu'un lecteur m'a suggéré d'essayer Linstor. Je l'ai essayé et j'ai aimé ! Mais il faut encore approfondir. Pour l'instant, je peux dire que les performances sont bonnes (j'ai ajouté les résultats des benchmarks ci-dessous). En gros, j'ai obtenu la même performance que pour le disque directement, sans aucune perte. (Ne me demandez pas pourquoi Portworx affiche de meilleures chiffres que le benchmark du disque directement. Je n'en ai aucune idée. C'est sûrement de la magie.) Donc, Linstor semble très efficace pour l'instant. Son installation n'est pas très difficile, mais pas aussi simple que pour d'autres options. Au début, j'ai dû installer Linstor (le module du noyau et les outils/services) et configurer LVM pour le thin provisioning et le support des snapshots en dehors de Kubernetes, directement sur l'hôte, puis créer les ressources nécessaires pour utiliser le stockage depuis Kubernetes. Je n'ai pas aimé le fait qu'il ne fonctionne pas sur CentOS et que j'ai dû utiliser Ubuntu. Ce n'est pas un gros problème, bien sûr, mais c'est un peu frustrant car la documentation (qui est d'ailleurs excellente) mentionne plusieurs paquets introuvables dans les dépôts Epel. Linstor propose des snapshots, mais pas de sauvegardes hors site, donc j'ai encore dû utiliser Velero avec Restic pour la sauvegarde des volumes. Je préférerais des snapshots plutôt que des sauvegardes au niveau des fichiers, mais cela peut être toléré si la solution est performante et fiable. Linstor est open-source, mais il y a un support payant. Si j'ai bien compris, il peut être utilisé sans limitations, même sans contrat de support, mais cela doit être confirmé. Je ne sais pas à quel point Linstor est éprouvé pour Kubernetes, mais le niveau de stockage est en dehors de Kubernetes et, apparemment, cette solution n'est pas apparue récemment, donc elle a probablement été testée dans des conditions réelles. Y a-t-il une solution ici qui me ferait changer d'avis et revenir à Kubernetes ? Je ne sais pas, je ne sais pas. Il faut encore enquêter, examiner la réplication. On verra. Mais la première impression est bonne. Je préférerais certainement utiliser mes propres clusters Kubernetes plutôt que Heroku, pour avoir plus de liberté et apprendre de nouvelles choses. Et comme Linstor n'est pas aussi simple à installer que les autres, j'écrirai bientôt un post à ce sujet.
Benchmarks
Malheureusement, j'ai conservé peu de notes de comparaison, car je ne pensais pas en écrire. Je n'ai que les résultats des benchmarks de base fio et seulement pour des clusters à nœud unique, donc je n'ai pas encore de chiffres pour les configurations répliquées. Mais à partir de ces résultats, on peut avoir une idée générale de ce à quoi s'attendre de chaque option, car je les ai comparées sur des serveurs cloud identiques, 4 cœurs, 16 Go de RAM, avec un disque supplémentaire de 100 Go pour les volumes testés. J'ai exécuté les benchmarks trois fois pour chaque solution et calculé la moyenne, plus j'ai réinitialisé le serveur pour chaque produit. Tout cela n'est pas scientifique, juste pour que vous compreniez en gros. Dans d'autres tests, j'ai copié 38 Go de photos et de vidéos d'un volume et sur le volume pour tester la lecture et l'écriture, mais je n'ai malheureusement pas conservé les chiffres. En résumé : Portworx était beaucoup plus rapide.
Pour le benchmark des volumes, j'ai utilisé ce manifeste :
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: dbench
spec:
storageClassName: ...
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
name: dbench
spec:
template:
spec:
containers:
- name: dbench
image: sotoaster/dbench:latest
imagePullPolicy: IfNotPresent
env:
- name: DBENCH_MOUNTPOINT
value: /data
- name: FIO_SIZE
value: 1G
volumeMounts:
- name: dbench-pv
mountPath: /data
restartPolicy: Never
volumes:
- name: dbench-pv
persistentVolumeClaim:
claimName: dbench
backoffLimit: 4D'abord, j'ai créé un volume avec la classe de stockage appropriée, puis j'ai lancé une tâche avec fio en arrière-plan. J'ai pris 1 Go pour évaluer la performance sans trop attendre. Voici les résultats :
J'ai mis en valeur la meilleure valeur pour chaque indicateur en vert, et la pire en rouge.
Conclusion
Comme vous pouvez le voir, dans la plupart des cas, Portworx a mieux performé que les autres. Mais pour moi, c'est cher. Je ne sais pas combien coûte Robin, mais il existe une excellente version gratuite, donc si vous avez besoin d'un produit payant, vous pouvez essayer (j'espère qu'ils vont bientôt résoudre le problème de restauration et de sauvegardes). Parmi les trois gratuits, j'ai eu le moins de problèmes avec OpenEBS, mais sa performance est médiocre. Dommage, je n'ai pas conservé plus de résultats, mais j'espère que les chiffres fournis et mes commentaires vous aideront.
Source : habr.com
