Applications sans état Stateful vs sur Kubernetes
Commençons par une définition naïve de «l'apatridité», puis progressons lentement vers une vue plus rigoureuse et réelle.
Une application apatride est celle qui ne dépend pas de stockage persistant. La seule chose dont votre cluster est responsable, c'est le code et d'autres contenus statiques, hébergés dessus. C'est tout, pas de bases de données changeantes, pas d'écrits et pas de fichiers laissés lorsque le pod est supprimé.
Une application avec état, en revanche, a plusieurs autres paramètres qu'il est censé s'occuper dans le cluster. Il existe des bases de données dynamiques qui, même lorsque l'application est hors ligne ou supprimée, persiste sur le disque. Sur un système distribué, comme Kubernetes, cela soulève plusieurs problèmes. Nous les examinerons en détail, mais clarifions d'abord certaines idées fausses.
Les services apatrides ne sont pas vraiment «apatrides»
Qu'est-ce que cela signifie lorsque nous disons l'état d'un système? Eh bien, considérons l'exemple simple suivant d'une porte automatique.
La porte s'ouvre lorsque le capteur détecte quelqu'un qui s'approche, et il ferme une fois que le capteur n'obtient aucune entrée pertinente.
En pratique, votre application apatride est similaire à ce mécanisme ci-dessus. Il peut avoir beaucoup plus d'états que simplement fermés ou ouverts, et de nombreux types d'entrée différents le rendant plus complexe mais essentiellement le même.
Il peut résoudre des problèmes compliqués en recevant simplement une entrée et en effectuant des actions qui dépendent à la fois de l'entrée, et «l'état» dans. Le nombre d'états possibles est prédéfini.
L'apatrise est donc un terme impropre.
Les applications apatrides, en pratique, peuvent également tricher un peu en économisant des détails sur, disons, les sessions clients sur le client lui-même (les cookies HTTP sont un excellent exemple) et ont toujours un joli apatritie qui les ferait fonctionner parfaitement sur le cluster.
Par exemple, les détails de session d'un client comme quels produits ont été enregistrés dans le panier et non vérifiés peuvent tous être stockés sur le client et la prochaine fois qu'une session commencera ces détails pertinents.
Sur un cluster Kubernetes, une application sans état n'a pas de stockage ou de volume persistant qui lui est associé. Du point de vue des opérations, c'est une excellente nouvelle. Différentes pods dans tout le cluster peuvent fonctionner de manière indépendante avec plusieurs demandes qui leur viennent simultanément. Si quelque chose ne va pas, vous pouvez simplement redémarrer l'application et il reviendra à l'état initial avec peu de temps d'arrêt.
Services avec état et théorème CAP
Les services avec état, en revanche, devront s'inquiéter de beaucoup, beaucoup de cas de bord et de problèmes étranges. Un pod est accompagné d'au moins un volume et si les données de ce volume sont corrompues, cela persiste même si l'ensemble du cluster est redémarré.
Par exemple, si vous exécutez une base de données sur un cluster Kubernetes, tous les pods doivent avoir un volume local pour stocker la base de données. Toutes les données doivent être en parfaite synchronisation.
Donc, si quelqu'un modifie une entrée dans la base de données, et cela a été fait sur le pod A, et une demande de lecture est disponible sur Pod B pour voir ces données modifiées, alors le pod B doit montrer que les dernières données ou vous donner un message d'erreur. Ceci est connu comme cohérence.
Cohérence, Dans le contexte d'un cluster Kubernetes, signifie Chaque lecture reçoit l'écriture la plus récente ou un message d'erreur.
Mais cela coupe contre disponibilité, L'une des raisons les plus importantes d'avoir un système distribué. La disponibilité implique que votre application fonctionne aussi près de la perfection que possible, 24 heures sur 24, avec le moins d'erreur que possible.
On peut affirmer que vous pouvez éviter tout cela si vous n'avez qu'une seule base de données centralisée qui est responsable de la gestion de tous les besoins de stockage persistants. Maintenant, nous sommes de retour à un seul point d'échec, ce qui est un autre problème qu'un Kubernetes Clusters est censé résoudre en premier lieu.
Vous devez avoir une façon décentralisée de stocker des données persistantes dans un cluster. Communément appelé partitionnement du réseau. De plus, votre cluster doit être en mesure de survivre à l'échec des nœuds exécutant l'application avec état. Ceci est connu comme tolérance de partition.
Tout service (ou application) avec état, exécuté sur un cluster Kubernetes, doit avoir un équilibre entre ces trois paramètres. Dans l'industrie, il est connu sous le nom de théorème de CAP où les compromis entre la cohérence et la disponibilité sont considérés en présence de partitionnement du réseau.
Autres références
Pour plus d'informations sur le théorème CAP, vous voudrez peut-être voir cette excellente conversation donnée par Bryan Cantrill, qui prend de plus près de plus près la gestion des systèmes distribués en production.