Implementaciones de Kubernetes frente a StatefulSets

110

He estado investigando mucho en Kubernetes y me gusta mucho lo que veo. Una cosa de la que no he podido tener una idea clara es cuáles son las distinciones exactas entre los recursos Deployment y StatefulSet y en qué escenarios usaría cada uno (o es uno generalmente preferido sobre el otro).

¡Cualquier experiencia que la gente pueda compartir sería increíble!

kubernetes SS781
fuente

Respuestas:

114

Las implementaciones y los controladores de replicación están diseñados para uso sin estado y son bastante livianos. StatefulSets se utilizan cuando el estado debe persistir. Por lo tanto, este último usa volumeClaimTemplates/ afirma en volúmenes persistentes para garantizar que puedan mantener el estado en los reinicios de componentes.

Por lo tanto, si su aplicación tiene estado o si desea implementar almacenamiento con estado sobre Kubernetes, use StatefulSet.

Si su aplicación no tiene estado o si el estado se puede construir desde sistemas de backend durante el inicio, utilice Implementaciones.

Se pueden encontrar más detalles sobre la ejecución de aplicaciones con estado en la entrada del blog de kubernetes de 2016 sobre aplicaciones con estado.

pagid
fuente
16
También puedo conectar los pods de una implementación con reclamos de volumen persistentes y estar seguro.
Torsten Bronger
9
@TorstenBronger Estoy de acuerdo, en ese momento volvemos a la pregunta original de cuál es el objetivo de StatefulSets?
HDave el
6
@HDave Con volúmenes dinámicos persistentes y proveedores de almacenamiento en rápido desarrollo (como Portworx, OpenEBS), el problema de la persistencia de los datos se puede resolver, pero el nombre y el orden de inicio / actualización siguen siendo diferentes con StatefulSets, lo que permite que las aplicaciones necesiten configuración maestra / esclava u otra configuración para formar correctamente un racimo. Aunque estoy de acuerdo en que quizás todo esto se pueda plegar en una sola deploymentconfiguración con una especificación simple para establecer 1 por nodo (daemonset), réplicas o ordenamiento con estado.
Mani Gandham
4
Es importante darse cuenta de que el "orden de inicio / actualización" se trata de réplicas de pod (es decir, 1, 2, 3 ...), no pods diferentes (es decir, web, srv, db, etc.). Dicho de otra manera, no sustituye a las dependencias de composición de docker.
HDave
72

  • Implementación: especifica un PersistentVolumeClaim que comparten todas las réplicas de pod. En otras palabras, volumen compartido.

    El almacenamiento de respaldo obviamente debe tener ReadWriteMany o ReadOnlyMany accessMode si tiene más de un pod de réplica.

  • StatefulSet: especifique un volumeClaimTemplates para que cada pod de réplica obtenga un PersistentVolumeClaim único asociado. En otras palabras, sin volumen compartido.

    Aquí, el almacenamiento de respaldo puede tener ReadWriteOnce accessMode.

    StatefulSet es útil para ejecutar cosas en un clúster, por ejemplo, clúster Hadoop, clúster MySQL, donde cada nodo tiene su propio almacenamiento.

Emmanuel Osimosu
fuente
23

TL; DR

La implementación es un recurso para implementar una aplicación sin estado, si se usa un PVC, todas las réplicas usarán el mismo volumen y ninguna tendrá su propio estado.

Statefulsets se utiliza para aplicaciones con estado, cada réplica del pod tendrá su propio estado y utilizará su propio volumen.

DaemonSet es un controlador que garantiza que el pod se ejecute en todos los nodos del clúster. Si se agrega / elimina un nodo de un clúster, DaemonSet agrega / elimina automáticamente el pod.

He escrito sobre las diferencias detalladas entre Implementaciones, StatefulSets y Daemonsets, y cómo implementar una aplicación de muestra usando estos Recursos K8: Implementaciones vs StatefulSets vs DaemonSets .

Ali Kahoot
fuente
4
Para continuar con su comentario, me parece que la diferencia entre los dos es que uno tiene la capacidad de especificar el almacenamiento específico del pod (y, por lo tanto, persistir en el estado específico del pod), mientras que el otro no (y, por lo tanto, solo puede persistir el servicio -en todo el estado). En ese sentido, en el nivel de servicio, ambos pueden verse como con estado. Pero en el nivel de pod, solo Statefulsets tiene estado.
scabbage
14

StatefulSet

Utilice 'StatefulSet' con aplicaciones distribuidas con estado, que requieren que cada nodo tenga un estado persistente . StatefulSet proporciona la capacidad de configurar un número arbitrario de nodos, para una aplicación / componente con estado, a través de una configuración (réplicas = N).

Hay dos tipos de aplicaciones distribuidas con estado: maestro-maestro y maestro-esclavo. Todos los nodos en una configuración maestro-maestro y los nodos esclavos en una configuración maestro-esclavo pueden hacer uso de un StatefulSet.
Ejemplos:
Maestro-Esclavo -> Nodos de datos (esclavos) en un clúster Hadoop
Maestro-Maestro -> Nodos de base de datos (maestro-maestro) en un clúster de Cassandra

Cada Pod (réplica / nodo) en un StatefulSet tiene una identidad de red única y estable. Por ejemplo, en un Cassandra StatefulSet con el nombre 'cassandra' y el número de nodos de réplica como N, cada pod (nodo) de Cassandra tiene:

  • Índice ordinal para cada grupo: 0,1, .., N-1
  • ID de red estable: cassandra-0, cassandra-1, .., cassandra-N-1
  • Un volumen persistente separado para cada pod contra una plantilla de reclamo de volumen, es decir, un almacenamiento separado para cada pod (nodo)
  • Los pods se crean en el orden 0 a N-1 y terminan en el orden inverso N-1 a 0

Consulte: https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

Despliegue

La 'implementación', por otro lado, es adecuada para aplicaciones / servicios sin estado donde los nodos no requieren ninguna identidad especial. Un equilibrador de carga puede llegar a cualquier nodo que elija. Todos los nodos son iguales. Una implementación es útil para crear cualquier número de nodos arbitrarios, a través de una configuración (réplicas = N).

Anurag
fuente
7

La diferencia entre StatefulSet y la implementación

StatefulSet es equivalente a una implementación especial. Cada pod de StatefulSet tiene un identificador de red único y estable que se puede utilizar para descubrir otros miembros del clúster. Si el nombre de StatefulSet es Kafka, entonces el primer grupo se llama Kafka-0, el segundo Kafka-1, y así sucesivamente; Se controla la secuencia de inicio y parada de la copia del pod controlada por StatefulSet. Cuando se opera el n-ésimo módulo, los primeros módulos N-1 ya están funcionando y listos. Buen estado; el pod en StatefulSet usa un volumen de almacenamiento persistente estable, implementado por PV o PVC. Al eliminar el pod, el volumen de almacenamiento asociado con StatefulSet no se elimina de forma predeterminada (para la seguridad de los datos); StatefulSet está obligado a estar vinculado al volumen PV. Se utiliza para almacenar datos de estado del módulo y también se utiliza junto con los servicios sin cabeza, declarados como pertenecientes a ese servicio sin cabeza;

Adler.Liu
fuente