Statefulset vs Daemonset in Kubernetes
Published: 2023-10-03 14:26:46

---
title: Statefulset vs Daemonset in Kubernetes
published: true
date: 2022-12-01 00:00:00 UTC
tags: 
canonical_url: 
---

In Kubernetes la più piccola unità di deploy è chiamata Pod. In che modo possiamo però distribuire la nostra applicazione tramite un controller?

In questo articolo vediamo quali sono le differenze tra due risorse fornite da Kubernetes per la distribuzione dei pod: lo **StatefulSet** e il **DaemonSet**.

# Cosa vedrai

- [DaemonSet](#daemonset)
- [StatefulSet](#statefulset)

# DaemonSet

Un DaemonSet è un controller che serve ad assicurarsi che il pod venga eseguito su tutti i nodi del cluster. Se un nodo viene aggiunto o rimosso dal cluster, il DaemonSet si occuperà di eseguire il deploy o di rimuovere il pod dal nodo.

Un esempio molto semplice di utilizzo di un DaemonSet è la necessità di esportare i log da tutti i nodi in modo semplice, attraverso uno strumento come Fluentd.

Tuttavia, i Daemonset non vengono deployati automaticamente su nodi che presentano una _taint_, come i nodi master. Le **taint** , per completezza, sono un modo per dire ai nodi di _respingere_ i pod, di modo da preservarli da eventuali problematiche: aumento delle risorse utilizzate, nodi con applicazioni di produzione che non devono essere sollecitati, e così via.

## Esempio

```
apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: my-app
spec:
 selector:
 matchLabels:
 app: my-app
 template:
 metadata:
 name: my-app
 labels:
 app: my-app
 spec:
 tolerations:
 - effect: NoSchedule
 operator: Exists
 containers:
 - name: my-app
 image: "busybox:latest"
 volumeMounts:
 - name: my-app
 mountPath: /app/
 volumes:
 - name: my-app
 persistentVolumeClaim:
 claimName: my-app
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: my-app
spec:
 accessModes:
 - ReadWriteMany
 resources:
 requests:
 storage: 50Mi

```

![Rappresentazione di un DaemonSet](https://theredcode.it/img/daemonset.png) _Rappresentazione di un DaemonSet_

# StatefulSet

Come dice anche la parola, questa tipologia di controller rappresenta delle applicazioni _stateful_: questo vuol dire che si occuperà di gestire lo **stato** degli oggetti al suo interno. Ne controlla anche il deploy, lo scaling dei pod e garantisce l’unicità e l’ordine dei pod.

Al contrario dei Deployment, non crea un ReplicaSet, perché si occupa in prima battuta di creare dei pod con una loro naming convention; questo vuol dire che se lo StatefulSet si chiama _my-app_, le diverse repliche avranno suffisso numerico relativa al numero di replica a cui si riferisce.

Ogni StatefulSet avrà il proprio stato e <ins>ciascuno dei pod creerà il proprio PVC</ins>. Questo vuol dire che uno StatefulSet con 3 repliche creerà 3 pod, ognuno con il proprio volume, quindi un totale di 3 PVC.

## Esempio

```
apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: my-app
spec:
 serviceName: "my-app"
 selector:
 matchLabels:
 app: my-app
 replicas: 3
 template:
 metadata:
 labels:
 app: my-app
 spec:
 containers:
 - name: my-app
 image: "busybox:latest"
 volumeMounts:
 - name: my-app
 mountPath: /app/ 
 volumeClaimTemplates:
 - metadata:
 name: my-app
 spec:
 accessModes: ["ReadWriteMany"]
 resources:
 requests:
 storage: 50Mi

```

![Rappresentazione di uno StatefulSet](https://theredcode.it/img/statefulset.png) _Rappresentazione di uno StatefulSet_

# Risorse utili

- [Docker](https://amzn.to/3cSVvUG) - per cominciare bene con Docker e Kubernetes
- [Kubernetes](https://amzn.to/44bLfyR) - Guida per gestire e orchestrare i container