Chapitre 4. Utilisation des Jobs et des DaemonSets
4.1. Exécution automatique des tâches d'arrière-plan sur les nœuds à l'aide d'ensembles de démons
En tant qu'administrateur, vous pouvez créer et utiliser des ensembles de démons pour exécuter des répliques d'un pod sur des nœuds spécifiques ou sur tous les nœuds d'un cluster OpenShift Container Platform.
Un ensemble de démons garantit que tous les nœuds (ou certains d'entre eux) exécutent une copie d'un module. Au fur et à mesure que des nœuds sont ajoutés au cluster, des pods sont ajoutés au cluster. Lorsque des nœuds sont supprimés du cluster, ces pods sont supprimés par le biais du garbage collection. La suppression d'un ensemble de démons nettoie les modules qu'il a créés.
Vous pouvez utiliser des ensembles de démons pour créer un stockage partagé, exécuter un pod de journalisation sur chaque nœud de votre cluster ou déployer un agent de surveillance sur chaque nœud.
Pour des raisons de sécurité, les administrateurs de clusters et les administrateurs de projets peuvent créer des jeux de démons.
Pour plus d'informations sur les ensembles de démons, voir la documentation Kubernetes.
La planification du jeu de démons est incompatible avec le sélecteur de nœuds par défaut du projet. Si vous ne le désactivez pas, l'ensemble de démons est restreint par la fusion avec le sélecteur de nœuds par défaut. Il en résulte des recréations fréquentes de pods sur les nœuds qui n'ont pas été sélectionnés par le sélecteur de nœuds fusionné, ce qui entraîne une charge indésirable sur le cluster.
4.1.1. Planifié par le planificateur par défaut
Un ensemble de démons garantit que tous les nœuds éligibles exécutent une copie d'un pod. Normalement, le nœud sur lequel un pod s'exécute est sélectionné par le planificateur Kubernetes. Cependant, auparavant, les pods daemon set sont créés et planifiés par le contrôleur daemon set. Cela pose les problèmes suivants :
-
Comportement incohérent des pods : Les pods normaux qui attendent d'être planifiés sont créés et se trouvent dans l'état Pending, mais les pods daemon set ne sont pas créés dans l'état
Pending. Cette situation est source de confusion pour l'utilisateur. - La préemption des pods est gérée par l'ordonnanceur par défaut. Lorsque la préemption est activée, le contrôleur de l'ensemble des démons prend des décisions d'ordonnancement sans tenir compte de la priorité et de la préemption des pods.
La fonctionnalité ScheduleDaemonSetPods, activée par défaut dans OpenShift Container Platform, vous permet de planifier des ensembles de démons en utilisant le planificateur par défaut au lieu du contrôleur d'ensembles de démons, en ajoutant le terme NodeAffinity aux pods d'ensembles de démons, au lieu du terme spec.nodeName. L'ordonnanceur par défaut est alors utilisé pour lier le pod à l'hôte cible. Si l'affinité de nœud du pod de l'ensemble de démons existe déjà, elle est remplacée. Le contrôleur de l'ensemble de démons n'effectue ces opérations que lors de la création ou de la modification des modules de l'ensemble de démons, et aucune modification n'est apportée à l'adresse spec.template de l'ensemble de démons.
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchFields:
- key: metadata.name
operator: In
values:
- target-host-name
En outre, une tolérance node.kubernetes.io/unschedulable:NoSchedule est ajoutée automatiquement aux pods de l'ensemble des démons. L'ordonnanceur par défaut ignore les nœuds non ordonnançables lors de l'ordonnancement des pods du jeu de démons.
4.1.2. Création de jeux de démons
Lors de la création d'ensembles de démons, le champ nodeSelector est utilisé pour indiquer les nœuds sur lesquels l'ensemble de démons doit déployer des répliques.
Conditions préalables
Avant de commencer à utiliser les ensembles de démons, désactivez le sélecteur de nœuds par défaut pour l'ensemble du projet dans votre espace de noms, en définissant l'annotation de l'espace de noms
openshift.io/node-selectorcomme une chaîne vide :$ oc patch namespace myproject -p \ '{"metadata": {"annotations": {"openshift.io/node-selector": ""}}}'AstuceVous pouvez également appliquer le YAML suivant pour désactiver le sélecteur de nœuds par défaut du projet pour un espace de noms :
apiVersion: v1 kind: Namespace metadata: name: <namespace> annotations: openshift.io/node-selector: ''Si vous créez un nouveau projet, écrasez le sélecteur de nœuds par défaut :
$ oc adm new-project <name> --node-selector=""
Procédure
Pour créer un ensemble de démons :
Définir le fichier yaml du daemon :
apiVersion: apps/v1 kind: DaemonSet metadata: name: hello-daemonset spec: selector: matchLabels: name: hello-daemonset 1 template: metadata: labels: name: hello-daemonset 2 spec: nodeSelector: 3 role: worker containers: - image: openshift/hello-openshift imagePullPolicy: Always name: registry ports: - containerPort: 80 protocol: TCP resources: {} terminationMessagePath: /dev/termination-log serviceAccount: default terminationGracePeriodSeconds: 10- 1
- Le sélecteur d'étiquettes qui détermine quels pods appartiennent à l'ensemble de démons.
- 2
- Le sélecteur d'étiquette du modèle de pod. Il doit correspondre au sélecteur d'étiquette ci-dessus.
- 3
- Le sélecteur de nœud qui détermine sur quels nœuds les répliques de pods doivent être déployées. Un label correspondant doit être présent sur le nœud.
Créer l'objet daemon set :
$ oc create -f daemonset.yaml
Vérifier que les pods ont été créés et que chaque nœud dispose d'une réplique de pod :
Trouver les pods du daemonset :
$ oc get pods
Exemple de sortie
hello-daemonset-cx6md 1/1 Running 0 2m hello-daemonset-e3md9 1/1 Running 0 2m
Affichez les modules pour vérifier qu'ils ont bien été placés sur le nœud :
$ oc describe pod/hello-daemonset-cx6md|grep Node
Exemple de sortie
Node: openshift-node01.hostname.com/10.14.20.134
$ oc describe pod/hello-daemonset-e3md9|grep Node
Exemple de sortie
Node: openshift-node02.hostname.com/10.14.20.137
- Si vous mettez à jour un modèle de pod de daemon set, les répliques de pod existantes ne sont pas affectées.
- Si vous supprimez un ensemble de démons et que vous en créez un nouveau avec un modèle différent mais le même sélecteur d'étiquettes, il reconnaît les réplicas de pods existants comme ayant des étiquettes correspondantes et ne les met donc pas à jour ou ne crée pas de nouveaux réplicas en dépit d'une incohérence dans le modèle de pod.
- Si vous modifiez les étiquettes des nœuds, l'ensemble de démons ajoute des modules aux nœuds qui correspondent aux nouvelles étiquettes et supprime les modules des nœuds qui ne correspondent pas aux nouvelles étiquettes.
Pour mettre à jour un ensemble de démons, il faut forcer la création de nouvelles répliques de pods en supprimant les anciennes répliques ou les nœuds.
