DaemonSet in Kubernetes: tutorial, casi d'uso e best practice

Tutorial sui DaemonSet in Kubernetes

Questo tutorial spiega come creare e utilizzare un DaemonSet. È tratto e adattato dalla documentazione di Kubernetes.

1. Creare un DaemonSet in Kubernetes

Per creare un DaemonSet in Kubernetes, lo definisca in un manifest YAML utilizzando apiVersion: apps/v1 e kind: DaemonSet. Il manifest deve includere i campi standard di Kubernetes come metadata e spec, oltre a un template di pod in .spec.template. Il campo .spec.selector del DaemonSet deve corrispondere alle label assegnate al template del pod; una volta creato il DaemonSet, questo selector non può essere modificato. Kubernetes richiede inoltre che la restart policy del pod sia Always, in modo esplicito o tramite l'impostazione predefinita.

Ad esempio, il manifest seguente crea un semplice DaemonSet che esegue un container su ogni nodo idoneo:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: example-daemonset
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: example
  template:
    metadata:
      labels:
        app.kubernetes.io/name: example
    spec:
      containers:
      - name: pause
        image: registry.k8s.io/pause

Gli amministratori possono estendere il template del pod con opzioni come richieste di risorse, volume mount, toleration, node selector e node affinity. Queste impostazioni determinano come vengono eseguiti i pod del DaemonSet e, quando sono specificati vincoli di scheduling, quali nodi sono idonei a ospitarli. La documentazione di Kubernetes fornisce un esempio di base in cui il DaemonSet schedula un pod su ogni nodo applicabile.

2. Distribuire un DaemonSet

Una volta creato il manifest del DaemonSet, lo distribuisca nel cluster con kubectl apply. Se il manifest è salvato localmente come daemonset.yaml, esegua:

kubectl apply -f daemonset.yaml

Kubernetes mostra inoltre come applicare un DaemonSet direttamente da un manifest YAML ospitato online. Ad esempio:

kubectl apply -f https://k8s.io/examples/application/basic-daemonset.yaml

Il comando kubectl apply invia la configurazione all'API di Kubernetes, dopodiché il controller del DaemonSet determina quali nodi sono idonei e crea i pod necessari. Quando nuovi nodi idonei entrano nel cluster, il controller vi crea automaticamente i pod del DaemonSet. I pod associati ai nodi rimossi vengono successivamente eliminati tramite garbage collection.

Dopo la distribuzione, le modifiche al DaemonSet possono generalmente essere gestite modificando il manifest ed eseguendo nuovamente kubectl apply. Per i DaemonSet che utilizzano la strategia RollingUpdate, le modifiche al template del pod avviano un aggiornamento graduale dei pod gestiti. Kubernetes supporta anche la strategia di aggiornamento OnDelete, per i casi in cui gli amministratori vogliono che i pod sostitutivi vengano creati solo dopo l'eliminazione manuale di quelli esistenti.

3. Verificare i pod del DaemonSet

Dopo aver distribuito un DaemonSet, verifichi che i suoi pod siano in esecuzione sui nodi previsti. La documentazione di Kubernetes consiglia di elencare i pod con l'opzione -o wide, che include il nodo assegnato a ciascun pod:

kubectl get pods -o wide

Per un DaemonSet destinato a essere eseguito in tutto il cluster, l'output dovrebbe mostrare un pod del DaemonSet su ogni nodo idoneo. La colonna NODE consente di confermare facilmente che i pod sono distribuiti come previsto.

Negli ambienti con molti workloads, utilizzi le label definite nel template del pod del DaemonSet per filtrare i risultati. Per l'esempio precedente, il comando sarebbe:

kubectl get pods -l app.kubernetes.io/name=example -o wide

Può anche ispezionare direttamente la risorsa DaemonSet con:

kubectl get daemonset example-daemonset

oppure utilizzare il nome abbreviato della risorsa:

kubectl get ds example-daemonset

Lo stato del DaemonSet aiuta gli amministratori a confrontare il numero desiderato di pod con il numero di pod aggiornati, pronti e disponibili. Se singoli pod non funzionano correttamente, comandi come kubectl describe pod <pod-name> e kubectl logs <pod-name> consentono di indagare su problemi di scheduling o a livello di container. Il tutorial di base sui DaemonSet di Kubernetes verifica il successo della distribuzione controllando che l'elenco dei pod risultante contenga un pod per ogni nodo applicabile.

Best practice per i DaemonSet in Kubernetes

1. Dimensionare correttamente richieste e limiti di CPU e memoria

Impostare richieste e limiti adeguati di CPU e memoria è fondamentale per la stabilità di un DaemonSet. Le richieste definiscono le risorse minime necessarie a un pod, mentre i limiti stabiliscono il massimo che può consumare. Un over-provisioning spreca risorse e può causare errori di scheduling sui nodi con risorse limitate. Un under-provisioning comporta il rischio di eviction dei pod o di degrado delle prestazioni. Analizzi il profilo di risorse del workload per determinare valori predefiniti ragionevoli, assicurando che ogni pod del DaemonSet possa essere allocato senza difficoltà su ogni nodo di destinazione.

Riveda e adegui periodicamente le impostazioni delle risorse man mano che l'applicazione evolve. I requisiti di risorse possono cambiare a causa di nuove funzionalità, aumento del carico o modifiche all'infrastruttura sottostante. Negli ambienti Kubernetes dinamici, la messa a punto periodica di richieste e limiti previene la contesa di risorse e favorisce un utilizzo efficiente del cluster. Integri le revisioni delle risorse nel processo di change management per un'ottimizzazione continua.

2. Basare le impostazioni delle risorse sull'utilizzo storico

Le richieste di risorse dovrebbero riflettere il comportamento dei pod del DaemonSet sotto carichi reali, anziché basarsi solo su stime iniziali. Utilizzi le metriche storiche di CPU e memoria provenienti da strumenti come Prometheus, Grafana o la piattaforma di monitoraggio del Suo cloud per identificare l'utilizzo tipico, i picchi di domanda e le differenze tra i nodi. Imposti richieste sufficientemente elevate da sostenere il funzionamento normale, evitando però di riservare risorse inutilmente su ogni nodo di destinazione.

Analizzi metriche basate sui percentili su periodi rappresentativi, invece di affidarsi a medie di breve termine. Le richieste di CPU possono spesso basarsi sull'utilizzo sostenuto con un margine per i picchi, mentre le richieste di memoria devono tenere conto dei picchi osservati. Poiché i DaemonSet moltiplicano il loro footprint di risorse su tutti i nodi, anche piccoli miglioramenti alle impostazioni per singolo pod possono liberare una capacità significativa del cluster.

3. Gestire la memoria in modo più conservativo rispetto alla CPU

I limiti di CPU e memoria hanno comportamenti di errore diversi in Kubernetes. Quando un container raggiunge il proprio limite di CPU, Kubernetes ne limita l'utilizzo (throttling), con il risultato di un'elaborazione più lenta. Quando un container supera il proprio limite di memoria, invece, può essere terminato dal kernel con un errore di out-of-memory (OOM). Per gli agenti a livello di nodo, riavvii ripetuti possono creare lacune nella copertura di logging, monitoraggio o sicurezza.

Imposti richieste e limiti di memoria con un margine sufficiente per picchi temporanei e per la crescita del workload. Monitori i picchi di utilizzo della memoria e gli eventi OOM prima di ridurre le allocazioni. Per gli agenti con requisiti di memoria imprevedibili, un limite di memoria troppo restrittivo può risultare più dannoso di una moderata sovra-allocazione: convalidi quindi i limiti rispetto ai pattern di utilizzo in produzione.

4. Utilizzare la strategia di aggiornamento appropriata

I DaemonSet supportano le strategie di aggiornamento RollingUpdate e OnDelete. RollingUpdate, la strategia predefinita, sostituisce automaticamente i pod esistenti quando il template del pod del DaemonSet cambia. Impostazioni come maxUnavailable e maxSurge consentono di controllare quanti pod del DaemonSet possono risultare non disponibili o essere aggiunti temporaneamente durante un aggiornamento.

Utilizzi OnDelete quando la sostituzione dei pod deve essere controllata in modo esplicito. Con questa strategia, l'aggiornamento del template del pod non sostituisce automaticamente i pod esistenti; gli amministratori devono eliminarli prima che Kubernetes crei i pod dal nuovo template. Qualunque strategia scelga, consideri l'effetto dell'indisponibilità degli agenti sulla copertura di logging, monitoraggio, networking o sicurezza durante gli aggiornamenti.

5. Monitorare continuamente l'efficienza al variare del cluster

Il consumo di risorse di un DaemonSet cresce con il numero di nodi idonei. Un pod che utilizza risorse modeste su un singolo nodo può rappresentare un consumo aggregato considerevole di CPU e memoria in un cluster di grandi dimensioni. Tenga traccia sia dell'utilizzo per singolo pod sia delle risorse totali consumate da ciascun DaemonSet, per comprenderne l'impatto sulla capacità del cluster.

Riesamini i DaemonSet quando cambiano i tipi di nodo, i workloads o le dimensioni del cluster. Presti attenzione a richieste di risorse inutilizzate, throttling della CPU, pressione sulla memoria, eventi OOM, riavvii e pod che non riescono a essere schedulati. Il monitoraggio continuo aiuta a individuare quando le impostazioni delle risorse o le regole di scheduling non corrispondono più alle effettive condizioni operative.

Ottimizzare l'utilizzo delle risorse dei DaemonSet con PerfectScale

Poiché un DaemonSet colloca un pod su ogni nodo idoneo, anche piccole quantità di over- o under-provisioning si moltiplicano nell'intero cluster. PerfectScale by DoiT è una piattaforma di ottimizzazione per Kubernetes che si installa con un singolo comando Helm e offre insight concreti e ottimizzazione autonoma sull'intero stack K8s, in modo che gli agenti a livello di nodo come collettori di log, exporter di monitoraggio e daemon di sicurezza vengano eseguiti con le risorse di cui hanno effettivamente bisogno.

Funzionalità chiave di PerfectScale:

• Right-sizing autonomo dei workloads: Podfit offre una vista granulare dello stato e dei costi del cluster, dà priorità alle aree che richiedono attenzione e ottimizza autonomamente i workloads con raccomandazioni di right-sizing basate sui dati, applicabili automaticamente.
• Ottimizzazione dell'utilizzo dei nodi: Infrafit fornisce visibilità completa sull'utilizzo dei nodi e insight granulari che identificano ed eliminano la capacità inutilizzata, aiutando a scegliere i nodi giusti per i Suoi workloads.
• Allineamento con gli autoscaler: funziona in combinazione con HPA, KEDA, Karpenter, Cluster Autoscaler, EKS Auto Mode, Fargate, Node Auto Provisioning e Google Autopilot, con raccomandazioni concrete per migliorarne le configurazioni.
• Alerting in tempo reale con prioritizzazione: un'avanzata prioritizzazione automatica mette in evidenza i rischi di resilienza, i picchi di costo e le anomalie più rilevanti prima che impattino gli utenti o la fattura cloud, con avvisi recapitati su Slack, Datadog, MS Teams o PagerDuty.
• Reportistica su trend e governance: il report Trends offre una visibilità approfondita su metriche di costo, spreco e rischio nel tempo, su cluster, gruppi di nodi, namespace e workloads, a supporto di previsioni e root cause analysis.
• Ampio supporto degli ambienti: funziona su cluster on-premise e cloud, tra cui OpenShift, EKS, GKE e AKS, e supporta container basati su Windows oltre a workloads effimeri e di ML.

Scopra di più sulla piattaforma PerfectScale