web-dev-qa-db-fra.com

Kubernetes Deployments vs StatefulSets

J'ai beaucoup fouillé dans Kubernetes et j'aime ce que je vois beaucoup! Une chose que je n'ai pas pu comprendre clairement est la distinction exacte qui existe entre les ressources Deployment et StatefulSet et dans quels scénarios les utiliseriez-vous (ou est-il généralement préférable à l'autre).

Toutes les expériences que les gens peuvent partager seraient géniales !!

64
SS781

Les déploiements et les ReplicationControllers sont conçus pour une utilisation sans état et sont plutôt légers. StatefulSets sont utilisés lorsque l'état doit être conservé. Par conséquent, ce dernier utilise volumeClaimTemplates/claim sur les volumes persistants pour s'assurer qu'ils peuvent conserver l'état lors du redémarrage des composants.

Ainsi, si votre application a un état ou si vous souhaitez déployer un stockage avec état sur Kubernetes, utilisez un StatefulSet.

Si votre application est sans état ou si l'état peut être construit à partir des systèmes dorsaux au démarrage, utilisez Deployments.

Vous trouverez plus de détails sur l'exécution d'une application avec état dans entrée de blog de 2016 de kubernetes sur les applications avec état

66
pagid
  • Déploiement - Vous spécifiez un PersistentVolumeClaim partagé par tous les réplicas de pod. En d'autres termes, volume partagé.

    Le stockage de sauvegarde doit évidemment avoir ReadWriteMany ou ReadOnlyMany accessMode si vous avez plusieurs réplicas.

  • StatefulSet - Vous spécifiez un volumeClaimTemplates afin que chaque réplica-pod reçoive un unique PersistentVolumeClaim qui lui est associé. En d'autres termes, pas de volume partagé.

    Ici, le support de stockage peut avoir ReadWriteOnce accessMode.

    StatefulSet est utile pour exécuter des tâches dans un cluster, par exemple un cluster Hadoop, un cluster MySQL, où chaque nœud a son propre stockage.

26
eosimosu

Utilisez 'StatefulSet' avec une application distribuée nécessitant que chaque nœud ait un état persistant et qu'il soit possible de configurer un nombre arbitraire de nœuds via une configuration (réplicas = 'X').

Tous les nœuds d'une configuration maître-maître et les nœuds esclaves d'une configuration maître-esclave peuvent utiliser un StatefulSet avec un service. Les nœuds maîtres (comme maître, maître secondaire) peuvent chacun être un pod avec un volume persistant avec un service, car ces nœuds n'ont pas besoin de redimensionner ou d'augmenter. Ils peuvent aussi bien être un StatefulSet avec des répliques = 1.

Des exemples de StatefulSet sont:
- Datanodes (esclaves) dans un cluster Hadoop (maître-esclave)
- Nœuds de base de données (maître-maître) dans un cluster Cassandra

Chaque pod (réplique) d'un StatefulSet a
- Une identité réseau unique et stable
- Kubernetes crée un volume persistant pour chaque volumeClaimTemplate.
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

Le 'déploiement', en revanche, convient aux applications/services sans état où les nœuds ne nécessitent aucune identité spéciale (un équilibreur de charge peut atteindre n'importe quel nœud de son choix) et où le nombre de nœuds peut être un nombre arbitraire.

6
Anurag

TL; DR

Le déploiement est une ressource pour déployer une application sans état. Si vous utilisez un PVC, tous les réplicas utiliseront le même volume et aucun d'entre eux n'aura son propre état.

Statefulsets est utilisé pour les applications avec état, chaque réplique du pod aura son propre état et utilisera son propre volume.

DaemonSet est un contrôleur qui garantit que le pod s'exécute sur tous les nœuds du cluster. Si un nœud est ajouté/supprimé d'un cluster, DaemonSet ajoute/supprime automatiquement le pod.

J'ai écrit sur les différences détaillées entre les déploiements, les StatefulSets et les Daemonsets, et sur la façon de déployer un exemple d'application à l'aide de ces ressources K8: Deployments vs StatefulSets vs DaemonSets .

2
Ali Kahoot