Notes d'étude du cours Open Technology Cloud Native: Orchestration et gestion des applications: Job and DaemonSet, gestion de la configuration des applications

5. Orchestration et gestion des applications: Job et DaemonSet

1 、 emploi

1), la source de la demande

Insérez la description de l'image ici

2), interprétation de cas d'utilisation

1) Syntaxe du travail

Insérez la description de l'image ici

L'image ci-dessus est le format yaml le plus simple de Job. Ici, un nouveau type appelé Job est principalement introduit. Ce Job est en fait un type de contrôleur de job. Ensuite, le nom dans les métadonnées spécifie le nom du travail, le modèle de spécification ci-dessous est en fait la spécification du pod

Le contenu ici est le même, la seule chose est deux autres points:

La première est restartPolicy. Trois stratégies de relance : Jamais, OnFailure et Toujours peuvent être définies dans Job . Vous pouvez utiliser Never lorsque vous souhaitez que le travail s'exécute à nouveau; vous pouvez utiliser OnFailure lorsque vous souhaitez l'exécuter à nouveau en cas d'échec, et vous pouvez utiliser OnFailure lorsque vous réessayez; ou vous pouvez utiliser Always lorsque vous réexécutez sous n'importe quel conditions.
De plus, il est impossible pour Job de réessayer indéfiniment lorsqu'il est en cours d'exécution, un paramètre est donc nécessaire pour contrôler le nombre de tentatives. Cette limite de backoffLimit permet de garantir combien de fois un travail peut être retenté

Ainsi, dans Job, l'objectif principal est la stratégie de redémarrage restartPolicy et la limite de relance de backoffLimit

2) Statut du travail

Insérez la description de l'image ici

Une fois le travail créé, vous pouvez utiliser kubectl get jobscette commande pour afficher l'état d'exécution du travail en cours. Dans la valeur obtenue, il y a essentiellement le nom du travail, combien de pods sont actuellement terminés et combien de temps cela prend

La signification de AGE signifie que ce pod est calculé à partir de l'heure actuelle, moins l'heure à laquelle il a été créé à ce moment-là. Cette durée est principalement utilisée pour vous raconter l'histoire du Pod et combien de temps il s'est écoulé depuis la création du Pod.
DURATION regarde principalement depuis combien de temps l'activité réelle de la tâche a été exécutée. Ce paramètre sera très utile lors de l'optimisation des performances.
COMPLETIONS examine principalement le nombre de pods de la tâche et le nombre d'états qu'elle a terminés qui seront affichés dans ce champ.

3) Afficher le pod

Insérez la description de l'image ici

L'unité d'exécution finale du travail est toujours le Pod. Le Job qui vient d'être créé créera un pod appelé pi. Cette tâche consiste à calculer le pi. Le nom du pod sera${job-name}-${random-suffix}

Il a un pod plus qu'ordinaire appelé ownerReferences, qui déclare à quel contrôleur de niveau supérieur le pod appartient à gérer. Vous pouvez voir que les références ownerReferences ici appartiennent à batch / v1, qui est géré par le travail précédent. Voici une déclaration indiquant qui est son contrôleur, puis vous pouvez vérifier qui est son contrôleur via le pod back, et en même temps, vous pouvez vérifier quels pods il a sous le travail en fonction du travail.

4) Exécuter le travail en parallèle

Insérez la description de l'image ici

Parfois, il y a certaines exigences: j'espère que le travail peut être maximisé en parallèle lors de l'exécution, et n Pods sont générés en parallèle pour s'exécuter rapidement. Dans le même temps, en raison de notre nombre limité de nœuds, nous ne souhaitons peut-être pas avoir trop de pods en parallèle en même temps. Il existe un concept de pipeline. Nous pouvons espérer que le degré maximal de parallélisme est, et le Le contrôleur de travail peut le faire pour nous.

Voici principalement deux paramètres: l' un est les complémentions, l'autre le parallélisme

Tout d'abord, le premier paramètre est utilisé pour spécifier le nombre d'exécutions de cette file d'attente de pod, qui peut être considéré comme le nombre total d'exécutions spécifié par ce Job. Par exemple, il est mis à 8 ici, c'est-à-dire que cette tâche sera exécutée 8 fois au total
Le deuxième paramètre représente le nombre d'exécutions parallèles. Le soi-disant nombre d'exécutions parallèles correspond en fait à la taille de la file d'attente de la mémoire tampon dans un pipeline ou un tampon. Définissez-le sur 2, ce qui signifie que ce travail doit être exécuté 8 fois, avec 2 pods en parallèle à chaque fois. Dans ce cas, un total de 4 sera exécuté. Lots

5) Afficher le travail parallèle en cours d'exécution

Insérez la description de l'image ici

L'image ci-dessus est l'effet qui peut être vu une fois la tâche exécutée dans son ensemble. Commencez par voir le nom de la tâche, puis voyez qu'elle a créé un total de 8 modules, ce qui a pris 2 minutes et 23 secondes pour s'exécuter. C'est le moment de la création.

Examinons ensuite les vrais pods. Il y a 8 pods au total, et l'état de chaque pod est terminé. Ensuite, regardez son AGE, qui est l'heure. De bas en haut, on voit qu'il y a respectivement 73s, 40s, 110s et 2m26s. Chaque groupe a deux pods qui ont la même heure, c'est-à-dire que lorsque la période est de 40 secondes, le dernier est créé et 2m26s est le premier créé. En d'autres termes, toujours deux pods sont créés en même temps, mis en parallèle et disparus, puis créés, exécutés et terminés à nouveau

6) Syntaxe de CronJob

Insérez la description de l'image ici

Par rapport à Job, CronJob (tâche chronométrée) a plusieurs champs différents:

schedule : Ce champ de planning sert principalement à définir le format de l'heure, et son format d'heure est le même que celui de l'heure de Linux
** startingDeadlineSeconds: ** Chaque fois qu'un travail est exécuté, combien de temps il peut attendre, parfois le travail peut s'exécuter pendant une longue période sans démarrer. Donc à ce moment, si plus d'un temps, CronJob arrêtera le travail
concurrencyPolicy : cela signifie s'il faut autoriser le fonctionnement en parallèle. L'opération dite parallèle est, par exemple, je l'exécute toutes les minutes, mais cette tâche peut prendre beaucoup de temps à s'exécuter. Si elle prend deux minutes pour s'exécuter correctement, c'est-à-dire lorsque la deuxième tâche doit s'exécuter à temps, le travail précédent n'est toujours pas terminé. Si cette stratégie est définie sur true, elle s'exécutera toutes les minutes, que votre travail précédent soit terminé ou non; s'il est faux, il attendra que le travail précédent se termine avant d'exécuter le suivant.
** JobsHistoryLimit: ** Cela signifie qu'après chaque exécution de CronJob, il laissera l'historique d'exécution et l'heure d'affichage du travail précédent. Bien sûr, ce montant ne peut pas être illimité, vous devez donc définir le nombre de rétention historique, généralement vous pouvez définir la valeur par défaut 10 ou 100.

3) Démonstration de fonctionnement

1) Création de travaux et vérification des opérations

job.yaml：

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl","-Mbignum=bpi","-wle","print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

hanxiantaodeMBP:yamls hanxiantao$ kubectl create -f job.yaml 
job.batch/pi created
hanxiantaodeMBP:yamls hanxiantao$ kubectl get jobs
NAME   COMPLETIONS   DURATION   AGE
pi     1/1           2m1s       2m26s
hanxiantaodeMBP:yamls hanxiantao$ kubectl get pods 
NAME       READY   STATUS      RESTARTS   AGE
pi-hltwn   0/1     Completed   0          2m34s
hanxiantaodeMBP:yamls hanxiantao$ kubectl logs pi-hltwn
3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901

2) Création de jobs parallèles et vérification des opérations

job1.yaml：

apiVersion: batch/v1
kind: Job
metadata:
  name: paral-1
spec:
  completions: 8
  parallelism: 2
  template:
    spec:
      containers:
      - name: param
        image: ubuntu
        command: ["/bin/bash"]
        args: ["-c","sleep 30;date"]
      restartPolicy: OnFailure

hanxiantaodeMBP:yamls hanxiantao$ kubectl create -f job1.yaml 
job.batch/paral-1 created
hanxiantaodeMBP:yamls hanxiantao$ kubectl get jobs
NAME      COMPLETIONS   DURATION   AGE
paral-1   0/8           10s        10s
hanxiantaodeMBP:yamls hanxiantao$ kubectl get pods
NAME            READY   STATUS    RESTARTS   AGE
paral-1-9gs52   1/1     Running   0          22s
paral-1-vjc5v   1/1     Running   0          22s
hanxiantaodeMBP:yamls hanxiantao$ kubectl get pods
NAME            READY   STATUS      RESTARTS   AGE
paral-1-7t6qf   0/1     Completed   0          102s
paral-1-9gs52   0/1     Completed   0          2m31s
paral-1-fps7x   0/1     Completed   0          107s
paral-1-hflsd   0/1     Completed   0          39s
paral-1-qfnk9   0/1     Completed   0          37s
paral-1-t5dqw   0/1     Completed   0          70s
paral-1-vjc5v   0/1     Completed   0          2m31s
paral-1-vqh7d   0/1     Completed   0          73s

3) Création de Cronjob et vérification du fonctionnement

cron.yaml：

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
       spec:
        containers:
        - name: hello
          image: busybox
          args: 
          - /bin/sh
          - -c
          - date;echo Hello from ther Kubernetes Cluster
        restartPolicy: OnFailure
  startingDeadlineSeconds: 10
  concurrencyPolicy: Allow
  successfulJobsHistoryLimit: 3

hanxiantaodeMBP:yamls hanxiantao$ kubectl create -f cron.yaml 
cronjob.batch/hello created
hanxiantaodeMBP:yamls hanxiantao$ kubectl get jobs
No resources found in default namespace.
hanxiantaodeMBP:yamls hanxiantao$ kubectl get jobs
NAME               COMPLETIONS   DURATION   AGE
hello-1609464960   1/1           4s         5s
hanxiantaodeMBP:yamls hanxiantao$ kubectl get jobs
NAME               COMPLETIONS   DURATION   AGE
hello-1609464960   1/1           4s         66s
hello-1609465020   1/1           3s         6s

Étant donné que ce CronJob est exécuté toutes les minutes, vous kubectl get jobsne pourrez peut-être pas voir les informations sur le travail au début, vous devez donc attendre un peu

4), conception d'architecture

Insérez la description de l'image ici

En fait, le Job Controller est toujours principalement chargé de créer le pod correspondant, puis le Job Controller suivra l'état du Job, réessayera ou continuera à créer en fonction de certaines des configurations soumises par nous en temps opportun. Chaque pod aura son étiquette correspondante, pour suivre le Job Controller auquel il appartient, et aussi pour configurer la création parallèle, parallèle ou série pour créer des pods

Insérez la description de l'image ici

La figure ci-dessus est le flux principal d'un contrôleur de tâche. Tous les jobs sont un contrôleur. Il surveillera le serveur API. Chaque fois qu'un job est soumis, le yaml sera transmis à etcd via le serveur api, puis le Job Controller enregistrera plusieurs gestionnaires, chaque fois qu'il y aura des ajouts, des mises à jour, ou suppressions. En attente de l'opération, il sera envoyé au contrôleur via une file d'attente de messages au niveau de la mémoire

Vérifiez si un pod est actuellement en cours d'exécution via Job Controller. Sinon, créez le pod via Scale up; s'il y en a un ou s'il est supérieur à ce nombre, réduisez-le. Si le pod change à ce moment, vous devez mettre à jour son statut dans le temps

Dans le même temps, vérifiez s'il s'agit d'un travail parallèle ou d'un travail série, et créez le nombre de pods en temps opportun en fonction du parallélisme configuré et du degré de sérialisation. Enfin, il mettra à jour le statut complet du travail sur le serveur API, afin que nous puissions voir l'effet final présenté

2 、 DaemonSet

1), la source de la demande

Insérez la description de l'image ici

2), interprétation de cas d'utilisation

1) Syntaxe de DaemonSet

Insérez la description de l'image ici

Le premier est gentil: DaemonSet. La syntaxe de DaemonSet a la même partie que Deployment. Par exemple, il aura matchLabel, via matchLabel pour gérer le pod correspondant, ce pod.label doit également correspondre à ce DaemonSet.controller.label, il peut le trouver selon label.selector Le pod de gestion correspondant. Tout dans le conteneur de spécifications ci-dessous est cohérent

Ici, nous utilisons fluentd comme exemple. Les points les plus couramment utilisés de DaemonSet sont les suivants:

Le premier est le stockage. Des choses comme GlusterFS ou Ceph doivent exécuter quelque chose de similaire à un agent sur chaque nœud. DaemonSet peut bien répondre à cette demande.
En outre, pour la collecte de journaux, comme logstash ou fluentd, ce sont les mêmes exigences. Chaque nœud doit exécuter un agent. De cette manière, son état peut être facilement collecté et les informations de chaque nœud peuvent être rapportées à temps. Au dessus
Un autre est que chaque nœud a besoin d'exécuter des tâches de surveillance, et chaque nœud doit exécuter les mêmes choses, telles que Promethues, qui a également besoin du support de DaemonSet.

2) Afficher l'état de DaemonSet

Insérez la description de l'image ici

Après avoir créé le DaemonSet, vous pouvez l'utiliser kubectl get DaemonSet(DaemonSet est abrégé en ds). On peut voir que la valeur de retour de DaemonSet est très similaire au déploiement, c'est-à-dire qu'il en a actuellement quelques-uns en cours d'exécution, puis nous en avons besoin, et quelques-uns sont PRÊTS. Bien sûr, READY n'a que des pods, donc tout ce qu'il crée à la fin sont des pods.

Il y a plusieurs paramètres ici, à savoir: le nombre de pods nécessaires, le nombre de pods qui ont été créés, le nombre de pods prêts et tous les pods disponibles qui ont réussi la vérification de l'état; et NODE SELECTOR. NODE SELECTOR est l'étiquette de sélection des nœuds. Parfois, nous souhaitons que seuls certains nœuds exécutent ce pod au lieu de tous les nœuds, donc si certains nœuds sont marqués, DaemonSet ne s'exécutera que sur ces nœuds

3) Mettre à jour DaemonSet

Insérez la description de l'image ici

En fait, DaemonSet et le déploiement sont très similaires. Il a également deux stratégies de mise à jour: l'une est RollingUpdate et l'autre est OnDelete

RollingUpdate se mettra à jour un par un. Mettez d'abord à jour le premier pod, puis l'ancien pod est supprimé, puis créez le deuxième pod après avoir passé la vérification de l'état, afin que l'entreprise se mette à niveau en douceur sans interruption.
OnDelete est en fait une très bonne stratégie de mise à jour, c'est-à-dire qu'après la mise à jour du modèle, il n'y aura aucun changement dans le pod et nous devons le contrôler manuellement. Si nous supprimons le pod correspondant à un certain nœud, il sera reconstruit. S'il n'est pas supprimé, il ne sera pas reconstruit. De cette façon, il aura également un effet particulièrement bon sur certains besoins particuliers que nous devons contrôler manuellement .

3) Démonstration de fonctionnement

1) Disposition de DaemonSet

daemonSet.yaml：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
     containers:
     - name: fluentd-elasticsearch
       image: fluent/fluentd:v1.4-1

hanxiantaodeMBP:yamls hanxiantao$ kubectl create -f daemonSet.yaml 
daemonset.apps/fluentd-elasticsearch created
hanxiantaodeMBP:yamls hanxiantao$ kubectl get ds
NAME                    DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
fluentd-elasticsearch   1         1         1       1            1           <none>          35s
hanxiantaodeMBP:yamls hanxiantao$ kubectl get pods
NAME                          READY   STATUS    RESTARTS   AGE
fluentd-elasticsearch-h9jb9   1/1     Running   0          2m17s

2) Mise à jour de DaemonSet

hanxiantaodeMBP:yamls hanxiantao$ kubectl set image ds/fluentd-elasticsearch fluentd-elasticsearch=fluent/fluentd:v1.4
daemonset.apps/fluentd-elasticsearch image updated
hanxiantaodeMBP:yamls hanxiantao$ kubectl rollout status ds/fluentd-elasticsearch
daemon set "fluentd-elasticsearch" successfully rolled out

4), conception d'architecture

Insérez la description de l'image ici

DaemonSet est également un contrôleur, et sa dernière véritable unité commerciale est également un pod. DaemonSet est en fait très similaire à un contrôleur de tâche. Il utilise également le contrôleur pour surveiller l'état du serveur API, puis ajoute des pods dans le temps. La seule différence est qu'il surveille l'état du nœud. Lorsqu'un nœud vient d'être ajouté ou disparaît, il crée un pod correspondant sur le nœud, puis sélectionne le nœud correspondant en fonction de l'étiquette que vous avez configurée.

Le contrôleur de DaemonSet, DaemonSet fait en fait la même chose que le contrôleur de tâche: les deux doivent être basés sur l'état de la surveillance du serveur API. Désormais, la seule différence entre DaemonSet et Job controller est que DaemonsetSet Controller doit surveiller l'état du nœud, mais en fait, l'état de ce nœud est toujours transmis à etcd via le serveur API.

Lorsqu'un état de nœud change, il sera envoyé via une file d'attente de messages en mémoire, puis le contrôleur DaemonSet surveillera cet état pour voir s'il existe un pod correspondant sur chaque nœud, et sinon, le créera. Bien sûr, il fera une comparaison, s'il y en a, il comparera les versions, puis ajoutera ce qui est mentionné ci-dessus s'il faut faire RollingUpdate? Sinon, il sera recréé. Lorsque Ondelete supprime le pod, il le vérifiera également pour vérifier s'il faut mettre à jour ou créer le pod correspondant.

Bien sûr, à la fin, si toutes les mises à jour sont terminées, il mettra à jour le statut de l'ensemble du DaemonSet sur le serveur API et terminera la mise à jour finale.