{"id":71858,"date":"2020-02-28T21:00:08","date_gmt":"2020-02-28T18:00:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/patterny-hraneniya-dannyh-v-kubernetes"},"modified":"2020-03-03T16:14:09","modified_gmt":"2020-03-03T13:14:09","slug":"patterny-hraneniya-dannyh-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/patterny-hraneniya-dannyh-v-kubernetes","title":{"rendered":"Mod\u00e8les de stockage des donn\u00e9es dans Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Mod\u00e8les<\/a><\/noindex>
\nSalut, Habr !<\/p>\n

Nous vous rappelons que nous avons publi\u00e9 un autre livre extr\u00eamement int\u00e9ressant et utile sur les mod\u00e8les Kubernetes. Tout a commenc\u00e9 avec \"<\/a><\/noindex> sur les mod\u00e8les Kubernetes. Tout a commenc\u00e9 avec \"\" de Brendan Burns, et notre travail dans ce segment est d'ailleurs<\/a><\/noindex>\" de Brendan Burns, et d'ailleurs, notre travail dans ce segment a \u00e9t\u00e9 . Aujourd'hui, nous vous proposons de lire un article du blog MinIO qui pr\u00e9sente bri\u00e8vement les tendances et les sp\u00e9cificit\u00e9s des mod\u00e8les de stockage des donn\u00e9es dans Kubernetes.<\/a><\/noindex>Kubernetes a fondamentalement chang\u00e9 les mod\u00e8les traditionnels de d\u00e9veloppement et de d\u00e9ploiement d'applications. D\u00e9sormais, une \u00e9quipe peut passer seulement quelques jours \u00e0 d\u00e9velopper, tester et d\u00e9ployer une application dans diff\u00e9rents environnements, le tout au sein de clusters Kubernetes. Ce type de travail avec les technologies des g\u00e9n\u00e9rations pr\u00e9c\u00e9dentes prenait g\u00e9n\u00e9ralement des semaines, voire des mois.
\n<\/a><\/noindex><\/p>\n

Cette acc\u00e9l\u00e9ration est rendue possible gr\u00e2ce \u00e0 l'abstraction fournie par Kubernetes \u2014 c'est-\u00e0-dire gr\u00e2ce au fait que Kubernetes se charge des interactions avec les d\u00e9tails de bas niveau des machines physiques ou virtuelles, permettant aux utilisateurs de d\u00e9clarer, parmi d'autres param\u00e8tres, le processeur n\u00e9cessaire, la quantit\u00e9 de m\u00e9moire requise, et le nombre d'instances de conteneurs. \u00c9tant donn\u00e9 que le soutien de Kubernetes est assur\u00e9 par une \u00e9norme communaut\u00e9 et que l'adoption de Kubernetes ne cesse de cro\u00eetre, il est de loin le leader parmi toutes les plateformes d'orchestration de conteneurs.<\/p>\n

\u00c0 mesure que l'utilisation de Kubernetes s'\u00e9tend, la confusion concernant les mod\u00e8les de stockage des donn\u00e9es appliqu\u00e9s augmente \u00e9galement.<\/p>\n

Dans une comp\u00e9tition g\u00e9n\u00e9rale pour une part de march\u00e9 dans Kubernetes (c'est-\u00e0-dire pour le stockage des donn\u00e9es), lorsqu'il s'agit de parler de stockage de donn\u00e9es, le signal se perd dans un bruit fort.<\/b><\/i>.<\/p>\n

Kubernetes incarne un mod\u00e8le moderne de d\u00e9veloppement et de d\u00e9ploiement d'applications, ainsi que de gestion de celles-ci. Ce mod\u00e8le moderne dissocie le stockage des donn\u00e9es des calculs. Pour comprendre pleinement cette dissociation dans le contexte de Kubernetes, il est \u00e9galement n\u00e9cessaire de comprendre ce que sont les applications \u00e0 \u00e9tat et sans \u00e9tat, ainsi que la mani\u00e8re dont cela s'articule avec le stockage des donn\u00e9es. C'est ici que l'approche REST API utilis\u00e9e par S3 pr\u00e9sente des avantages clairs par rapport \u00e0 l'approche POSIX\/CSI, typique d'autres solutions.
\nKubernetes incarne un mod\u00e8le moderne de d\u00e9veloppement et de d\u00e9ploiement d'applications, ainsi que de leur gestion. Ce mod\u00e8le moderne dissocie le stockage des donn\u00e9es des calculs. Pour comprendre pleinement cette dissociation dans le contexte de Kubernetes, il est \u00e9galement n\u00e9cessaire de comprendre ce que sont les applications qui g\u00e8rent l'\u00e9tat et celles qui ne le g\u00e8rent pas, ainsi que la mani\u00e8re dont cela s'associe au stockage des donn\u00e9es. C'est ici que l'approche REST API, appliqu\u00e9e par S3, pr\u00e9sente des avantages \u00e9vidents par rapport \u00e0 l'approche POSIX\/CSI, caract\u00e9ristique d'autres solutions.<\/p>\n

Dans cet article, nous allons parler des sch\u00e9mas de stockage des donn\u00e9es dans Kubernetes et aborderons s\u00e9par\u00e9ment le d\u00e9bat sur les applications fonctionnant avec et sans \u00e9tat, afin de bien comprendre la diff\u00e9rence entre elles et pourquoi elle est importante. Par la suite, nous examinerons les applications et les sch\u00e9mas de stockage des donn\u00e9es qui les concernent \u00e0 la lumi\u00e8re des meilleures pratiques en mati\u00e8re de conteneurs et de Kubernetes.<\/p>\n

Conteneurs sans \u00e9tat<\/h4>\n

\nLes conteneurs sont, par nature, l\u00e9gers et \u00e9ph\u00e9m\u00e8res. Ils peuvent \u00eatre arr\u00eat\u00e9s, supprim\u00e9s ou d\u00e9ploy\u00e9s sur un autre n\u0153ud en quelques secondes. Dans un grand syst\u00e8me d'orchestration de conteneurs, ces op\u00e9rations se produisent constamment, et les utilisateurs ne remarquent m\u00eame pas ces changements. Cependant, les d\u00e9placements ne sont possibles que si le conteneur n'a aucune d\u00e9pendance vis-\u00e0-vis du n\u0153ud sur lequel il se trouve. Ces conteneurs sont dits fonctionner sans \u00e9tat<\/i>.<\/p>\n

Conteneurs avec \u00e9tat<\/h4>\n

\nSi un conteneur stocke des donn\u00e9es sur des dispositifs locaux connect\u00e9s (ou sur un dispositif de bloc), le stockage o\u00f9 il se trouve devra \u00eatre d\u00e9plac\u00e9 vers un nouveau n\u0153ud avec le conteneur lui-m\u00eame en cas de d\u00e9faillance. C'est crucial, car sinon, l'application ex\u00e9cut\u00e9e dans le conteneur ne pourra pas fonctionner correctement, car elle a besoin d'acc\u00e9der aux donn\u00e9es stock\u00e9es sur des supports locaux. Ces conteneurs sont dits fonctionner avec \u00e9tat<\/i>.<\/p>\n

D'un point de vue purement technique, les conteneurs avec \u00e9tat peuvent \u00e9galement \u00eatre d\u00e9plac\u00e9s vers d'autres n\u0153uds. Cela est g\u00e9n\u00e9ralement r\u00e9alis\u00e9 \u00e0 l'aide de syst\u00e8mes de fichiers distribu\u00e9s ou de stockage en r\u00e9seau de blocs attach\u00e9 \u00e0 tous les n\u0153uds sur lesquels les conteneurs fonctionnent. Ainsi, les conteneurs peuvent acc\u00e9der aux volumes pour le stockage persistant des donn\u00e9es, et l'information est stock\u00e9e sur des disques r\u00e9partis sur le r\u00e9seau. J'appellerai cette m\u00e9thode \u00abapproche conteneur avec \u00e9tat<\/i>\u00bb, et je l'appellerai ainsi pour le reste de l'article afin d'assurer une uniformit\u00e9.<\/p>\n

\"Mod\u00e8les
\n
\nDans une approche typique des conteneurs avec \u00e9tat, tous les pods d'application sont attach\u00e9s \u00e0 un syst\u00e8me de fichiers distribu\u00e9 unique - on obtient une sorte de stockage partag\u00e9, o\u00f9 toutes les donn\u00e9es des applications sont rassembl\u00e9es. Bien que des variations soient possibles, c'est une approche de haut niveau.<\/p>\n

Voyons maintenant pourquoi l'approche des conteneurs avec \u00e9tat est un anti-mod\u00e8le dans un monde ax\u00e9 sur le cloud.<\/p>\n

Conception d'applications ax\u00e9e sur le cloud<\/h4>\n

\nTraditionnellement, les applications utilisaient des bases de donn\u00e9es pour le stockage structur\u00e9 des informations et des disques locaux ou des syst\u00e8mes de fichiers distribu\u00e9s o\u00f9 toutes les donn\u00e9es non structur\u00e9es, voire semi-structur\u00e9es, \u00e9taient d\u00e9pos\u00e9es. \u00c0 mesure que les volumes de donn\u00e9es non structur\u00e9es augmentaient, les d\u00e9veloppeurs ont r\u00e9alis\u00e9 que POSIX \u00e9tait trop 'bavard', entra\u00eenant des co\u00fbts significatifs et, en fin de compte, entravant le fonctionnement des applications lors de la transition vers des \u00e9chelles v\u00e9ritablement larges.<\/p>\n

Cela a principalement contribu\u00e9 \u00e0 l'\u00e9mergence d'une nouvelle norme de stockage de donn\u00e9es, \u00e0 savoir les stockages ax\u00e9s sur le cloud, fonctionnant principalement sur la base d'API REST et lib\u00e9rant l'application de l'entretien fastidieux du stockage de donn\u00e9es local. Dans ce cas, l'application fonctionne en mode sans \u00e9tat (puisque l'\u00e9tat se trouve dans un stockage distant). Les applications modernes sont construites d\u00e8s le d\u00e9part en tenant compte de ce facteur. En g\u00e9n\u00e9ral, toute application moderne qui traite des donn\u00e9es de tout type (logs, m\u00e9tadonn\u00e9es, blobs, etc.) est bas\u00e9e sur une parologie ax\u00e9e sur le cloud, o\u00f9 l'\u00e9tat est transf\u00e9r\u00e9 dans un syst\u00e8me logiciel sp\u00e9cifiquement d\u00e9di\u00e9 \u00e0 son stockage. <\/p>\n

L'approche des conteneurs avec \u00e9tat ram\u00e8ne toute cette parologie \u00e0 son point de d\u00e9part ! <\/b><\/i><\/p>\n

Lors de l'utilisation des interfaces POSIX pour le stockage des donn\u00e9es, les applications fonctionnent de mani\u00e8re similaire \u00e0 la mani\u00e8re dont elles sauvegardent l'\u00e9tat. Cette approche s'\u00e9loigne des postulats les plus importants de la conception cloud-native, \u00e0 savoir la capacit\u00e9 d'ajuster la taille des flux de travail des applications en fonction de la charge d'entr\u00e9e, de basculer vers un nouveau n\u0153ud d\u00e8s qu'un n\u0153ud actuel \u00e9choue, et ainsi de suite.<\/p>\n

En examinant cette situation de plus pr\u00e8s, nous d\u00e9couvrons qu'en choisissant un stockage de donn\u00e9es, nous rencontrons encore et encore le dilemme \u00ab POSIX contre REST API \u00bb, MAIS avec des probl\u00e8mes suppl\u00e9mentaires li\u00e9s \u00e0 POSIX en raison de la nature distribu\u00e9e des environnements Kubernetes. En particulier,<\/p>\n