Mettre à jour! . Dans les commentaires, l'un des lecteurs a suggéré d'essayer Linstor (peut-être qu'il y travaille lui-même), j'ai donc ajouté une section sur cette solution. J'ai également écrit un article sur la façon de l'installer , car le processus est très différent du reste.
Pour être honnête, j'ai abandonné et abandonné Kubernetes (au moins pour l'instant). J'utiliserai Heroku . Pourquoi? À cause du stockage! Qui aurait pensé que je jouerais plus avec le stockage qu'avec Kubernetes lui-même. J'utilise Hetzner Cloud car il est peu coûteux et les performances sont bonnes, et depuis le tout début j'ai déployé des clusters à l'aide de Rancher . Je n'ai pas essayé les services gérés Kubernetes de Google / Amazon / Microsoft / DigitalOcean, etc., etc., parce que je voulais tout apprendre moi-même. Et je suis économique.
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 étudié quelques options payantes par curiosité, car elles ont des versions gratuites avec des restrictions. J'ai noté quelques chiffres des derniers tests lorsque je comparais différentes options, et ils pourraient intéresser ceux qui étudient le stockage dans Kubernetes. Jusqu'à présent, j'ai personnellement dit au revoir à Kubernetes. Je veux également mentionner le pilote CSI , dans lequel vous pouvez préparer directement les volumes Hetzner Cloud, mais je ne l'ai pas encore essayé. J'ai étudié le stockage défini par logiciel dans le cloud car j'avais besoin d'une réplication et de la capacité de monter rapidement des volumes persistants sur n'importe quel nœud, en particulier en cas de défaillance d'un nœud et d'autres situations similaires. Certaines solutions proposent des instantanés à un moment donné et des sauvegardes hors site, ce qui est pratique.
J'ai testé 6-7 solutions de stockage:
Comme je l'ai dit dans un post précédent , après avoir testé la plupart des options de la liste, je me suis d'abord installé sur 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. Il s'agit d'une source ouverte et les développeurs de leur chaîne Slack ont toujours beaucoup aidé lorsque j'avais besoin d'aide. Malheureusement, ses performances sont très faibles par rapport aux autres options, j'ai donc dû refaire les tests. OpenEBS dispose désormais de 3 moteurs de stockage, mais je publie les résultats de référence pour cStor. Jusqu'à présent, je n'ai pas de numéros pour Jiva et LocalPV.
En un mot, Jiva est un peu plus rapide et LocalPV est généralement plus rapide, pas pire que la référence du lecteur directement. Le problème avec LocalPV est que l'accès au volume ne peut être obtenu que sur le nœud où il a été préparé et qu'il n'y a absolument aucune réplication. J'ai eu quelques problèmes pour récupérer la sauvegarde via Velero sur un nouveau cluster, car les noms de nœuds étaient différents. Si nous parlons de sauvegardes, cStor a un plugin pour Velero , avec lequel vous pouvez faire des sauvegardes hors site des instantanés à la fois, ce qui est plus pratique que les sauvegardes au niveau du fichier avec Velero-Restic. J'ai écrit plusieurs scripts pour faciliter la gestion des sauvegardes et des restaurations avec ce plugin. En général, j'aime vraiment OpenEBS, mais ses performances ...
Rook possède également du code open source, et il diffère des autres 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, tels que Ceph , EdgeFS et autres, ce qui simplifie considérablement 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 propose non seulement un stockage par blocs, mais également un stockage d'objets compatible avec S3 / Swift et le système de fichiers distribué. Ce que j'aime chez Ceph, c'est la possibilité de distribuer des données de volume sur plusieurs disques afin que le volume puisse utiliser plus d'espace disque que ne peut en contenir un seul. C'est pratique. Une autre fonctionnalité intéressante est que lorsque vous ajoutez des disques à un cluster, il redistribue automatiquement les données sur tous les disques.
Il y a des instantanés dans Ceph, mais pour autant que je sache, ils ne peuvent pas être utilisés directement dans Rook / Kubernetes. Certes, je ne suis pas entré dans cela. Mais hors site, il n'y a pas de sauvegardes, vous devez donc utiliser quelque chose avec Velero / Restic, mais il n'y a que des sauvegardes au niveau du fichier, pas des instantanés à l'époque. Mais dans Rook, j'ai vraiment aimé le travail simple avec Ceph - il cache presque toutes les choses complexes et offre des outils pour communiquer directement avec Ceph pour le dépannage. Malheureusement, dans le test de résistance des volumes de Ceph, j'ai eu ce problème tout le temps, à cause duquel Ceph est devenu 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 contrôle Ceph. J'ai évoqué les paramètres de la mémoire, et cela s'est amélioré, mais le problème n'a été résolu qu'à la fin. Ceph a de bonnes performances, comme vous pouvez le voir dans les benchmarks ci-dessous. Il a également un bon tableau de bord.
J'aime vraiment Longhorn. À mon avis, c'est une solution prometteuse. Certes, les développeurs eux-mêmes (Rancher Labs) reconnaissent qu'il ne convient pas à l'environnement de travail, et cela peut être vu. Il a du code open source et de bonnes performances (bien qu'ils ne l'aient pas encore optimisé), mais les volumes prennent très longtemps à se connecter au foyer, et dans le pire des cas, cela prend 15 à 16 minutes, surtout après la restauration d'une sauvegarde de grande taille ou la mise à niveau de la charge de travail. Il a 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 d'autres ressources. Les sauvegardes et la restauration sont très fiables, mais indécemment lentes. Sérieusement, juste prohibitivement lent. L'utilisation du processeur et le chargement du système augmentent souvent lorsque vous travaillez avec des données moyennes à Longhorn. Il y a un tableau de bord pratique pour contrôler le Longhorn. J'ai déjà dit que j'aime Longhorn, mais il faut y travailler.
StorageOS est le premier produit payant de la liste. Il a une version pour les développeurs avec un stockage géré limité à 500 Go, mais le nombre de nœuds, à mon avis, n'est pas limité. Le service des ventes 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 produit avec les performances: dans certains benchmarks, c'est assez décent, mais je n'ai pas aimé la vitesse du tout dans le test de stress des volumes. En général, je ne sais pas quoi dire. Par conséquent, je n'ai pas particulièrement compris. Il n'y a pas de sauvegardes hors site et vous devrez également utiliser Velero avec Restic pour sauvegarder les volumes. C'est étrange, car le produit est payé. Et les développeurs n'étaient pas désireux de communiquer en Slack.
J'ai entendu parler de Robin sur Reddit par leur directeur technique. Je n'avais jamais entendu parler de lui auparavant. Peut-être parce que je cherchais des solutions gratuites, et Robin a 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 y a une excellente CLI là-bas, mais ce qui est cool, c'est que vous pouvez créer des instantanés et sauvegarder l'intégralité de l'application (dans le sélecteur de ressources, elle s'appelle Helm releases ou «flex apps»), y compris les volumes et autres ressources, vous pouvez donc vous passer de Velero. Et tout serait merveilleux si ce n'était pas pour un petit détail: si vous restaurez (ou "importez", comme Robin l'appelle) une application sur un nouveau cluster - par exemple, en cas de récupération après un accident - la récupération, bien sûr, fonctionne, mais continuez à sauvegarder l'application non autorisé. Dans cette version, ce n'est tout simplement pas possible, et les développeurs l'ont confirmé. Pour le dire légèrement, c'est étrange, surtout si l'on considère les autres avantages (par exemple, les sauvegardes et la restauration incroyablement rapides). Les développeurs promettent de tout réparer pour 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 le volume connecté à l'hôte, la vitesse de lecture est beaucoup plus élevée que dans le même volume, mais de l'intérieur. 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'étais contrarié à cause du problème de récupération et de sauvegarde - il me semblait que j'avais finalement trouvé une solution appropriée, et j'étais même prêt à payer pour cela quand j'avais besoin de plus d'espace ou de serveurs.
Je n'ai vraiment rien à dire ici. C'est un produit payant, tout aussi cool et cher. La performance est un miracle. Jusqu'à présent, c'est le meilleur indicateur. Slack m'a dit que le prix commence à 205 $ par mois et par nœud, comme indiqué sur Google GKE Marketplace. 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 que la licence de développeur (jusqu'à 1 To et 3 nœuds) soit pratiquement inutile avec Kubernetes, sauf si vous vous contentez d'une préparation statique. J'espérais que la licence en volume tomberait automatiquement au niveau du développeur à la fin de la période d'essai, mais ce n'est pas le cas. La licence de développeur ne peut être utilisée directement qu'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 sont tout simplement pas comparables à d'autres options.
J'ai ajouté cette section après la publication du message, lorsqu'un lecteur a suggéré d'essayer Linstor. Je l'ai essayé et je l'ai aimé! Mais il faut encore creuser. Maintenant, je peux dire que les performances ne sont pas mauvaises (j'ai ajouté les résultats de référence ci-dessous). En fait, j'ai obtenu les mêmes performances que pour le lecteur directement, sans aucun frais généraux. (Ne demandez pas directement pourquoi Portworx a de meilleurs chiffres que la référence du lecteur. Je n'en ai aucune idée. Magic, probablement.) Donc, Linstor semble toujours très efficace. L'installer n'est pas si difficile, mais pas aussi facile que les autres options. J'ai d'abord dû installer Linstor (le module du noyau et les outils / services) et configurer LVM pour l'allocation dynamique 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 que cela ne fonctionne pas sur CentOS et devait utiliser Ubuntu. Pas effrayant, bien sûr, mais un peu ennuyeux, car la documentation (qui est d'ailleurs excellente) mentionne plusieurs packages qui ne peuvent pas être trouvés dans les référentiels Epel spécifiés. Linstor a des instantanés, mais pas des sauvegardes hors site, donc là encore j'ai dû utiliser Velero avec Restic pour sauvegarder des volumes. Je préférerais les instantanés plutôt que les sauvegardes au niveau des fichiers, mais cela peut être toléré si la solution est productive et fiable. Linstor a l'open source, mais il y a un support payant. Si je comprends bien, il peut être utilisé sans restrictions, même si vous n'avez pas d'accord de support, mais cela doit être clarifié. Je ne sais pas comment Linstor est testé pour Kubernetes, mais le niveau de stockage lui-même est en dehors de Kubernetes et, apparemment, la solution n'est pas apparue hier, donc elle a probablement déjà été testée dans des conditions réelles. Y a-t-il une solution ici qui me fera changer d'avis et retourner à Kubernetes? Je ne sais pas, je ne sais pas. Il faut encore creuser plus profondément, étudier la réplication. Voyons voir. Mais la première impression est bonne. Je préférerais certainement utiliser mes propres clusters Kubernetes au lieu de Heroku pour gagner plus de liberté et apprendre de nouvelles choses. Étant donné que Linstor n'est pas installé aussi facilement que d'autres, j'écrirai bientôt un article à ce sujet.
Repères
Malheureusement, j'ai gardé quelques enregistrements de la comparaison, car je ne pensais pas que j'écrirais à ce sujet. Je n'ai que les résultats des tests de référence de la base fio, et uniquement pour les clusters à nœud unique, donc pour les configurations répliquées, je n'ai pas encore de chiffres. Mais à partir de ces résultats, vous pouvez avoir une idée approximative de ce à quoi vous 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, puis réinitialisé les paramètres du serveur pour chaque produit. Tout cela n'est pas du tout scientifique, juste pour vous faire comprendre 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 la référence 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: 4
J'ai d'abord créé un volume avec la classe de stockage correspondante, puis j'ai commencé la tâche 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 indicateur en vert et la pire en rouge.
Conclusion
Comme vous pouvez le voir, dans la plupart des cas, Portworx a obtenu de meilleurs résultats que les autres. Mais pour moi, il est cher. Je ne sais pas combien coûte Robin, mais il y a une excellente version gratuite, donc si vous avez besoin d'un produit payant, vous pouvez l'essayer (j'espère qu'ils régleront bientôt le problème de la récupération et des sauvegardes). Des trois gratuits, j'ai eu le moins de problèmes avec OpenEBS, mais ses performances ne sont pas au diable. Dommage, je n'ai pas enregistré plus de résultats, mais j'espère que les chiffres donnés et mes commentaires vous aideront.