Comprendre la gestion de l’état dans Kubernetes

Lorsque vous parlez d’applications en général, vous pouvez souvent entendre parler de l’état de l’application. Dans cette unité, nous examinons la définition de l’état et les différents types d’états afin que vous puissiez mieux préparer votre application pour gérer différents états.

État

L’état de l’application est tout stocké en mémoire au moment où l’application est en cours d’exécution. L’état peut impliquer différentes choses, mais nous nous concentrons principalement sur les données utilisateur.

Pour donner un exemple d’état d’application, imaginez que vous avez ouvert un lecteur de musique. Cette application a un état. Il sait qui vous êtes, ce que vous aimez entendre, et quelle musique vous avez téléchargée. Toutes ces informations font partie de l’état de l’application.

L’état en mémoire est les informations que l’application n’a pas besoin de rechercher ailleurs. L’état du disque contient les informations que l’application n’a pas à portée de main, de sorte qu’elle doit récupérer celle-ci à partir d’une autre source de données.

Types d’états

Il existe deux types d’états d’application. Le premier type est l’état éphémère, qui n’est pas persistant et disparaît dès que l’application est fermée.

Les conteneurs ont un état éphémère. Toutes les données stockées dans ces données sont perdues instantanément lorsque le conteneur est supprimé. Certaines applications peuvent fonctionner avec cette seule, car elles peuvent régénérer l’état à partir d’autres sources et n’ont pas besoin de l’état à stocker localement. Ces applications sont appelées stateless applications.

L’état restant qui n’est pas éphémère est appelé état persistant. L’état persistant continue d’exister après le cycle de vie d’un conteneur. La plupart des technologies de conteneur que nous utilisons ont le concept de volume, un emplacement sur disque où l’état existe. Si vous supprimez le conteneur et réactivez-le, l’état reste stocké dans un emplacement sûr et peut être utilisé à nouveau.

Les applications qui s’appuient sur un état externe à récupérer sont appelées stateful applications.

États et Kubernetes

Kubernetes peut gérer les applications sans état et avec état. Les applications sans état sont plus faciles, car nous pouvons nous concentrer uniquement sur l’application elle-même et non sur son état (car elle n’existe pas).

Pour la plupart des applications sans état, une charge de travail de déploiement simple avec un pod suffirait à disposer d’un système entièrement opérationnel et de tirer le meilleur parti de votre cluster.

La gestion des applications avec état est tout l’inverse. Dans ces cas, vous devez prendre en compte l’application et son état, où l’état est stocké, ainsi que la façon dont vous pouvez stocker l’état de manière sécurisée et fiable.

C’est pourquoi Kubernetes a également le concept de PersistentVolumes (PV) et PersistentVolumeClaims (PVC).

PersistentVolumes sont des disques alloués dans des nœuds pour stocker les états du conteneur d’un pod. Étant donné que Kubernetes est idéal pour les applications distribuées, tous les volumes créés se trouvent dans un pool de volumes disponibles. Les conteneurs prétendent ensuite cet espace pour eux-mêmes. Vous pouvez utiliser PersistentVolumeClaims pour lier un pod PersistentVolume et utiliser son espace pour stocker les données nécessaires.

Tous les fournisseurs de base de données sont des applications avec état. Si vous déployez un fournisseur de base de données dans votre cluster, vous avez besoin d’un PV et d’un PVC pour stocker les données de base de données et permettre au fournisseur de récupérer ces données même si ses conteneurs ont été supprimés.

Meilleures pratiques pour la gestion des états

L’état est présent dans la plupart des applications. Toutefois, une bonne pratique pour gérer l’état est de ne pas s'en occuper du tout.

Vous concevez n’importe quelle application efficace dans le but de la rendre hautement disponible et évolutive. L’état va dans la direction opposée. Malgré les options fournies par les fournisseurs de stockage et la facilité de déploiement et d’utilisation, l’état ne s’adapte pas facilement. Il n'est pas non plus très disponible.

État de haute disponibilité

Pour être hautement disponible, une application doit toujours être en ligne. Cette opération s’effectue via la réplication de zone et de région. Kubernetes prend en charge les zones dans la plupart de ses charges de travail. Cela signifie que vous pouvez avoir plusieurs instances d’une application déployées dans différentes zones. Toutefois, les disques ne sont pas compatibles avec la gestion par zones.

Lorsque vous déployez un nouvel PersistentVolume objet sur Kubernetes, il est lié à un disque sur un nœud. Ce disque est également lié à une zone particulière dans une région particulière. L’utilisation de la réplication de zone ou de région avec des PVS est complexe et nécessite beaucoup de maintenance, à la fois pour répliquer et synchroniser des données.

État hautement évolutif

Pour être hautement évolutive, une application doit augmenter son débit avec le nombre d’utilisateurs qui y sont connectés. Cela est compliqué dans la gestion de l’état, car tout état externe est essentiellement un disque, et un disque a un débit d’entrée et de sortie limité. La gestion du débit permet de résoudre ce problème.

Les solutions de base de données ont proposé l'idée de ReplicaSets, qui réplique l'ensemble de la base de données dans plusieurs instances. La réplication augmente le nombre de disques et les E/S pour l’état.

Sur chaque modification de base de données, l’état doit être synchronisé afin que tous les disques contiennent les mêmes données. Cette synchronisation est également complexe.

Externalisation de l’état

Azure dispose de solutions PaaS (Platform as a Service), telles qu’Azure Cosmos DB, qui sont hautement disponibles et évolutives et résolvent la plupart des problèmes de gestion de l’état pour vous.

Le stockage de l’état en externe et la suppression des besoins de maintenance peuvent vous aider à vous concentrer sur l’application et à réduire la surcharge liée à la gestion de l’intégrité des données dans votre infrastructure.