🏑 👌🏿 🤳🏻 Modèles de stockage Kubernetes 🔀 ☝🏽 👩🏽‍⚖️

Bonjour, Habr!

Nous vous rappelons que nous avons publié un autre livre extrêmement intéressant et utile sur les modèles Kubernetes. Tout a commencé avec les « Patterns » de Brendan Burns et, soit dit en passant, le travail dans ce segment bat son plein . Aujourd'hui, nous vous invitons à lire un article du blog MinIO qui résume les tendances et les spécificités des modèles de stockage de données dans Kubernetes.

Kubernetes a fondamentalement changé les modèles traditionnels de développement et de déploiement d'applications. Maintenant, l'équipe peut prendre des jours pour développer, tester et déployer l'application - dans différents environnements, et tout cela au sein des clusters Kubernetes. Un tel travail avec la technologie des générations précédentes prenait généralement des semaines, voire des mois.

Cette accélération a été rendue possible grâce à l'abstraction fournie par Kubernetes - c'est-à-dire du fait que Kubernetes lui-même interagit avec les détails de bas niveau des machines physiques ou virtuelles, permettant aux utilisateurs de déclarer, entre autres paramètres, le processeur souhaité, la mémoire requise, le nombre d'instances de conteneur. Étant donné que Kubernetes est pris en charge par une énorme communauté et que la portée de Kubernetes est en constante expansion, il domine largement sur toutes les plates-formes d'orchestration de conteneurs.

À mesure que l'utilisation de Kubernetes se développe, la confusion au sujet des modèles de stockage qui y sont utilisés augmente .

Avec la concurrence générale pour un morceau de tarte Kubernetes (c'est-à-dire pour le stockage de données), quand il s'agit de stockage de données, le signal se noie dans un bruit fort.
Kubernetes incarne un modèle moderne de développement, de déploiement et de gestion d'applications. Un tel modèle moderne détache le stockage de données de l'informatique. Pour bien comprendre ce détachement dans le contexte de Kubernetes, vous devez également comprendre ce que sont les applications avec état et sans état, et comment le stockage de données est combiné avec cela. C'est là que l'approche de l'API REST utilisée par S3 présente des avantages évidents par rapport à l'approche POSIX / CSI qui est typique des autres solutions.

Dans cet article, nous parlerons des modèles de stockage dans Kubernetes et nous discuterons séparément du débat sur les applications sans état et sans état, afin que nous puissions clairement comprendre la différence entre elles et pourquoi elle est importante. Plus loin dans le texte, nous examinerons les applications et les modèles de stockage de données qui y sont utilisés à la lumière des meilleures pratiques pour travailler avec des conteneurs et Kubernetes.

Conteneurs apatrides

Les conteneurs sont intrinsèquement légers et éphémères. Ils peuvent être facilement arrêtés, supprimés ou déployés sur un autre nœud - tout cela prend quelques secondes. Dans un grand système d'orchestration de conteneurs, ces opérations se produisent tout le temps et les utilisateurs ne remarquent même pas ces modifications. Cependant, les mouvements ne sont possibles que si le conteneur n'a pas de dépendances sur le nœud sur lequel il se trouve. Ces conteneurs fonctionneraient sans la préservation de l'État .

Conteneurs avec état

Si le conteneur stocke des données sur des périphériques connectés localement (ou sur un périphérique bloc), l'entrepôt de données sur lequel il se trouve devra être déplacé vers un nouveau nœud avec le conteneur lui-même - en cas de défaillance. Ceci est important, car sinon l'application exécutée dans le conteneur ne pourra pas fonctionner correctement, car elle doit accéder aux données stockées sur les médias locaux. Ces conteneurs seraient en état .

D'un point de vue purement technique, les conteneurs avec état peuvent également être déplacés vers d'autres nœuds. En règle générale, cela est réalisé à l'aide de systèmes de fichiers distribués ou de blocs de stockage réseau attachés à tous les nœuds sur lesquels les conteneurs fonctionnent. Ainsi, les conteneurs ont accès aux volumes pour le stockage de données persistantes et les informations sont stockées sur des disques situés sur le réseau. J'appellerai une telle méthode une « approche de conteneur préservant l'état », et dans le reste de l'article je l'appellerai par souci d'uniformité.

Dans une approche de conteneur avec état typique, tous les modules d'application sont attachés à un système de fichiers distribué - une sorte de stockage partagé est obtenu, où toutes les données d'application sont acquises. Bien que certaines variations soient possibles, il s'agit d'une approche de haut niveau.

Voyons maintenant pourquoi l'approche des conteneurs avec état dans le monde basé sur le cloud est anti-modèle.

Conception d'applications basées sur le cloud

Traditionnellement, les applications utilisaient des bases de données pour le stockage structuré des informations et des disques locaux ou des systèmes de fichiers distribués, où toutes les données non structurées ou même semi-structurées étaient vidées. Alors que le volume de données non structurées augmentait, les développeurs ont réalisé que POSIX était trop «bavard», associé à des coûts importants et, en fin de compte, interfère avec l'application lors du passage à une très grande échelle.

Cela a principalement contribué à l'émergence d'une nouvelle norme pour le stockage de données, à savoir les stockages basés sur le cloud qui fonctionnent principalement sur la base de l'API REST et libèrent l'application de la maintenance fastidieuse de l'entrepôt de données local. Dans ce cas, l'application entre en fait dans le mode de fonctionnement sans enregistrer l'état (car l'état se trouve dans le stockage distant). Des applications modernes sont construites à partir de zéro en tenant déjà compte de ce facteur. En règle générale, toute application moderne qui traite des données d'une sorte ou d'une autre (journaux, métadonnées, blobs, etc.) est construite sur un paradigme orienté cloud, où l'état est transféré vers un système logiciel spécialement alloué pour son stockage.

Une approche de conteneur dynamique fait que tout ce paradigme revient exactement là où il a commencé!

Lorsque vous utilisez des interfaces POSIX pour stocker des données, les applications fonctionnent de la même manière que si elles maintenaient l'état, et pour cette raison, s'écartent des postulats les plus importants de la conception basée sur le cloud, c'est-à-dire de la possibilité de faire varier la taille des workflows d'application en fonction de l'entrée. charger, déplacer vers un nouveau nœud dès que le nœud actuel tombe en panne, etc.

Un examen plus approfondi de cette situation révèle que lors du choix d'un entrepôt de données, nous sommes confrontés à maintes reprises au dilemme «POSIX versus API REST», MAIS avec une aggravation supplémentaire des problèmes POSIX causés par la nature distribuée des environnements Kubernetes. En particulier,

POSIX : POSIX , . , . API , , S3 API, , , «» . , . .
: , , . , , ( ), , . - POSIX . , S3 API , , , .
: POSIX : . - . , API, , , ..
: , . , , , . , , , .

Alors que l'interface de stockage de données de conteneur (CSI) a beaucoup aidé à la distribution du niveau de volume de Kubernetes, le transmettant partiellement à des fournisseurs d'entrepôt de données tiers, mais a également contribué accidentellement à la conviction que l'approche de conteneur avec état était la méthode recommandée de stockage de données dans Kubernetes.

CSI a été développé comme standard pour fournir des systèmes de stockage de blocs et de fichiers arbitraires pour les applications héritées lorsque vous travaillez avec Kubernetes. Et, comme cela a été montré dans cet article, la seule situation où une approche de conteneur avec état (et CSI dans sa forme actuelle) est appropriée est lorsque l'application elle-même est un système hérité dans lequel il est impossible d'ajouter la prise en charge de l'API de stockage de données d'objet.

Il est important de comprendre que l'utilisation de CSI dans sa forme actuelle, c'est-à-dire lors du montage de volumes lorsque vous travaillez avec des applications modernes, nous rencontrerons environ les mêmes problèmes que ceux rencontrés dans les systèmes où le stockage des données est organisé dans le style POSIX.

Meilleure approche

Dans ce cas, il est important de comprendre que la plupart des applications ne sont pas intrinsèquement affûtées spécifiquement pour un travail avec ou sans conservation de l'état. Ce comportement dépend de l'architecture globale du système et des options spécifiques sélectionnées lors de la conception. Parlons un peu des applications avec état.

En principe, toutes les données d'application peuvent être divisées en plusieurs grands types:

Consigner les données
Données d'horodatage
Données de transaction
Métadonnées
Images de conteneurs
Données blob (blobs)

Tous ces types de données sont très bien pris en charge sur les plates-formes de stockage de données modernes, et il existe plusieurs plates-formes basées sur le cloud adaptées pour fournir des données dans chacun de ces formats spécifiques. Par exemple, les données de transaction et les métadonnées peuvent résider dans une base de données cloud moderne telle que CockroachDB, YugaByte, etc. Les images de conteneur ou les données d'objets blob peuvent être stockées dans le registre Docker basé sur MinIO. Les données d'horodatage peuvent être stockées dans une base de données de séries temporelles, comme InfluxDB, etc. Nous n'entrerons pas dans les détails de chaque type de données et applications associées, mais l'idée générale est d'éviter le stockage persistant de données basé sur le montage de disque local.

En outre, il est souvent efficace de fournir une couche de mise en cache temporaire, qui sert de type de stockage de fichiers temporaires pour les applications, mais les applications ne doivent pas dépendre de ce niveau comme source de vérité.

Stockage d'applications avec état

Alors que dans la plupart des cas, il est utile de conserver les applications sans état, les applications conçues pour stocker des données - par exemple, les bases de données, les magasins d'objets, les magasins de clés et de valeurs - doivent conserver leur état. Voyons pourquoi ces applications sont déployées sur Kubernetes. Prenons l'exemple de MinIO, mais des principes similaires s'appliquent à tous les autres grands systèmes de stockage basés sur le cloud.

Les applications centrées sur le cloud sont conçues pour maximiser l'utilisation de la flexibilité inhérente aux conteneurs. Cela signifie qu'ils ne font aucune hypothèse sur l'environnement dans lequel ils seront déployés. Par exemple, MinIO utilise un mécanisme de codage d'effacement interne, qui fournit au système une stabilité suffisante pour qu'il reste opérationnel même si la moitié des disques tombent en panne. MinIO gère également l'intégrité et la sécurité des données à l'aide de ses propres hachage et chiffrement côté serveur.

Pour de telles applications basées sur le cloud, les volumes persistants locaux (PV) sont les plus pratiques comme stockage de sauvegarde. Le PV local offre la possibilité de stocker des données brutes, tandis que les applications exécutées au-dessus de ces PV collectent indépendamment des informations pour mettre à l'échelle les données et gérer les besoins croissants de données.

Cette approche est beaucoup plus simple et beaucoup plus évolutive par rapport aux systèmes PV basés sur CSI, qui apportent leurs propres niveaux de gestion des données et de redondance au système; le fait est que ces niveaux entrent généralement en conflit avec des applications conçues selon le principe de la préservation de l'État.

Mouvement confiant pour détacher les données de l'informatique

Dans cet article, nous avons expliqué comment les applications sont réorientées pour fonctionner sans enregistrer l'état, ou, en d'autres termes, le stockage de données est séparé du calcul sur celles-ci. En conclusion, nous considérons quelques exemples concrets d'une telle tendance.

Spark , la célèbre plate-forme d'analyse de données, est traditionnellement utilisée avec un déploiement avec état et un déploiement sur le système de fichiers HDFS. Cependant, à mesure que Spark passe à un monde basé sur le cloud, cette plate-forme est de plus en plus utilisée sans préservation de l'état à l'aide de `s3a`. Spark utilise s3a pour transférer l'état vers d'autres systèmes, tandis que les conteneurs Spark eux-mêmes fonctionnent entièrement sans préservation de l'état. Autres acteurs de grandes entreprises dans le domaine de l'analyse des mégadonnées, en particulier Vertica , Teradata, Greenplum va également travailler avec la division du stockage de données et de l'informatique.

Des modèles similaires peuvent également être observés sur d'autres grandes plates-formes analytiques, notamment Presto, Tensorflow to R, Jupyter. Le téléchargement de l'état vers des systèmes de stockage cloud distants facilite la gestion et la mise à l'échelle de votre application. De plus, il facilite la portabilité de l'application vers une variété d'environnements.