Formation DevOps | Formation kubernetes​ : DaemonSet

www.itgalaxy.io

DaemonSet

Un DaemonSet garantit que tous (ou certains) nœuds exécutent une copie d’un pod. Au fur et à mesure que des nœuds sont ajoutés au cluster, des pods leur sont ajoutés. À mesure que les nœuds sont supprimés du cluster, ces pods sont récupérés. La suppression d’un DaemonSet nettoiera les pods qu’il a créés.

Certaines utilisations typiques d’un DaemonSet sont :

• exécuter un démon de stockage de cluster sur chaque nœud
• exécuter un démon de collecte de journaux sur chaque nœud
• exécuter un démon de surveillance de nœud sur chaque nœud

Dans un cas simple, un DaemonSet, couvrant tous les nœuds, serait utilisé pour chaque type de démon. Une configuration plus complexe peut utiliser plusieurs DaemonSets pour un seul type de démon, mais avec des indicateurs différents et/ou des demandes de mémoire et de processeur différentes pour différents types de matériel.
Écrire une spécification

Créer un DaemonSet

Vous pouvez décrire un DaemonSet dans un fichier YAML. Par exemple, le daemonset.yamlfichier ci-dessous décrit un DaemonSet qui exécute l’image Docker fluentd-elasticsearch
On utilise souvent ce use case pour la récupération des logs avec fluentd et les stockées dans une base de donnée elasticsearch , et ensuite les éxposé avec kibana , je vous ai préparer un tutoriel complet pour le deployement de la stack ELK sur kubernetes .

Créez un DaemonSet basé sur le fichier YAML :

kubectl apply -f daemonset.yaml

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      # these tolerations are to have the daemonset runnable on control plane nodes
      # remove them if your control plane nodes should not run pods
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      # it may be desirable to set a high priority class to ensure that a DaemonSet Pod
      # preempts running Pods
      # priorityClassName: important
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

Comment les pods démons sont programmés

Un DaemonSet peut être utilisé pour garantir que tous les nœuds éligibles exécutent une copie d’un pod. Le contrôleur DaemonSet crée un pod pour chaque nœud éligible et ajoute le spec.affinity.nodeAffinitychamp du pod pour correspondre à l’hôte cible.

Une fois le pod créé, le scheduleur par défaut prend généralement le relais, puis lie le pod à l’hôte cible en définissant le .spec.nodeNamechamp. Si le nouveau pod ne peut pas tenir sur le nœud, le sheduleur par défaut peut préempter (expulser) certains des pods existants en fonction de la priorité du nouveau pod.

L’affinité de nœud d’origine spécifiée dans le .spec.template.spec.affinity.nodeAffinitychamp (si spécifiée) est prise en compte par le contrôleur DaemonSet lors de l’évaluation des nœuds éligibles.

nodeAffinity:
  requiredDuringSchedulingIgnoredDuringExecution:
    nodeSelectorTerms:
    - matchFields:
      - key: metadata.name
        operator: In
        values:
        - target-host-name




1. Nous contactez

2. Infra as a Service

  • Description: Infrastructure cloud évolutive et sécurisée
  • Links:

3. Projets Développeurs

4. Développeurs

5. Formations Complètes

6. Marketplace

7. Blogs

This website is powered by ItGalaxy.io