Statefulset vs Daemonset in Kubernetes
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
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
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 ciascuno dei pod creerà il proprio PVC. 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
Risorse utili
- Docker - per cominciare bene con Docker e Kubernetes
- Kubernetes - Guida per gestire e orchestrare i container