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.

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