sts statefulset replicas example deploy kubernetes

statefulset - replicas kubernetes



Implementaciones de Kubernetes vs StatefulSets (4)

He estado investigando mucho sobre 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!


Las implementaciones y los controladores de replicación están diseñados para uso sin estado y son bastante ligeros. StatefulSets se utilizan cuando el estado tiene que persistir. Por lo tanto, estos últimos usan volumeClaimTemplates / reclamos en volúmenes persistentes para garantizar que puedan mantener el estado en todos los reinicios de componentes.

Entonces, si su aplicación tiene estado o si desea implementar almacenamiento con estado sobre Kubernetes, use un StatefulSet.

Si su aplicación no tiene estado o si el estado se puede construir a partir de sistemas de fondo durante el inicio, use Implementaciones.

Se pueden encontrar más detalles sobre la ejecución de aplicaciones con estado en StatefulSets


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 de ellas tendrá su propio estado.

Statefulsets se usa para aplicaciones Stateful, cada réplica del pod tendrá su propio estado y usará 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 utilizando estos Recursos K8: Implementaciones vs StatefulSets vs DaemonSets .


Use ''StatefulSet'' con una aplicación distribuida que requiere que cada nodo tenga un estado persistente y la capacidad de configurar un número arbitrario de nodos a través de una configuración (réplicas = ''X'').

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 junto con un Servicio. Los nodos maestros (como maestro, maestro-secundario) pueden ser cada uno un Pod con un volumen persistente junto con un Servicio, ya que estos nodos no necesitan escalar hacia arriba o hacia abajo. También pueden ser un StatefulSet con réplicas = 1.

Ejemplos de StatefulSet son:
- Nodos de datos (esclavos) en un clúster Hadoop (maestro-esclavo)
- Nodos de base de datos (maestro-maestro) en un clúster Cassandra

Cada Pod (réplica) en un StatefulSet tiene
- Una identidad de red única y estable.
- Kubernetes crea un volumen persistente para cada VolumeClaimTemplate
https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/

El ''despliegue'', por otro lado, es adecuado para aplicaciones / servicios sin estado donde los nodos no requieren ninguna identidad especial (un equilibrador de carga puede alcanzar cualquier nodo que elija) y el número de nodos puede ser un número arbitrario.


  • Implementación: se 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: especifica un volumenClaimTemplates para que cada pod de réplica obtenga un PersistentVolumeClaim único asociado con él. En otras palabras, no hay volumen compartido.

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

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