Kubernetes e DaemonSet

Da quanto abbiamo imparato sinora su Kubernetes, in questa piattaforma, svettano due caratteristiche principali:

• è naturalmente predisposto per lavorare su cluster ovvero abbiamo un sistema costituito da più nodi (può trattarsi di macchine fisiche, virtuali, dispositivi Raspberry o altro ancora) che collaborano al perseguimento del medesimo scopo che tipicamente è l'esecuzione di una o più applicazioni a microservizi;
• è in grado di gestire il ciclo di vita dei Pod in base alla configurazione dell'utente. Da quanto visto nella guida sappiamo ormai che possiamo indicare quante repliche vogliamo di un determinato componente e questo rimarrà il numero di istanze mantenuto in vita: non se ne creeranno di ulteriori (non potrà farlo nemmeno il gestore del cluster) né si permetterà che alcune di queste falliscano e scompaiano dalla nostra applicazione.

Il meccanismo esposto nel secondo punto viene gestito mediante i ReplicaSet una componente alla quale tipicamente accediamo tramite i Deployment e la cui esistenza è rivelata per lo più dell'attributo replicas inserito all'interno della configurazione YAML di questi.

Esistono però casi nei quali vogliamo accertarci che di una specifica componente ne sia in esecuzione una istanza per ogni nodo del cluster. Questo, ad esempio, può capitare nel caso in cui abbiamo degli strumenti che si occupano di raccolta di log, metriche, storage di informazioni, attività sistemistiche di vario genere e ci si vuole accertare che ognuna delle loro repliche sia presente su un nodo diverso. In tal caso, chiamiamo in causa un'ulteriore componente che prende il nome di DaemonSet.

È sufficiente la sola presenza della suffisso Set all'interno del suo nome per farci capire che questo strumento sarà in grado di gestire un'insieme di Pod. Proprio i Pod sappiamo essere l'unità minimale di deployment in Kubernetes ed, in questo caso, verranno schedulati affinché la loro distribuzione sia uniforme sui vari nodi che compongono il cluster.

Quindi il DamonSet può essere considerato un qualcosa di simile per molti aspetti al ReplicaSet ma per altri versi mostra delle caratteristiche assolutamente originali che lo distinguono da quest'ultimo componente.

Anche i DaemonSet saranno gestiti mediante kubectl e configurazione dichiarativa. Quindi anche per questa componente ci preoccuperemo di scrivere una configurazione in YAML, attivarla con il comando apply e verificarne lo stato di salute mediante describe e get.

Vediamo subito un esempio di configurazione con un caso piuttosto comune che potremmo definire quasi didattico in quanto è il tipico caso di studio che viene preso in considerazione per approcciare il DaemonSet anche nella documentazione. Il file per noi si chiamerà daemonset.yaml:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  labels:
    app: fluentd-app
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      containers:
      - name: fluentd
        image: fluentd
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

Prendiamo in esame il caso in cui vorremo avviare su ogni nodo un servizio fluentd, messo a disposizione da immagini Docker, e finalizzato all'unificazione dei dati di log.

Come si può vedere, lo schema YAML è simile a quanto a noi già noto. Abbiamo un selector per rintracciare i componenti con le stesse label (anche qui sfruttiamo l'importantissimo disaccoppiamento delle componenti di Kubernetes), il template dei container e la definizione dei volume.

Non si fa riferimento al numero di repliche ma al perché queste saranno generate in base ai nodi che compongono il cluster. Possiamo attivare il file con:

kubectl apply -f daemonset.yaml

e verificare l'esistenza dei Pod attivati con:

kubectl describe daemonset/fluentd-app

Tra l'output prodotto da tale comando, troveremo valori di questo genere:

Desired Number of Nodes Scheduled: 2
Current Number of Nodes Scheduled: 2
Number of Nodes Scheduled with Up-to-date Pods: 2
Number of Nodes Scheduled with Available Pods: 2

che metterà a confronto nodi e Pod ad essi collegati: tali parametri, come si può presumere, dipenderanno dall'architettura del cluster che abbiamo avviato. Infine, potremo andare a verificare i Pod in esecuzione con get e grazie a -o wide verificare il nome del nodo su cui il singolo Pod è in esecuzione:

kubectl get pods -o wide

Come ogni altra componente, potremo rimuovere un DaemonSet qualora non fossimo più interessati al suo funzionamento ed il tutto sarà praticabile con il comando delete. La sintassi da invocare sarà:

kubectl delete -f daemonset.yaml