Notas de estudo do curso aberto da Cloud Native Technology: Orquestração e gerenciamento de aplicativos: Job e DaemonSet, gerenciamento de configuração de aplicativos

5. Orquestração e gerenciamento de aplicativos: Job e DaemonSet

1 、 Trabalho

1), a fonte de demanda

Insira a descrição da imagem aqui

2), interpretação de caso de uso

1) Sintaxe do trabalho

Insira a descrição da imagem aqui

A imagem acima é o formato yaml mais simples de Jó. Aqui, um novo tipo chamado Jó é principalmente apresentado. Este trabalho é na verdade um tipo de controlador de trabalho. Em seguida, o nome nos metadados especifica o nome do trabalho, o spec.template abaixo é na verdade a especificação do pod

O conteúdo aqui é o mesmo, a única coisa são mais dois pontos:

A primeira é restartPolicy. Três políticas de repetição: Never, OnFailure e Always podem ser definidas no Job . Você pode usar Never quando quiser que o trabalho seja executado novamente; você pode usar OnFailure quando quiser executá-lo novamente quando falhar, e você pode usar OnFailure quando tentar novamente; ou você pode usar Always quando você executar novamente em qualquer circunstâncias.
Além disso, é impossível para o Job repetir infinitamente quando está em execução, portanto, um parâmetro é necessário para controlar o número de tentativas. Este backoffLimit é para garantir quantas vezes um trabalho pode ser repetido

Portanto, no Job, o foco principal é a estratégia de reinicialização restartPolicy e o limite de repetição backoffLimit

2) Status do trabalho

Insira a descrição da imagem aqui

Após a criação do trabalho, você pode usar kubectl get jobseste comando para visualizar o status de execução do trabalho atual. No valor obtido constam basicamente o nome da tarefa, quantos pods estão concluídos atualmente e quanto tempo leva

O significado de AGE significa que este pod é calculado a partir da hora atual, menos a hora em que foi criado naquele momento. Essa duração é usada principalmente para contar a história do pod e há quanto tempo ele foi criado.
DURATION analisa principalmente há quanto tempo o negócio real no trabalho está em execução. Este parâmetro será muito útil ao ajustar o desempenho.
COMPLETIONS analisa principalmente quantos pods na tarefa e quantos estados foram concluídos serão exibidos neste campo

3) Ver Pod

Insira a descrição da imagem aqui

A unidade de execução final do trabalho ainda é o pod. O trabalho recém-criado criará um pod chamado pi. Essa tarefa é calcular o pi. O nome do pod será${job-name}-${random-suffix}

Ele tem mais um pod comum chamado ownerReferences, que declara a qual controlador de nível superior o pod pertence para gerenciar. Você pode ver que as ownerReferences aqui pertencem a batch / v1, que é gerenciado pelo trabalho anterior. Aqui está uma declaração de quem é seu controlador e, em seguida, você pode verificar quem é seu controlador por meio de pod back e, ao mesmo tempo, você pode verificar quais pods ele tem sob o trabalho de acordo com o trabalho.

4) Execute o trabalho em paralelo

Insira a descrição da imagem aqui

Às vezes, existem alguns requisitos: espero que o trabalho possa ser maximizado em paralelo durante a execução e n pods sejam gerados em paralelo para execução rápida. Ao mesmo tempo, devido ao nosso número limitado de nós, podemos não querer ter muitos pods em paralelo ao mesmo tempo. Há um conceito de pipeline. Podemos esperar que o grau máximo de paralelismo seja, e o O controlador de trabalho pode fazer isso por nós.

Aqui estão principalmente dois parâmetros: um é complementos, o outro é paralelismo

Em primeiro lugar, o primeiro parâmetro é usado para especificar o número de execuções dessa fila de pod, que pode ser considerado como o número total de execuções especificadas por este trabalho. Por exemplo, é definido como 8 aqui, ou seja, esta tarefa será executada 8 vezes no total
O segundo parâmetro representa o número de execuções paralelas. O chamado número de execuções paralelas é na verdade o tamanho da fila de buffer em um pipeline ou buffer. Defina-o como 2, o que significa que este trabalho deve ser executado 8 vezes, com 2 pods em paralelo de cada vez. Neste caso, um total de 4 serão executados.

5) Visualize o trabalho paralelo em execução

Insira a descrição da imagem aqui

A imagem acima é o efeito que pode ser visto depois que o trabalho é executado como um todo. Primeiro, veja o nome do trabalho e, em seguida, veja que ele criou um total de 8 pods, que levou 2 minutos e 23 segundos para ser executado .Este é o momento da criação.

A seguir, vamos dar uma olhada nos pods reais. Existem 8 pods no total, e o status de cada pod é completo. Em seguida, olhe para sua IDADE, que é o tempo. De baixo para cima, podemos ver que existem 73s, 40s, 110s e 2m26s, respectivamente. Cada grupo possui dois pods que possuem o mesmo tempo, ou seja, quando o período de tempo é 40s, o último é criado e 2m26s é o primeiro criado. Em outras palavras, sempre dois pods são criados ao mesmo tempo, colocados em paralelo e desaparecidos, em seguida, criados, executados e finalizados novamente

6) Sintaxe CronJob

Insira a descrição da imagem aqui

Comparado com Job, CronJob (tarefa cronometrada) tem vários campos diferentes:

cronograma : Este campo de cronograma serve principalmente para definir o formato da hora, e seu formato de hora é o mesmo do crontime do Linux
** StartingDeadlineSeconds: ** Sempre que um trabalho é executado, quanto tempo ele pode esperar, às vezes o trabalho pode ser executado por um longo tempo sem iniciar. Portanto, neste momento, ainda que por muito tempo, o CronJob interromperá o trabalho
concurrencyPolicy : significa se deve permitir a operação paralela. A chamada operação paralela é, por exemplo, eu executo a cada minuto, mas este trabalho pode demorar muito para ser executado. Se demorar dois minutos para ser executado com sucesso, ou seja, quando o segundo trabalho precisa ser executado a tempo, o trabalho anterior ainda não foi concluído. Se esta política for definida como verdadeira, ela será executada a cada minuto, independentemente de seu trabalho anterior ter sido concluído ou não; se for falsa, ele aguardará a conclusão do trabalho anterior antes de executar o próximo
** JobsHistoryLimit: ** Isso significa que após cada execução do CronJob, ele deixará o histórico de execução e verá o tempo do trabalho anterior. Claro, esse valor não pode ser ilimitado, então você precisa definir o número de retenção histórica, geralmente você pode definir o padrão 10 ou 100.

3) Demonstração da operação

1) Criação de trabalho e verificação de operação

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) Criação de trabalho paralelo e verificação de operação

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) Criação de Cronjob e verificação de operação

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

Uma vez que este CronJob é executado a cada minuto, você kubectl get jobspode não ser capaz de ver as informações do trabalho no início, então você precisa esperar um pouco

4), projeto de arquitetura

Insira a descrição da imagem aqui

Na verdade, o Job Controller ainda tem como objetivo principal criar o pod correspondente, e então o Job Controller rastreará o status do Job, tentará novamente ou continuará a criar de acordo com algumas das configurações enviadas por nós em tempo hábil. Cada pod terá seu rótulo correspondente, para rastrear o Job Controller ao qual pertence e também para configurar a criação paralela, paralela ou serial para criar pods

Insira a descrição da imagem aqui

A figura acima é o fluxo principal de um controlador de tarefas. Todos os jobs são um controlador. Ele observará o servidor API. Cada vez que um job for enviado, o yaml será passado para o etcd por meio do api-server e, em seguida, o Job Controller registrará vários Handlers, sempre que houver adições, atualizações, ou exclusões. Ao aguardar a operação, ele será enviado ao controlador por meio de uma fila de mensagens no nível da memória

Verifique se há um pod em execução no Job Controller. Caso contrário, crie o pod por meio de Aumentar a escala; se houver, ou se for maior que este número, reduza. Se o pod mudar neste momento, você precisa para atualizar seu status a tempo

Ao mesmo tempo, verifique se é um trabalho paralelo ou serial e crie o número de pods em tempo hábil de acordo com o paralelismo configurado e o grau de serialização. Por fim, atualizará todo o status da tarefa para o Servidor API, para que possamos ver o efeito final apresentado

2 、 DaemonSet

1), a fonte de demanda

Insira a descrição da imagem aqui

2), interpretação de caso de uso

1) Sintaxe DaemonSet

Insira a descrição da imagem aqui

O primeiro é gentil: DaemonSet. A sintaxe de DaemonSet tem a mesma parte de Deployment. Por exemplo, ele terá matchLabel, por meio de matchLabel para gerenciar o pod correspondente, este pod.label também deve corresponder a este DaemonSet.controller.label, ele pode encontrá-lo de acordo com label.selector O pod de gerenciamento correspondente. Tudo no spec.container abaixo é consistente

Aqui usamos fluentd como exemplo. Os pontos mais comumente usados do DaemonSet são os seguintes:

O primeiro é o armazenamento. Coisas como GlusterFS ou Ceph precisam executar algo semelhante a um Agente em cada nó. O DaemonSet pode atender bem a essa demanda.
Além disso, para a coleta de logs, como logstash ou fluentd, esses são os mesmos requisitos. Cada nó precisa executar um Agente. Dessa forma, seu status pode ser facilmente coletado e as informações em cada nó podem ser relatadas a tempo. Acima de
Outra é que cada nó precisa executar algumas coisas de monitoramento, e cada nó precisa executar as mesmas coisas, como Promethues, que também precisa do suporte do DaemonSet.

2) Ver o status do DaemonSet

Insira a descrição da imagem aqui

Depois de criar o DaemonSet, você pode usá-lo kubectl get DaemonSet(DaemonSet é abreviado como ds). Percebe-se que o valor de retorno do DaemonSet é muito parecido com o de deployment, ou seja, atualmente ele tem alguns rodando, e depois precisamos de alguns, e alguns estão READY. Claro, READY só tem pods, então tudo o que ele cria no final são pods.

Existem vários parâmetros aqui, a saber: o número de pods necessários, o número de pods que foram criados, o número de pods prontos e todos os pods disponíveis que passaram na verificação de integridade e NODE SELECTOR. NODE SELECTOR é o rótulo de seleção de nó. Às vezes, podemos querer que apenas alguns nós executem este pod em vez de todos os nós, portanto, se alguns nós estiverem marcados, o DaemonSet será executado apenas nesses nós

3) Atualizar DaemonSet

Insira a descrição da imagem aqui

Na verdade, DaemonSet e implantação são muito semelhantes. Ele também tem duas estratégias de atualização: uma é RollingUpdate e a outra é OnDelete

RollingUpdate atualizará um por um. Atualize o primeiro pod primeiro, depois o pod antigo é removido e, em seguida, construa o segundo pod depois de passar na verificação de integridade, para que o negócio seja atualizado sem interrupções
OnDelete é na verdade uma estratégia de atualização muito boa, ou seja, depois que o template for atualizado, não haverá mudanças no pod e precisamos controlá-lo manualmente. Se excluirmos o pod correspondente a um determinado nó, ele será reconstruído. Se não for excluído, não será reconstruído. Dessa forma, também terá um efeito particularmente bom em algumas necessidades especiais que precisamos controlar manualmente .

3) Demonstração da operação

1) Organização do 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) Atualização do 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), projeto de arquitetura

Insira a descrição da imagem aqui

DaemonSet também é um controlador e sua unidade de negócios real final também é um Pod. Na verdade, o DaemonSet é muito semelhante a um controlador de trabalho. Ele também usa o controlador para observar o status do servidor de API e, em seguida, adiciona pods a tempo. A única diferença é que ele monitora o status do nó. Quando um nó é adicionado recentemente ou desaparece, ele cria um pod correspondente no nó e seleciona o nó correspondente de acordo com o rótulo que você configurou.

O controlador do DaemonSet, DaemonSet, na verdade, faz a mesma coisa que o controlador do Job: ambos precisam ser baseados no estado do relógio do servidor API. Agora, a única diferença entre o DaemonSet e o controlador de trabalho é que o controlador DaemonsetSet precisa observar o estado do nó, mas na verdade o estado desse nó ainda é passado para o etcd através do servidor API

Quando o estado de um nó muda, ele é enviado por meio de uma fila de mensagens de memória e, em seguida, o controlador DaemonSet observará esse estado para ver se há um pod correspondente em cada nó e, caso não haja, crie-o. Claro que vai fazer uma comparação, se houver, vai comparar as versões, e depois adicionar o mencionado acima se deseja fazer RollingUpdate? Caso contrário, ele será recriado. Quando Ondelete exclui o pod, ele também verifica se deseja atualizar ou criar o pod correspondente.

Claro, no final, se todas as atualizações forem concluídas, ele atualizará o status de todo o DaemonSet para o servidor API e concluirá a atualização final.