Notas de estudio del curso abierto de tecnología nativa en la nube: Orquestación y gestión de aplicaciones: Job and DaemonSet, Gestión de configuración de aplicaciones

5. Orquestación y gestión de aplicaciones: Job y DaemonSet

1 、 Trabajo

1), la fuente de demanda

Inserte la descripción de la imagen aquí

2), interpretación de casos de uso

1) Sintaxis del trabajo

Inserte la descripción de la imagen aquí

La imagen de arriba es el formato yaml más simple de Job. Aquí, se presenta principalmente un nuevo tipo llamado Job. Este Job es en realidad un tipo de controlador de trabajo. Luego, el nombre en los metadatos especifica el nombre del trabajo, la especificación de la plantilla a continuación es en realidad la especificación del pod.

El contenido aquí es el mismo, lo único son dos puntos más:

La primera es restartPolicy. Se pueden configurar tres políticas de reintento: Never, OnFailure y Always en Job . Puede utilizar Never cuando desee que el trabajo se vuelva a ejecutar; puede utilizar OnFailure cuando desee ejecutarlo de nuevo cuando falle, y puede utilizar OnFailure cuando vuelva a intentarlo; o puede utilizar Always cuando vuelva a ejecutarlo en cualquier circunstancias.
Además, es imposible que Job reintente infinitamente cuando se está ejecutando, por lo que se necesita un parámetro para controlar el número de reintentos. Este backoffLimit es para asegurar cuántas veces se puede reintentar un trabajo

Entonces, en Trabajo, el enfoque principal es la estrategia de reinicio de la política de reinicio y el límite de reintentos de backoffLimit

2) Estado del trabajo

Inserte la descripción de la imagen aquí

Una vez creado el trabajo, puede utilizar kubectl get jobseste comando para ver el estado de ejecución del trabajo actual. En el valor obtenido, se encuentran básicamente el nombre del trabajo, cuántos pods se completan actualmente y cuánto tiempo lleva

El significado de AGE significa que este Pod se calcula a partir de la hora actual, menos la hora en que se creó en ese momento. Esta duración se usa principalmente para contarle el historial del Pod y cuánto tiempo ha pasado desde que se creó.
DURATION analiza principalmente cuánto tiempo ha estado funcionando el negocio real en el trabajo. Este parámetro será muy útil al ajustar el rendimiento.
FINALIZACIONES analiza principalmente cuántos pods en la tarea y cuántos estados ha completado se mostrarán en este campo

3) Ver Pod

Inserte la descripción de la imagen aquí

La unidad de ejecución final del trabajo sigue siendo el Pod. El trabajo que se acaba de crear creará un pod llamado pi. Esta tarea es para calcular el pi. El nombre del pod será${job-name}-${random-suffix}

Tiene un Pod más que el ordinario llamado ownerReferences, que declara a qué controlador de nivel superior pertenece el pod para administrar. Puede ver que las ownerReferences aquí pertenecen a batch / v1, que es administrado por el trabajo anterior. Aquí hay una declaración de quién es su controlador, y luego puede verificar quién es su controlador a través del pod back y, al mismo tiempo, puede verificar qué pods tiene debajo del trabajo de acuerdo con el trabajo.

4) Ejecutar trabajo en paralelo

Inserte la descripción de la imagen aquí

A veces hay algunos requisitos: espero que el trabajo se pueda maximizar en paralelo cuando se ejecuta, y que n Pods se generen en paralelo para ejecutarse rápidamente. Al mismo tiempo, debido a nuestro número limitado de nodos, es posible que no queramos tener demasiados pods en paralelo al mismo tiempo. Existe el concepto de canalización. Podemos esperar que el grado máximo de paralelismo sea, y el El controlador de trabajo puede hacerlo por nosotros.

Aquí hay principalmente dos parámetros: uno es complementos, el otro es paralelismo

En primer lugar, el primer parámetro se usa para especificar el número de ejecuciones de esta cola de Pod, que se puede considerar como el número total de ejecuciones especificadas por este trabajo. Por ejemplo, aquí se establece en 8, es decir, esta tarea se ejecutará 8 veces en total
El segundo parámetro representa el número de ejecuciones paralelas. El llamado número de ejecuciones paralelas es en realidad el tamaño de la cola del búfer en una canalización o búfer. Configúrelo en 2, lo que significa que este trabajo debe ejecutarse 8 veces, con 2 pods en paralelo cada vez. En este caso, se ejecutarán un total de 4. Lotes

5) Ver el trabajo paralelo en ejecución

Inserte la descripción de la imagen aquí

La imagen de arriba es el efecto que se puede ver después de que el trabajo se ejecuta en su totalidad. Primero, vea el nombre del trabajo y luego vea que ha creado un total de 8 pods, que tardaron 2 minutos y 23 segundos en ejecutarse. Este es el momento de la creación.

A continuación, veamos los grupos reales. Hay 8 grupos en total y el estado de cada grupo está completo. Luego, mire su AGE, que es la hora. De abajo hacia arriba, podemos ver que hay 73s, 40s, 110s y 2m26s respectivamente. Cada grupo tiene dos pods que tienen el mismo tiempo, es decir, cuando el período de tiempo es de 40 s, se crea el último y 2m26s es el primero que se crea. En otras palabras, siempre se crean dos pods al mismo tiempo, se ponen en paralelo y desaparecen, luego se crean, se ejecutan y se terminan nuevamente.

6) Sintaxis de CronJob

Inserte la descripción de la imagen aquí

En comparación con Job, CronJob (tarea cronometrada) tiene varios campos diferentes:

horario : este campo de horario es principalmente para establecer el formato de hora, y su formato de hora es el mismo que crontime de Linux
** beginDeadlineSeconds: ** Cada vez que se ejecuta un trabajo, cuánto tiempo puede esperar, a veces el trabajo puede ejecutarse durante mucho tiempo sin comenzar. Entonces, en este momento, si es más de mucho tiempo, CronJob detendrá el trabajo
concurrencyPolicy : Significa si se permite el funcionamiento en paralelo. La llamada operación en paralelo es, por ejemplo, la ejecuto cada minuto, pero este trabajo puede tardar mucho en ejecutarse. Si tarda dos minutos en ejecutarse correctamente, es decir, cuando el segundo trabajo debe ejecutarse a tiempo, el trabajo anterior aún no se ha completado. Si esta política se establece en verdadera, se ejecutará cada minuto independientemente de si su trabajo anterior se completó o no; si es falsa, esperará a que se complete el trabajo anterior antes de ejecutar el siguiente.
** JobsHistoryLimit: ** Esto significa que después de que se ejecute cada CronJob, dejará el historial de ejecución y verá la hora del trabajo anterior. Por supuesto, esta cantidad no puede ser ilimitada, por lo que debe establecer el número de retención histórica, generalmente puede establecer el valor predeterminado de 10 o 100.

3) demostración de funcionamiento

1) Creación de empleo y verificación de funcionamiento

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) Creación de trabajos paralelos y verificación de operaciones

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) Creación y verificación de funcionamiento de Cronjob

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

Dado que este CronJob se ejecuta cada minuto, es kubectl get jobsposible que no pueda ver la información del trabajo al principio, por lo que debe esperar un poco.

4), diseño de arquitectura

Inserte la descripción de la imagen aquí

De hecho, el controlador de trabajos sigue siendo principalmente para crear el pod correspondiente, y luego el controlador de trabajos rastreará el estado del trabajo, volverá a intentarlo o continuará creando de acuerdo con algunas de las configuraciones enviadas por nosotros de manera oportuna. Cada pod tendrá su etiqueta correspondiente, para rastrear el Job Controller al que pertenece, y también para configurar la creación en paralelo, paralelo o en serie para crear pods

Inserte la descripción de la imagen aquí

La figura anterior es el flujo principal de un controlador de trabajos. Todos los trabajos son un controlador. Observará el servidor API. Cada vez que se envía un trabajo, el yaml se pasará a etcd a través del servidor api, y luego el controlador de trabajos registrará varios controladores, siempre que haya adiciones, actualizaciones, o eliminaciones. Cuando se espera la operación, se enviará al controlador a través de una cola de mensajes a nivel de memoria

Compruebe si hay un pod en ejecución a través del controlador de trabajos. De lo contrario, cree el pod a través de Escalar hacia arriba; si lo hay, o si es mayor que este número, escale hacia abajo. Si el pod cambia en este momento, necesita para actualizar su estado a tiempo

Al mismo tiempo, verifique si es un trabajo paralelo o un trabajo en serie, y cree el número de pods de manera oportuna de acuerdo con el paralelismo configurado y el grado de serialización. Finalmente, actualizará todo el estado del trabajo al servidor API, para que podamos ver el efecto final presentado.

2 、 DaemonSet

1), la fuente de demanda

Inserte la descripción de la imagen aquí

2), interpretación de casos de uso

1) Sintaxis de DaemonSet

Inserte la descripción de la imagen aquí

El primero es amable: DaemonSet. La sintaxis de DaemonSet tiene la misma parte que Deployment. Por ejemplo, tendrá matchLabel, a través de matchLabel para administrar el pod correspondiente, este pod.label también debe coincidir con este DaemonSet.controller.label, puede encontrarlo según label.selector El módulo de gestión correspondiente. Todo en el contenedor de especificaciones a continuación es consistente

Aquí usamos fluentd como ejemplo. Los puntos más utilizados de DaemonSet son los siguientes:

El primero es el almacenamiento. Cosas como GlusterFS o Ceph necesitan ejecutar algo similar a un agente en cada nodo. DaemonSet puede satisfacer bien esta demanda.
Además, para la recopilación de registros, como logstash o fluentd, estos son los mismos requisitos. Cada nodo debe ejecutar un Agente. De esta manera, su estado se puede recopilar fácilmente y la información de cada nodo se puede informar a tiempo. Encima
Otra es que cada nodo necesita ejecutar algunas cosas de monitoreo, y cada nodo necesita ejecutar las mismas cosas, como Promethues, que también necesita el soporte de DaemonSet.

2) Ver el estado de DaemonSet

Inserte la descripción de la imagen aquí

Después de crear el DaemonSet, puede usarlo kubectl get DaemonSet(DaemonSet se abrevia como ds). Se puede ver que el valor de retorno de DaemonSet es muy similar a la implementación, es decir, actualmente tiene algunos en ejecución, y luego necesitamos algunos, y algunos están LISTOS. Por supuesto, READY solo tiene pods, por lo que todo lo que crea al final son pods.

Aquí hay varios parámetros, a saber: el número de pods necesarios, el número de pods que se han creado, el número de listas y todos los pods disponibles que han pasado la verificación de estado; y NODE SELECTOR. NODE SELECTOR es la etiqueta de selección de nodo. A veces, es posible que deseemos que solo algunos nodos ejecuten este pod en lugar de todos los nodos, por lo que si algunos nodos están marcados, DaemonSet solo se ejecutará en estos nodos

3) Actualizar DaemonSet

Inserte la descripción de la imagen aquí

De hecho, DaemonSet y la implementación son muy similares. También tiene dos estrategias de actualización: una es RollingUpdate y la otra es OnDelete

RollingUpdate se actualizará uno por uno. Primero actualice el primer módulo, luego se elimina el módulo anterior y luego cree el segundo módulo después de pasar la verificación de estado, para que la empresa se actualice sin problemas y sin interrupciones.
OnDelete es en realidad una muy buena estrategia de actualización, es decir, después de que se actualice la plantilla, no habrá cambios en el pod y debemos controlarlo manualmente. Si eliminamos el pod correspondiente a un determinado nodo, se reconstruirá. Si no se elimina, no se reconstruirá. De esta manera, también tendrá un efecto particularmente bueno en algunas necesidades especiales que debemos controlar manualmente. .

3) demostración de funcionamiento

1) Disposición 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) Actualización 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), diseño de arquitectura

Inserte la descripción de la imagen aquí

DaemonSet también es un controlador, y su unidad de negocio real final también es un Pod. DaemonSet es en realidad muy similar a un controlador de trabajo. También usa el controlador para observar el estado del servidor API y luego agrega pods a tiempo. La única diferencia es que monitorea el estado del nodo. Cuando un nodo se agrega o desaparece, creará un pod correspondiente en el nodo y luego seleccionará el nodo correspondiente de acuerdo con la etiqueta que configuró.

El controlador de DaemonSet, DaemonSet, en realidad hace lo mismo que el controlador de trabajo: ambos deben basarse en el estado de la vigilancia del servidor API. Ahora, la única diferencia entre DaemonSet y Job controller es que DaemonsetSet Controller necesita observar el estado del nodo, pero de hecho el estado de este nodo todavía se pasa a etcd a través del servidor API.

Cuando el estado de un nodo cambia, se enviará a través de una cola de mensajes de memoria, y luego el controlador DaemonSet observará este estado para ver si hay un Pod correspondiente en cada nodo y, de no ser así, crearlo. Por supuesto, hará una comparación, si hay alguna, comparará las versiones y luego agregará lo mencionado anteriormente si desea hacer RollingUpdate. De lo contrario, se volverá a crear. Cuando Ondelete elimine el pod, también lo comprobará para comprobar si se debe actualizar o crear el pod correspondiente.

Por supuesto, al final, si se completan todas las actualizaciones, actualizará el estado de todo el DaemonSet al servidor API y completará la actualización final.