{"id":37528,"date":"2019-10-31T22:18:10","date_gmt":"2019-10-31T19:18:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/hranilishha-v-kubernetes-openebs-vs-rook-ceph-vs-rancher-longhorn-vs-storageos-vs-robin-vs-portworx-vs-linstor\/"},"modified":"2019-10-31T22:18:10","modified_gmt":"2019-10-31T19:18:10","slug":"hranilishha-v-kubernetes-openebs-vs-rook-ceph-vs-rancher-longhorn-vs-storageos-vs-robin-vs-portworx-vs-linstor","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/hranilishha-v-kubernetes-openebs-vs-rook-ceph-vs-rancher-longhorn-vs-storageos-vs-robin-vs-portworx-vs-linstor","title":{"rendered":"Stockages dans Kubernetes : OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Stockages<\/p>\n

<\/p>\n

Mise \u00e0 jour !<\/strong>. Dans les commentaires, l'un des lecteurs a propos\u00e9 d'essayer Linstor<\/a><\/noindex> (peut-\u00eatre qu'il travaille dessus lui-m\u00eame), donc j'ai ajout\u00e9 une section sur cette solution. J'ai aussi \u00e9crit un post sur la fa\u00e7on de l'installer<\/a><\/noindex>, car le processus est tr\u00e8s diff\u00e9rent des autres.<\/p>\n

<\/p>\n

Honn\u00eatement, j'ai renonc\u00e9 et j'ai abandonn\u00e9 Kubernetes<\/a><\/noindex> (en tout cas, pour l'instant). Je vais utiliser Heroku<\/a><\/noindex>. Pourquoi ? \u00c0 cause du stockage ! Qui aurait pens\u00e9 que je passerais plus de temps \u00e0 g\u00e9rer des stockages qu'\u00e0 travailler avec Kubernetes. J'utilise Hetzner Cloud<\/a><\/noindex>, car c'est peu co\u00fbteux et la performance est bonne, et d\u00e8s le d\u00e9part, j'ai d\u00e9ploy\u00e9 des clusters avec Rancher<\/a><\/noindex>. Je n'ai pas essay\u00e9 les services g\u00e9r\u00e9s de Kubernetes de Google\/Amazon\/Microsoft\/DigitalOcean et autres, car je voulais apprendre par moi-m\u00eame. Et puis je suis \u00e9conome.<\/p>\n

<\/a><\/noindex><\/p>\n

Donc, oui, j'ai pass\u00e9 beaucoup de temps \u00e0 essayer de d\u00e9cider quel stockage choisir lorsque j'\u00e9valuais la pile possible pour Kubernetes. Je pr\u00e9f\u00e8re les solutions open source, non seulement pour le prix, mais j'ai aussi explor\u00e9 quelques options payantes par curiosit\u00e9, car elles ont des versions gratuites avec des limitations. J'ai not\u00e9 quelques chiffres des derniers tests que j'ai r\u00e9alis\u00e9s en comparant diff\u00e9rentes options, et ils pourraient int\u00e9resser ceux qui \u00e9tudient le stockage dans Kubernetes. Bien que personnellement, je me sois pour l'instant \u00e9loign\u00e9 de Kubernetes. Je veux aussi mentionner le pilote CSI<\/a><\/noindex>, qui permet de pr\u00e9parer directement les volumes de Hetzner Cloud, mais je ne l'ai pas encore essay\u00e9. J'ai \u00e9tudi\u00e9 les stockages cloud d\u00e9finis par logiciel, car j'avais besoin de r\u00e9plication et de la capacit\u00e9 de connecter rapidement des volumes persistants sur n'importe quel n\u0153ud, surtout en cas de d\u00e9faillance de n\u0153ud ou de situations similaires. Certaines solutions offrent des snapshots \u00e0 un moment donn\u00e9 et des sauvegardes hors site, ce qui est pratique.<\/p>\n

<\/p>\n

J'ai test\u00e9 6 \u00e0 7 solutions de stockage :<\/p>\n

<\/p>\n

OpenEBS<\/a><\/noindex><\/h3>\n

<\/p>\n

Comme je l'ai d\u00e9j\u00e0 mentionn\u00e9 dans le post pr\u00e9c\u00e9dent<\/a><\/noindex>, apr\u00e8s avoir test\u00e9 la plupart des options de la liste, j'ai au d\u00e9part opt\u00e9 pour OpenEBS. OpenEBS est tr\u00e8s simple \u00e0 installer et \u00e0 utiliser, mais honn\u00eatement, apr\u00e8s des tests avec de vraies donn\u00e9es sous charge, sa performance m'a d\u00e9\u00e7u. C'est open source, et les d\u00e9veloppeurs sur leur canal Slack<\/a><\/noindex> Ils m'ont toujours beaucoup aid\u00e9 lorsque j'avais besoin d'assistance. Malheureusement, sa performance est tr\u00e8s inf\u00e9rieure par rapport \u00e0 d'autres options, donc j'ai d\u00fb effectuer les tests \u00e0 nouveau. Actuellement, OpenEBS dispose de 3 moteurs de stockage, mais je publie les r\u00e9sultats des benchmarks pour cStor. Pour l'instant, je n'ai pas de chiffres pour Jiva et LocalPV.<\/p>\n

<\/p>\n

En gros, Jiva est un peu plus rapide, tandis que LocalPV est tr\u00e8s rapide, pas moins performant qu'un benchmark de disque direct. Le probl\u00e8me avec LocalPV est que l'acc\u00e8s est uniquement possible sur le n\u0153ud sur lequel il a \u00e9t\u00e9 configur\u00e9, et il n'y a pas de r\u00e9plication. J'ai rencontr\u00e9 quelques probl\u00e8mes pour restaurer une sauvegarde via Velero<\/a><\/noindex> sur un nouveau cluster, car les noms des n\u0153uds \u00e9taient diff\u00e9rents. En ce qui concerne les sauvegardes, cStor dispose d'un plugin pour Velero<\/a><\/noindex>, qui permet de r\u00e9aliser des sauvegardes off site des snapshots \u00e0 des moments donn\u00e9s, ce qui est plus pratique que les sauvegardes au niveau des fichiers avec Velero-Restic. J'ai \u00e9crit quelques scripts<\/a><\/noindex>, pour faciliter la gestion des sauvegardes et des restaurations avec ce plugin. Dans l'ensemble, j'aime beaucoup OpenEBS, mais sa performance\u2026<\/p>\n

<\/p>\n

Rook<\/a><\/noindex><\/h3>\n

<\/p>\n

Rook est \u00e9galement 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\u00e2ches complexes de gestion de stockage avec diff\u00e9rents backends, tels que Ceph<\/a><\/noindex>, EdgeFS<\/a><\/noindex> et d'autres, ce qui simplifie consid\u00e9rablement le travail. J'ai eu des probl\u00e8mes avec EdgeFS lorsque je l'ai essay\u00e9 il y a quelques mois, donc j'ai principalement effectu\u00e9 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\u00e8me de fichiers distribu\u00e9. Ce que j'appr\u00e9cie dans Ceph, c'est la possibilit\u00e9 de r\u00e9partir les donn\u00e9es 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\u00e9 int\u00e9ressante est que lorsque des disques sont ajout\u00e9s au cluster, il redistribue automatiquement les donn\u00e9es sur tous les disques.<\/p>\n

<\/p>\n

Ceph propose des snapshots, mais, \u00e0 ma connaissance, ils ne peuvent pas \u00eatre utilis\u00e9s 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\u00e9s. En revanche, ce que j'ai beaucoup appr\u00e9ci\u00e9 dans Rook, c'est la simplicit\u00e9 d'interaction avec Ceph \u2013 il cache presque tous les aspects complexes et propose des outils pour interagir directement avec Ceph pour r\u00e9soudre les probl\u00e8mes. Malheureusement, lors de mes tests de stress sur les volumes Ceph, j'ai constamment rencontr\u00e9 ce probl\u00e8me<\/a><\/noindex>, rendant Ceph instable. Il n'est pas encore clair s'il s'agit d'un bug dans Ceph lui-m\u00eame ou d'un probl\u00e8me avec la fa\u00e7on dont Rook g\u00e8re Ceph. J'ai jou\u00e9 avec les param\u00e8tres de m\u00e9moire, et cela s'est am\u00e9lior\u00e9, mais le probl\u00e8me n'est pas compl\u00e8tement r\u00e9solu. Ceph offre de bonnes performances, comme le montrent les benchmarks ci-dessous. De plus, il dispose d'un bon tableau de bord de surveillance.<\/p>\n

<\/p>\n

Rancher Longhorn<\/a><\/noindex><\/h3>\n

<\/p>\n

J'appr\u00e9cie beaucoup Longhorn. C'est, \u00e0 mon avis, une solution prometteuse. Cependant, les d\u00e9veloppeurs eux-m\u00eames (Rancher Labs) admettent qu'elle n'est pas encore adapt\u00e9e \u00e0 un environnement de production, et cela se voit. Son code est ouvert et ses performances sont correctes (bien qu'elles n'aient pas encore \u00e9t\u00e9 optimis\u00e9es), mais les volumes mettent tr\u00e8s longtemps \u00e0 se connecter au pod, et dans les pires cas, cela peut prendre 15 \u00e0 16 minutes, surtout apr\u00e8s la restauration d'une grande sauvegarde ou d'une mise \u00e0 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\u00eame besoin de quelque chose comme Velero pour sauvegarder les autres ressources. Les sauvegardes et les restaurations sont tr\u00e8s fiables, mais incroyablement lentes. S\u00e9rieusement, c'est juste affolant comme c'est lent. L'utilisation des ressources processeur et la charge syst\u00e8me grimpent souvent lors du traitement de quantit\u00e9s de donn\u00e9es moyennes dans Longhorn. Il existe un tableau de bord pratique pour g\u00e9rer Longhorn. J'ai d\u00e9j\u00e0 mentionn\u00e9 que j'appr\u00e9cie Longhorn, mais il faut vraiment y travailler de mani\u00e8re approfondie.<\/p>\n

<\/p>\n

StorageOS<\/a><\/noindex><\/h3>\n

<\/p>\n

StorageOS est le premier produit payant de la liste. Il existe une version pour d\u00e9veloppeurs avec une taille maximale de stockage g\u00e9r\u00e9 de 500 Go, mais il me semble qu'il n'y a pas de limite sur le nombre de n\u0153uds. Dans le service commercial, on m'a dit que le prix commen\u00e7ait \u00e0 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 \u00e9trange : dans certains benchmarks, elle est plut\u00f4t 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\u00e9 sur le sujet. Il n'y a pas de sauvegardes hors site, et je devrai \u00e9galement utiliser Velero avec Restic pour sauvegarder les volumes. \u00c9trange, car c'est un produit payant. De plus, les d\u00e9veloppeurs n'\u00e9taient pas tr\u00e8s dispos\u00e9s \u00e0 communiquer sur Slack.<\/p>\n

<\/p>\n

Robin<\/a><\/noindex><\/h3>\n

<\/p>\n

J'ai d\u00e9couvert Robin sur Reddit gr\u00e2ce \u00e0 leur directeur technique. Je n'en avais jamais entendu parler auparavant. Peut-\u00eatre parce que je cherchais des solutions gratuites, alors que Robin est payant. Ils ont une version gratuite assez g\u00e9n\u00e9reuse avec un stockage de 10 To et trois n\u0153uds. En g\u00e9n\u00e9ral, le produit est tout \u00e0 fait respectable et offre de bonnes fonctionnalit\u00e9s. Il y a une excellente interface en ligne de commande, mais ce qui est vraiment impressionnant, c'est la possibilit\u00e9 de faire un instantan\u00e9 et une sauvegarde de l'ensemble de l'application (dans le s\u00e9lecteur de ressources, cela s'appelle des versions Helm ou \u00ab flex apps \u00bb), y compris les volumes et d'autres ressources, ce qui permet d'\u00e9viter Velero. Tout serait parfait s'il n'y avait pas un petit d\u00e9tail : si l'on restaure (ou \u00ab importe \u00bb, comme cela s'appelle dans Robin) une application sur un nouveau cluster, par exemple dans le cas d'une restauration apr\u00e8s 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\u00e9veloppeurs l'ont confirm\u00e9. C'est, pour le dire poliment, \u00e9trange, surtout compte tenu des autres avantages (par exemple, des sauvegardes et des restaurations incroyablement rapides). Les d\u00e9veloppeurs promettent de tout corriger pour la prochaine version. La performance est globalement bonne, mais j'ai remarqu\u00e9 une anomalie : si je lance un benchmark directement sur le volume connect\u00e9 \u00e0 l'h\u00f4te, la vitesse de lecture est beaucoup plus \u00e9lev\u00e9e que sur le m\u00eame volume, mais \u00e0 l'int\u00e9rieur d'un pod. Tous les autres r\u00e9sultats sont identiques, mais en th\u00e9orie, il ne devrait pas y avoir de diff\u00e9rence. M\u00eame s'ils y travaillent, je suis d\u00e9\u00e7u par le probl\u00e8me de restauration et de sauvegarde \u2013 j'avais l'impression d'avoir enfin trouv\u00e9 une solution ad\u00e9quate, et j'\u00e9tais m\u00eame pr\u00eat \u00e0 payer pour cela quand j'aurai besoin de plus d'espace ou de plus de serveurs.<\/p>\n

<\/p>\n

Portworx<\/a><\/noindex><\/h3>\n

<\/p>\n

Je n'ai pas grand-chose \u00e0 dire \u00e0 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\u00e9f\u00e9rence. On m'a dit sur Slack que le prix commence \u00e0 205 $ par mois par n\u0153ud, comme indiqu\u00e9 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'\u00e9tais tr\u00e8s, tr\u00e8s d\u00e9\u00e7u que la licence d\u00e9veloppeur (jusqu'\u00e0 1 To et 3 n\u0153uds) soit pratiquement inutile avec Kubernetes, \u00e0 moins que vous ne vous contentiez d'un d\u00e9ploiement statique. J'esp\u00e9rais que la licence entreprise descendrait automatiquement au niveau d\u00e9veloppeur \u00e0 la fin de la p\u00e9riode d'essai, mais ce ne fut pas le cas. La licence d\u00e9veloppeur ne peut \u00eatre utilis\u00e9e que directement avec Docker, et la configuration dans Kubernetes est tr\u00e8s complexe et limit\u00e9e. Bien s\u00fbr, je pr\u00e9f\u00e8re 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 \u00eatre compar\u00e9e \u00e0 d'autres options.<\/p>\n

<\/p>\n

Linstor<\/a><\/noindex><\/h3>\n

<\/p>\n

J'ai ajout\u00e9 cette section apr\u00e8s la publication du post, lorsqu'un lecteur m'a sugg\u00e9r\u00e9 d'essayer Linstor. Je l'ai essay\u00e9 et j'ai aim\u00e9 ! Mais il faut encore approfondir. Pour l'instant, je peux dire que les performances sont bonnes (j'ai ajout\u00e9 les r\u00e9sultats des benchmarks ci-dessous). En gros, j'ai obtenu la m\u00eame 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\u00e9e. C'est s\u00fbrement de la magie.) Donc, Linstor semble tr\u00e8s efficace pour l'instant. Son installation n'est pas tr\u00e8s difficile, mais pas aussi simple que pour d'autres options. Au d\u00e9but, j'ai d\u00fb 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\u00f4te, puis cr\u00e9er les ressources n\u00e9cessaires pour utiliser le stockage depuis Kubernetes. Je n'ai pas aim\u00e9 le fait qu'il ne fonctionne pas sur CentOS et que j'ai d\u00fb utiliser Ubuntu. Ce n'est pas un gros probl\u00e8me, bien s\u00fbr, mais c'est un peu frustrant car la documentation (qui est d'ailleurs excellente) mentionne plusieurs paquets introuvables dans les d\u00e9p\u00f4ts Epel. Linstor propose des snapshots, mais pas de sauvegardes hors site, donc j'ai encore d\u00fb utiliser Velero avec Restic pour la sauvegarde des volumes. Je pr\u00e9f\u00e9rerais des snapshots plut\u00f4t que des sauvegardes au niveau des fichiers, mais cela peut \u00eatre tol\u00e9r\u00e9 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 \u00eatre utilis\u00e9 sans limitations, m\u00eame sans contrat de support, mais cela doit \u00eatre confirm\u00e9. Je ne sais pas \u00e0 quel point Linstor est \u00e9prouv\u00e9 pour Kubernetes, mais le niveau de stockage est en dehors de Kubernetes et, apparemment, cette solution n'est pas apparue r\u00e9cemment, donc elle a probablement \u00e9t\u00e9 test\u00e9e dans des conditions r\u00e9elles. Y a-t-il une solution ici qui me ferait changer d'avis et revenir \u00e0 Kubernetes ? Je ne sais pas, je ne sais pas. Il faut encore enqu\u00eater, examiner la r\u00e9plication. On verra. Mais la premi\u00e8re impression est bonne. Je pr\u00e9f\u00e9rerais certainement utiliser mes propres clusters Kubernetes plut\u00f4t que Heroku, pour avoir plus de libert\u00e9 et apprendre de nouvelles choses. Et comme Linstor n'est pas aussi simple \u00e0 installer que les autres, j'\u00e9crirai bient\u00f4t un post \u00e0 ce sujet.<\/p>\n

<\/p>\n

Benchmarks<\/h3>\n

<\/p>\n

Malheureusement, j'ai conserv\u00e9 peu de notes de comparaison, car je ne pensais pas en \u00e9crire. Je n'ai que les r\u00e9sultats des benchmarks de base fio et seulement pour des clusters \u00e0 n\u0153ud unique, donc je n'ai pas encore de chiffres pour les configurations r\u00e9pliqu\u00e9es. Mais \u00e0 partir de ces r\u00e9sultats, on peut avoir une id\u00e9e g\u00e9n\u00e9rale de ce \u00e0 quoi s'attendre de chaque option, car je les ai compar\u00e9es sur des serveurs cloud identiques, 4 c\u0153urs, 16 Go de RAM, avec un disque suppl\u00e9mentaire de 100 Go pour les volumes test\u00e9s. J'ai ex\u00e9cut\u00e9 les benchmarks trois fois pour chaque solution et calcul\u00e9 la moyenne, plus j'ai r\u00e9initialis\u00e9 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\u00e9 38 Go de photos et de vid\u00e9os d'un volume et sur le volume pour tester la lecture et l'\u00e9criture, mais je n'ai malheureusement pas conserv\u00e9 les chiffres. En r\u00e9sum\u00e9 : Portworx \u00e9tait beaucoup plus rapide.<\/p>\n

<\/p>\n

Pour le benchmark des volumes, j'ai utilis\u00e9 ce manifeste :<\/p>\n

<\/p>\n

kind: PersistentVolumeClaim\napiVersion: v1\nmetadata:\n  name: dbench\nspec:\n  storageClassName: ...\n  accessModes:\n    - ReadWriteOnce\n  resources:\n    requests:\n      storage: 5Gi\n---\napiVersion: batch\/v1\nkind: Job\nmetadata:\n  name: dbench\nspec:\n  template:\n    spec:\n      containers:\n      - name: dbench\n        image: sotoaster\/dbench:latest\n        imagePullPolicy: IfNotPresent\n        env:\n          - name: DBENCH_MOUNTPOINT\n            value: \/data\n          - name: FIO_SIZE\n            value: 1G\n        volumeMounts:\n        - name: dbench-pv\n          mountPath: \/data\n      restartPolicy: Never\n      volumes:\n      - name: dbench-pv\n        persistentVolumeClaim:\n          claimName: dbench\n  backoffLimit: 4<\/code><\/pre>\n
<\/p>\n
D'abord, j'ai cr\u00e9\u00e9 un volume avec la classe de stockage appropri\u00e9e, puis j'ai lanc\u00e9 une t\u00e2che avec fio en arri\u00e8re-plan. J'ai pris 1 Go pour \u00e9valuer la performance sans trop attendre. Voici les r\u00e9sultats :<\/p>\n
<\/p>\n
\"Stockages<\/a><\/noindex><\/p>\n
<\/p>\n
J'ai mis en valeur la meilleure valeur pour chaque indicateur en vert, et la pire en rouge.<\/p>\n
<\/p>\n
Conclusion<\/h3>\n
<\/p>\n
Comme vous pouvez le voir, dans la plupart des cas, Portworx a mieux perform\u00e9 que les autres. Mais pour moi, c'est cher. Je ne sais pas combien co\u00fbte Robin, mais il existe une excellente version gratuite, donc si vous avez besoin d'un produit payant, vous pouvez essayer (j'esp\u00e8re qu'ils vont bient\u00f4t r\u00e9soudre le probl\u00e8me de restauration et de sauvegardes). Parmi les trois gratuits, j'ai eu le moins de probl\u00e8mes avec OpenEBS, mais sa performance est m\u00e9diocre. Dommage, je n'ai pas conserv\u00e9 plus de r\u00e9sultats, mais j'esp\u00e8re que les chiffres fournis et mes commentaires vous aideront.<\/p>\n
Source : habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0435!. \u0412 \u043a\u043e\u043c\u043c\u0435\u043d\u0442\u0430\u0445 \u043e\u0434\u0438\u043d \u0438\u0437 \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0435\u0439 \u043f\u0440\u0435\u0434\u043b\u043e\u0436\u0438\u043b \u043f\u043e\u043f\u0440\u043e\u0431\u043e\u0432\u0430\u0442\u044c Linstor (\u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e, \u043e\u043d \u0441\u0430\u043c \u043d\u0430\u0434 \u043d\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442), \u0442\u0430\u043a \u0447\u0442\u043e \u044f \u0434\u043e\u0431\u0430\u0432\u0438\u043b \u0440\u0430\u0437\u0434\u0435\u043b \u043e\u0431 \u044d\u0442\u043e\u043c \u0440\u0435\u0448\u0435\u043d\u0438\u0438. \u0415\u0449\u0435 \u044f \u043d\u0430\u043f\u0438\u0441\u0430\u043b \u043f\u043e\u0441\u0442 \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u0435\u0433\u043e \u0443\u0441\u0442\u0430\u043d\u043e\u0432\u0438\u0442\u044c, \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u0441\u0438\u043b\u044c\u043d\u043e \u043e\u0442\u043b\u0438\u0447\u0430\u0435\u0442\u0441\u044f \u043e\u0442 \u043e\u0441\u0442\u0430\u043b\u044c\u043d\u044b\u0445. \u0415\u0441\u043b\u0438 \u0447\u0435\u0441\u0442\u043d\u043e, \u044f \u0441\u0434\u0430\u043b\u0441\u044f \u0438 \u043e\u0442\u043a\u0430\u0437\u0430\u043b\u0441\u044f \u043e\u0442 Kubernetes (\u0432\u043e \u0432\u0441\u044f\u043a\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435, \u043f\u043e\u043a\u0430). \u0411\u0443\u0434\u0443 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c Heroku. \u041f\u043e\u0447\u0435\u043c\u0443? […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28163,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37528","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Stockages dans Kubernetes : OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/hranilishha-v-kubernetes-openebs-vs-rook-ceph-vs-rancher-longhorn-vs-storageos-vs-robin-vs-portworx-vs-linstor","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0425\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u0432 Kubernetes: OpenEBS vs Rook (Ceph) vs Rancher Longhorn vs StorageOS vs Robin vs Portworx vs Linstor | ProHoster","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/hranilishha-v-kubernetes-openebs-vs-rook-ceph-vs-rancher-longhorn-vs-storageos-vs-robin-vs-portworx-vs-linstor","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:18:10+00:00","article:modified_time":"2019-10-31T19:18:10+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37528","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 18:13:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:25:26","updated":"2026-01-23 18:13:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/37528","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=37528"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/37528\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/28163"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=37528"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=37528"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=37528"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}