Pourquoi StatefulSets? Un pod sans état ne peut-il pas utiliser des volumes persistants?
Je suis une recrue de Kubernetes, comme on peut probablement le supposer, alors pardonnez-moi si mon utilisation de la terminologie n'est pas tout à fait correcte. J'espère que l'intention de ma question est néanmoins claire.
J'essaie d'envelopper ma tête autour Stateful Sets . En quoi leur utilisation diffère-t-elle de l'utilisation de pods "sans état" avec des volumes persistants? Autrement dit, en supposant qu'un pod "normal" puisse prétendre à un stockage persistant, quelle chose évidente me manque qui nécessite cette nouvelle construction (avec un démarrage/arrêt ordonné, etc.)?
Oui, un pod régulier peut utiliser un volume persistant. Cependant, il existe parfois plusieurs modules qui forment logiquement un "groupe". Des exemples de cela seraient des répliques de bases de données, des hôtes ZooKeeper, Kafka, etc. Dans tous ces cas, il y a un tas de serveurs et ils travaillent ensemble et se parlent. Ce qui est spécial à leur sujet est que chaque individu du groupe a une identité. Par exemple, pour un cluster de base de données, un est le maître et deux sont des suiveurs et chacun des suiveurs communique avec le maître pour lui faire savoir ce qu'il a et n'a pas synchronisé. Les suiveurs savent donc que "db-x-0" est le maître et le maître sait que "db-x-2" est un suiveur et a toutes les données jusqu'à un certain point mais a encore besoin de données au-delà.
Dans de telles situations, vous avez besoin de quelques choses que vous ne pouvez pas facilement obtenir à partir d'un pod régulier:
- Un nom prévisible: vous voulez commencer vos pods en leur disant où se trouver pour qu'ils puissent former un cluster, élire un leader, etc. mais vous devez connaître leurs noms à l'avance pour le faire. Les noms de pods normaux sont aléatoires, vous ne pouvez donc pas les connaître à l'avance.
- Une adresse/nom DNS stable: vous voulez que les noms disponibles à l'étape (1) restent les mêmes. Si un pod normal redémarre (vous redéployez, l'hôte où il s'exécutait meurt, etc.) sur un autre hôte, il obtiendra un nouveau nom et une nouvelle adresse IP.
- Un lien persistant entre un individu du groupe et son volume persistant: si l'hôte sur lequel un de votre maître de base de données s'exécute meurt, il sera déplacé un nouvel hôte mais doit se connecter au même volume persistant car il y a un et un seul volume qui contient les bonnes données pour cet "individu". Ainsi, par exemple, si vous redéployez votre groupe de 3 hôtes de base de données, vous voulez que la même personne (par nom DNS et adresse IP) obtienne le même volume persistant afin que le maître soit toujours le maître et ait toujours les mêmes données, replica1 obtient son données, etc.
Les StatefulSets résolvent ces problèmes car ils fournissent (citant https://kubernetes.io/docs/concepts/abstractions/controllers/statefulsets/ ):
- Identifiants réseau stables et uniques.
- Stockage stable et persistant.
- Déploiement et mise à l'échelle ordonnés et harmonieux.
- Suppression et résiliation ordonnées et gracieuses.
Je n'ai pas vraiment parlé de (3) et (4) mais cela peut aussi aider avec les clusters car vous pouvez dire au premier à déployer pour devenir le maître et au suivant de trouver le premier et de le traiter comme maître, etc.
Comme certains l'ont noté, vous pouvez en effet certains des mêmes avantages en utilisant des pods et des services réguliers, mais c'est beaucoup plus de travail. Par exemple, si vous vouliez 3 instances de base de données, vous pouvez créer manuellement 3 déploiements et 3 services. Notez que vous devez créer manuellement 3 déploiements car vous ne pouvez pas avoir de point de service sur un seul pod dans un déploiement. Ensuite, pour évoluer, vous devez créer manuellement un autre déploiement et un autre service. Cela fonctionne et était une pratique quelque peu courante avant l'arrivée de PetSet/PersistentSet. Notez qu'il manque certains des avantages énumérés ci-dessus (mappage de volume persistant et ordre de démarrage fixe par exemple).