Mise à jour!. Dans les commentaires, l'un des lecteurs a suggéré d'essayer (peut-être qu'il y travaille lui-même), j'ai donc ajouté une section sur cette solution. j'ai aussi écrit parce que le processus est très différent du reste.
Pour être honnête, j'ai abandonné et abandonné (au moins pour l'instant). j'utiliserai . Pourquoi? A cause du stockage ! Qui aurait pensé que je jouerais plus avec le stockage qu'avec Kubernetes lui-même. j'utilise , parce que c'est peu coûteux et que les performances sont bonnes, et dès le début j'ai déployé des clusters avec . Je n'ai pas essayé les services gérés Kubernetes de Google/Amazon/Microsoft/DigitalOcean, etc., etc., car je voulais tout apprendre moi-même. Je suis aussi économe.
Donc - oui, j'ai passé beaucoup de temps à essayer de décider quel stockage choisir lorsque j'envisageais une éventuelle pile sur Kubernetes. Je préfère les solutions open source, et pas seulement à cause du prix, mais j'ai regardé quelques options payantes par curiosité, car elles ont des versions gratuites avec des restrictions. J'ai noté quelques chiffres de benchmarks récents lorsque je comparais différentes options, et ils peuvent intéresser ceux qui étudient le stockage dans Kubernetes. Bien que personnellement, j'ai dit au revoir à Kubernetes jusqu'à présent. Je veux aussi mentionner , dans lequel vous pouvez provisionner directement des volumes Hetzner Cloud, mais je ne l'ai pas encore essayé. J'étudiais le stockage défini par logiciel dans le cloud parce que j'avais besoin de réplication et de la possibilité de monter rapidement des volumes persistants sur n'importe quel nœud, en particulier en cas de panne de nœud et d'autres situations similaires. Certaines solutions proposent des instantanés ponctuels et des sauvegardes hors site, ce qui est pratique.
J'ai testé 6-7 solutions de stockage :
Comme je l'ai déjà dit , après avoir testé la plupart des options de la liste, j'ai d'abord opté pour OpenEBS. OpenEBS est très facile à installer et à utiliser, mais pour être honnête, après avoir testé avec des données réelles sous charge, ses performances m'ont déçu. Ceci est open source, et les développeurs sont seuls toujours très utile quand j'avais besoin d'aide. Malheureusement, ses performances sont très médiocres par rapport aux autres options, j'ai donc dû refaire les tests. À l'heure actuelle, OpenEBS dispose de 3 moteurs de stockage, mais je publie des résultats de référence pour cStor. Je n'ai pas encore de chiffres pour Jiva et LocalPV.
En un mot, Jiva est légèrement plus rapide et LocalPV est généralement rapide, pas pire que le benchmark du lecteur directement. Le problème avec LocalPV est que le volume n'est accessible que sur le nœud où il a été provisionné et qu'il n'y a aucune réplication. J'ai eu quelques problèmes avec la restauration d'une sauvegarde via sur le nouveau cluster car les noms de nœud étaient différents. En parlant de sauvegardes, cStor a , avec lequel vous pouvez effectuer des sauvegardes d'instantanés ponctuelles hors site, ce qui est plus pratique que les sauvegardes de niveau fichier avec Velero-Restic. J'ai écrit pour faciliter la gestion des sauvegardes et des restaurations avec ce plugin. Dans l'ensemble, j'aime beaucoup OpenEBS, mais ses performances...
Rook est également open source et diffère du reste des options de la liste en ce qu'il s'agit d'un orchestrateur de stockage qui effectue des tâches complexes de gestion du stockage avec différents backends, par exemple , et d'autres, ce qui simplifie grandement le travail. J'ai eu des problèmes avec EfgeFS lorsque je l'ai essayé il y a quelques mois, j'ai donc testé principalement avec Ceph. Ceph offre non seulement un stockage par blocs, mais également un stockage d'objets compatible avec S3/Swift et un système de fichiers distribué. Ce que j'aime chez Ceph, c'est la possibilité de répartir les données de volume sur plusieurs disques afin que le volume puisse utiliser plus d'espace disque qu'il ne peut en contenir sur un seul disque. C'est confortable. Une autre fonctionnalité intéressante est que lorsque vous ajoutez des disques au cluster, il redistribue automatiquement les données sur tous les disques.
Ceph a des instantanés, mais pour autant que je sache, ils ne peuvent pas être utilisés directement dans Rook/Kubernetes. Certes, je ne me suis pas penché dessus. Mais il n'y a pas de sauvegardes hors site, vous devez donc utiliser quelque chose avec Velero / Restic, mais il n'y a que des sauvegardes au niveau des fichiers, pas des instantanés à un moment donné. Ce que j'aime vraiment chez Rook, cependant, c'est la facilité de travail avec Ceph - il cache presque tous les éléments complexes et offre des outils pour parler directement à Ceph pour le dépannage. Malheureusement, lors du stress test des volumes Ceph, j'ai toujours eu , ce qui rend Ceph instable. Il n'est pas encore clair s'il s'agit d'un bogue dans Ceph lui-même ou d'un problème dans la façon dont Rook gère Ceph. J'ai tripoté les paramètres de mémoire, et ça s'est amélioré, mais le problème n'a pas été complètement résolu. Ceph a de bonnes performances comme le montrent les benchmarks ci-dessous. Il a également un bon tableau de bord.
J'aime beaucoup Longhorn. Je pense que c'est une solution prometteuse. Certes, les développeurs eux-mêmes (Rancher Labs) admettent qu'il n'est pas encore adapté à un environnement de production, et cela se voit. C'est open source et a des performances décentes (bien qu'ils ne l'aient pas encore optimisé), mais les volumes mettent très longtemps à se connecter au pod, et dans le pire des cas, cela prend 15 à 16 minutes, surtout après la restauration d'une grande sauvegarde ou mise à niveau d'une charge de travail. Il contient des instantanés et des sauvegardes hors site de ces instantanés, mais ils ne s'appliquent qu'aux volumes, vous avez donc toujours besoin de quelque chose comme Velero pour sauvegarder le reste des ressources. Les sauvegardes et les restaurations sont très fiables, mais d'une lenteur indécente. Sérieusement, juste d'une lenteur prohibitive. L'utilisation du processeur et la charge du système augmentent souvent lorsque vous travaillez avec une quantité moyenne de données dans Longhorn. Il existe un tableau de bord pratique pour gérer Longhorn. J'ai déjà dit que j'aime Longhorn, mais il faut le travailler correctement.
StorageOS est le premier produit payant de la liste. Il a une version développeur avec une taille de stockage gérée limitée à 500 Go, mais je ne pense pas qu'il y ait une limite au nombre de nœuds. Le service commercial m'a dit que le coût commence à 125 $ par mois pour 1 To, si je me souviens bien. Il y a un tableau de bord de base et une CLI pratique, mais quelque chose d'étrange se passe avec les performances : dans certains benchmarks, c'est assez correct, mais dans le test de résistance des volumes, je n'ai pas du tout aimé la vitesse. En général, je ne sais pas quoi dire. Donc je n'ai pas vraiment compris. Il n'y a pas de sauvegardes hors site ici et vous devrez également utiliser Velero avec Restic pour sauvegarder les volumes. C'est étrange, car le produit est payant. Et les développeurs n'étaient pas pressés de communiquer dans Slack.
J'ai entendu parler de Robin sur Reddit par leur CTO. Je n'avais jamais entendu parler de lui auparavant. Peut-être parce que je cherchais des solutions gratuites et que Robin est payé. Ils ont une version gratuite assez généreuse avec 10 To de stockage et trois nœuds. En général, le produit est assez décent et avec de belles fonctionnalités. Il existe une excellente CLI, mais le plus cool est que vous pouvez créer un instantané et sauvegarder l'intégralité de l'application (appelée versions Helm ou "applications flexibles" dans le sélecteur de ressources), y compris les volumes et autres ressources, afin que vous puissiez vous passer de Velero. Et tout serait merveilleux si ce n'était pour un petit détail : si vous restaurez (ou « importez », comme on dit en Robin) une application sur un nouveau cluster - par exemple, en cas de reprise après sinistre - la restauration, de bien sûr, fonctionne, mais continuer à sauvegarder l'application c'est interdit. Dans cette version, ce n'est tout simplement pas possible, et les développeurs l'ont confirmé. C'est pour le moins étrange, surtout si l'on considère d'autres avantages (par exemple, des sauvegardes et des restaurations incroyablement rapides). Les développeurs promettent de tout réparer d'ici la prochaine version. Les performances sont généralement bonnes, mais j'ai remarqué une chose étrange : si vous exécutez le benchmark directement sur un volume attaché à l'hôte, la vitesse de lecture est beaucoup plus élevée que dans le même volume, mais depuis l'intérieur du pod. Tous les autres résultats sont identiques, mais en théorie, il ne devrait pas y avoir de différence. Bien qu'ils y travaillent, j'ai été frustré par le problème de restauration et de sauvegarde - il me semblait que j'avais enfin trouvé une solution appropriée, et j'étais même prêt à payer pour cela lorsque j'avais besoin de plus d'espace ou de plus de serveurs.
Je n'ai pas grand chose à dire ici. C'est un produit payant, tout aussi cool et cher. La performance est tout simplement incroyable. C'est pour l'instant le meilleur indicateur. Slack m'a dit que les prix commençaient à 205 $ par mois et par nœud, comme indiqué sur le marché GKE de Google. Je ne sais pas si ce sera moins cher si vous achetez directement. En tout cas, je ne peux pas me le permettre, j'ai donc été très, très déçu qu'une licence développeur (jusqu'à 1 To et 3 nœuds) soit pratiquement inutile avec Kubernetes, à moins que vous ne vous contentiez d'un provisionnement statique. J'espérais que la licence en volume passerait automatiquement au niveau développeur à la fin de la période d'essai, mais cela ne s'est pas produit. La licence développeur ne peut être utilisée que directement avec Docker, et la configuration dans Kubernetes est très lourde et limitée. Bien sûr, je préfère l'open source, mais si j'avais de l'argent, je choisirais certainement Portworx. Jusqu'à présent, ses performances ne se comparent tout simplement pas à d'autres options.
J'ai ajouté cette section après la publication du message, lorsqu'un lecteur a suggéré d'essayer Linstor. J'ai essayé et j'ai aimé ! Mais encore faut-il creuser. Maintenant, je peux dire que les performances ne sont pas mauvaises (résultats de référence ajoutés ci-dessous). En fait, j'ai obtenu les mêmes performances que pour le disque directement, sans aucune surcharge. (Ne demandez pas pourquoi les chiffres de Portworx sont meilleurs que la référence du lecteur directement. Je n'en ai aucune idée. Magique, je suppose.) Donc, Linstor semble très efficace jusqu'à présent. L'installer n'est pas si difficile, mais pas aussi facile que d'autres options. J'ai d'abord dû installer Linstor (module de noyau et outils/services) et configurer LVM pour le provisionnement léger et la prise en charge des instantanés en dehors de Kubernetes, directement sur l'hôte, puis créer les ressources nécessaires pour utiliser le stockage de Kubernetes. Je n'aimais pas le fait que cela ne fonctionnait pas sur CentOS et que je devais utiliser Ubuntu. Pas terrible, certes, mais un peu ennuyeux, car la documentation (qui, soit dit en passant, est excellente) mentionne plusieurs packages introuvables dans les référentiels Epel spécifiés. Linstor a des instantanés, mais pas de sauvegardes hors site, donc là encore, j'ai dû utiliser Velero avec Ristic pour sauvegarder les volumes. Je préférerais les instantanés aux sauvegardes au niveau des fichiers, mais cela peut être toléré si la solution est à la fois performante et fiable. Linstor est open source mais a un support payant. Si j'ai bien compris, il peut être utilisé sans restriction, même si vous n'avez pas de contrat de support, mais cela doit être clarifié. Je ne sais pas comment Linstor est testé pour Kubernetes, mais la couche de stockage elle-même est en dehors de Kubernetes et, apparemment, la solution n'est pas apparue hier, elle est donc probablement déjà testée en conditions réelles. Existe-t-il une solution ici qui me fera changer d'avis et revenir à Kubernetes ? Je ne sais pas. Nous devons encore creuser plus profondément, étudier la réplication. Voyons. Mais la première impression est bonne. Je préférerais certainement utiliser mes propres clusters Kubernetes au lieu d'Heroku pour avoir plus de liberté et apprendre de nouvelles choses. Étant donné que Linstor n'est pas aussi facile à installer que d'autres, j'écrirai bientôt un article à ce sujet.
Repères
Malheureusement, j'ai gardé peu de traces de la comparaison, car je ne pensais pas écrire à ce sujet. Je n'ai que des résultats de référence de référence fio et uniquement 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, vous pouvez avoir une idée approximative de ce à quoi s'attendre de chaque option, car je les ai comparés sur les mêmes serveurs cloud, 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 tests de performance trois fois pour chaque solution et calculé le résultat moyen, ainsi que la réinitialisation des paramètres du serveur pour chaque produit. Tout cela est complètement non scientifique, juste pour que vous compreniez en termes généraux. Dans d'autres tests, j'ai copié 38 Go de photos et de vidéos du volume et pour tester la lecture et l'écriture, mais, hélas, je n'ai pas enregistré les chiffres. En bref : Portworkx était beaucoup plus rapide.
Pour le benchmark de volume, 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: 4J'ai d'abord créé un volume avec la classe de stockage appropriée, puis j'ai exécuté le travail avec fio dans les coulisses. J'ai pris 1 Go pour estimer les performances et ne pas attendre trop longtemps. Voici les résultats:
J'ai mis en évidence la meilleure valeur pour chaque métrique en vert et la pire en rouge.
Conclusion
Comme vous pouvez le constater, dans la plupart des cas, Portworx a obtenu de meilleurs résultats 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 l'essayer (j'espère qu'ils résoudront bientôt le problème avec les restaurations et les sauvegardes). Des trois gratuits, j'ai eu le moins de problèmes avec OpenEBS, mais ses performances sont catastrophiques. Je suis désolé de ne pas avoir enregistré plus de résultats, mais j'espère que les chiffres et mes commentaires vous aideront.
Source: habr.com