Com o kubernetes nós podemos criar um deploy que vai rodar em todos os nodes do cluster, esse tipo de deploy é conhecido como DaemonSet.
O melhor exemplo que me vem a cabeça é algo que aplique uma configuração no kernel da maquina, como por exemplo utilizando o sysctl.
Quando rodamos o Elasticsearch no Kubernetes, algumas vezes podemos nós deparar com essa mensagem de erro:
max virtual memory areas vm.max_map_count [65530] likely too low,
increase to at least [262144]
Para resolver esse problema o comando abaixo já resolveria:
sysctl -w vm.max_map_count=262144
Mas teriamos que aplicar esse comando em todos os workers que potencialmente poderiam rodar o pod do elasticsearch. Só que felizmente nós temos o DaemonSet para nós ajudar, para aplicar em todos os nós ao mesmo tempo e garantir que em caso de um reboot o comando sejá aplicado novamente só precisamos criar DaemonSet:
apiVersion: v1
kind: Namespace
metadata:
name: elastic-daemonset
---
apiVersion: apps/v1beta2
kind: DaemonSet
metadata:
labels:
namespace: elastic-daemonset
name: elastic-tunning-daemonset
name: elastic-tunning-daemonset
spec:
selector:
matchLabels:
name: elastic-tunning-daemonset
template:
metadata:
labels:
name: elastic-tunning-daemonset
spec:
containers:
- env:
- name: STARTUP_SCRIPT
value: |
#! /bin/bash
sysctl -w vm.max_map_count=262144
echo "done"
image: gcr.io/google-containers/startup-script:v1
imagePullPolicy: IfNotPresent
name: elastic-tunning-daemonset
resources: {}
securityContext:
privileged: true
procMount: Default
hostPID: true
restartPolicy: Always
securityContext: {}
updateStrategy:
type: OnDelete
Para esse exemplo, vou usar um cluster 9 nodes que foi provisionado na DigitalOcean com apenas um clique.
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
heuristic-almeida-8dyb Ready <none> 3m9s v1.13.2
heuristic-almeida-8dyf Ready <none> 2m54s v1.13.2
heuristic-almeida-8dyg Ready <none> 2m48s v1.13.2
heuristic-almeida-8dyj Ready <none> 2m28s v1.13.2
heuristic-almeida-8dyo Ready <none> 2m47s v1.13.2
heuristic-almeida-8dyr Ready <none> 2m52s v1.13.2
heuristic-almeida-8dyw Ready <none> 2m56s v1.13.2
heuristic-almeida-8dyx Ready <none> 2m42s v1.13.2
heuristic-almeida-8dyy Ready <none> 2m36s v1.13.2
O YAML acima vai criar uma namespace chamada elastic-daemonset e um DaemonSet chamado elastic-tunning-daemonset, esse DaemonSet precisa de algumas permissões especiais para poder modificar o Kernel do Worker, por isso ele roda como privileged
$ kubectl create -f daemonset-elastic.yaml
namespace/elastic-daemonset created
daemonset.apps/elastic-tunning-daemonset created
Agora para validar se o DaemonSet foi criado podemos rodar o comando:
$ kubectl get all
NAME READY STATUS RESTARTS AGE
pod/elastic-tunning-daemonset-5t6j5 1/1 Running 0 65s
pod/elastic-tunning-daemonset-7x86j 1/1 Running 0 65s
pod/elastic-tunning-daemonset-drtmz 1/1 Running 0 65s
pod/elastic-tunning-daemonset-glspx 1/1 Running 0 65s
pod/elastic-tunning-daemonset-kn5wg 1/1 Running 0 65s
pod/elastic-tunning-daemonset-mx5bb 1/1 Running 0 65s
pod/elastic-tunning-daemonset-nqrnw 1/1 Running 0 65s
pod/elastic-tunning-daemonset-ph6bp 1/1 Running 0 65s
pod/elastic-tunning-daemonset-t8v4g 1/1 Running 0 65s
Com isso nós garantimos que todos os nodes estão executando o codigo, caso alguem node caia e volte, automaticamente o container será schedulado novamente e o tunning será aplicado.
Esse laboratorio foi criado utilizando o Kubernetes da DigitalOcean, o cluster foi provisionado em minutos, passei a utilizar ele no lugar do minikube para fazer testes, já que até Block Storage via CSI eles oferecem.