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 de l'article, suite à la suggestion d'un lecteur d'essayer Linstor. Je l'ai testé et j'ai été conquis ! Cependant, je dois approfondir mes recherches. Pour l'instant, je peux affirmer que les performances sont excellentes (les résultats des benchmarks sont disponibles ci-dessous). En fait, j'ai obtenu les mêmes performances qu'avec un benchmark direct sur disque, sans aucune surcharge. (Ne me demandez pas pourquoi les résultats de Portworx sont meilleurs que ceux du benchmark direct sur disque. Je n'en ai aucune idée. Un mystère, sans doute.) Linstor semble donc très efficace jusqu'à présent. Sa configuration n'est pas particulièrement difficile, mais elle n'est pas aussi simple que d'autres solutions. J'ai d'abord dû installer Linstor (module noyau et outils/services) et configurer LVM pour le provisionnement fin et la prise en charge des snapshots en dehors de Kubernetes, directement sur l'hôte, puis créer les ressources nécessaires à l'utilisation du stockage depuis Kubernetes. J'étais déçu que cela ne fonctionne pas sur CentOS et a dû utiliser UbuntuCe n'est pas un problème majeur, certes, mais c'est un peu agaçant car la documentation (qui est excellente, au passage) mentionne plusieurs paquets indisponibles dans les dépôts EPEL spécifiés. Linstor propose des snapshots, mais pas de sauvegardes externes ; j'ai donc dû réutiliser Velero avec Restic pour les sauvegardes de volumes. Je préférerais les snapshots aux sauvegardes au niveau fichier, mais c'est acceptable si la solution est performante et fiable. Linstor est open source, mais propose un support payant. Si j'ai bien compris, on peut l'utiliser sans restriction même sans contrat de support, mais il faudrait que je vérifie. Je ne sais pas dans quelle mesure Linstor est testé pour Kubernetes, mais la couche de stockage elle-même est externe à Kubernetes, et il semble exister depuis un certain temps ; il a donc probablement déjà été testé en conditions réelles. Existe-t-il une solution qui me ferait changer d'avis et revenir à Kubernetes ? Je ne sais pas. Il me faut approfondir mes recherches et me renseigner sur la réplication. On verra bien. Mais la première impression est positive. Je préférerais nettement utiliser mes propres clusters Kubernetes plutôt qu'Heroku pour plus de liberté et pour découvrir de nouvelles choses. Comme Linstor n'est pas aussi simple à installer que d'autres solutions, je publierai 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
