Da quanto abbiamo imparato sinora su Kubernetes, in questa piattaforma, svettano due caratteristiche principali:
- è naturalmente predisposto per lavorare su cluster Raspberry
- è in grado di gestire il ciclo di vita dei Pod
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 Docker
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
-o wide
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
kubectl delete -f daemonset.yaml