CronJobs

Autopilot Padrão

Os CronJobs estão geralmente disponíveis (GA) na versão 1.21 e posteriores do Google Kubernetes Engine (GKE). Este documento explica como executar CronJobs no GKE. Os CronJobs são uma funcionalidade integrada do Kubernetes. Para mais detalhes, consulte a documentação do Kubernetes sobre CronJobs.

Vista geral

Os CronJobs criam tarefas do Kubernetes numa programação repetitiva. Os CronJobs permitem-lhe automatizar tarefas regulares, como fazer cópias de segurança, criar relatórios, enviar emails ou tarefas de limpeza.

Os CronJobs são criados, geridos, dimensionados e eliminados da mesma forma que os Jobs. O número exato de objetos Job criados depende de vários fatores. Para mais informações, consulte as limitações do CronJob.

Para mais informações sobre as tarefas, consulte o artigo Executar uma tarefa.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

• Ative a API Google Kubernetes Engine.
Ative a API Google Kubernetes Engine
• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute o comando gcloud components update para obter a versão mais recente. As versões anteriores da CLI gcloud podem não suportar a execução dos comandos neste documento.
  Nota: para instalações existentes da CLI gcloud, certifique-se de que define a compute/region propriedade. Se usar principalmente clusters zonais, defina o compute/zone. Ao definir uma localização predefinida, pode evitar erros na CLI gcloud, como os seguintes: One of [--zone, --region] must be supplied: Please specify location. Pode ter de especificar a localização em determinados comandos se a localização do seu cluster for diferente da predefinição que definiu.

Criar um CronJob

Pode criar um CronJob através de um ficheiro do manifesto. Por exemplo, o manifesto YAML seguinte imprime a hora atual e uma string uma vez por minuto, mantendo os valores predefinidos para os parâmetros CronJob:

# cronjob.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Allow
  startingDeadlineSeconds: 100
  suspend: false
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo "Hello, World!"
          restartPolicy: OnFailure

Nota: se o cluster executar versões do GKE anteriores à 1.21, especifique batch/v1beta1 no campo apiVersion.

Para criar este CronJob, guarde o manifesto YAML num ficheiro e aplique-o ao cluster:

kubectl apply -f PATH_TO_FILE

Substitua PATH_TO_FILE pelo caminho para o manifesto YAML.

Configurar um CronJob

Pode especificar os seguintes parâmetros quando cria um CronJob:

• Quando o CronJob é executado
• O que faz o CronJob
• O prazo para o CronJob começar
• Se são permitidas tarefas simultâneas para o CronJob
• Se os novos empregos estão suspensos
• Quantas execuções o CronJob guarda no respetivo histórico

Especificar quando o CronJob é executado

O campo spec.schedule define quando e com que frequência o CronJob é executado, usando o formato crontab padrão do Unix. Todas as horas do CronJob estão em UTC. Existem cinco campos separados por espaços. Estes campos representam o seguinte:

1. Minutos (entre 0 e 59)
2. Horas (entre 0 e 23)
3. Dia do mês (entre 1 e 31)
4. Mês (entre 1 e 12)
5. Dia da semana (entre 0 e 6, começando no domingo)

Pode usar os seguintes carateres especiais em qualquer um dos campos spec.schedule:

• ? é um valor universal que corresponde a um único caráter.
• * é um valor universal que corresponde a zero ou mais carateres.
• / permite especificar um intervalo para um campo. Por exemplo, se o primeiro campo (o campo dos minutos) tiver um valor de */5, significa "a cada 5 minutos". Se o quinto campo (o campo do dia da semana) estiver definido como 0/5, significa "todos os quintos domingos".

Especificar o que o CronJob executa

O spec.jobTemplate descreve o que o CronJob faz, incluindo as imagens dos contentores, os comandos que os contentores executam e a política de reinício do CronJob. Para mais detalhes sobre o que incluir no spec.jobTemplate, consulte a documentação do CronJob do Kubernetes.

Especificar um prazo

O campo startingDeadlineSeconds opcional indica o número máximo de segundos que o CronJob pode demorar a iniciar se perder a hora agendada por qualquer motivo. Os CronJobs perdidos são considerados falhas.

Para especificar um prazo, adicione o valor startingDeadlineSeconds ao campo spec do CronJob no ficheiro de manifesto. Por exemplo, o seguinte manifesto especifica que o CronJob tem 100 segundos para começar:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  startingDeadlineSeconds: 100
  jobTemplate:
    spec:
    ...

Nota: se especificar um valor vazio para o campo startingDeadlineSeconds, o CronJob nunca excede o limite de tempo. Isto pode levar à execução do mesmo CronJob várias vezes em simultâneo. Pode evitar esta situação especificando uma política de simultaneidade.

Especificar uma política de concorrência

O campo spec.concurrencyPolicy opcional especifica como tratar as execuções concorrentes de uma tarefa criada pelo controlador CronJob. Se não definir um valor, são permitidas várias tarefas simultâneas por predefinição.

O elemento concurrencyPolicy aceita os seguintes valores:

Valor	Significado
Allow	Os trabalhos simultâneos são permitidos. Esta é a predefinição.
Forbid	As tarefas simultâneas são proibidas e as novas tarefas não podem ser iniciadas até que as anteriores tenham sido concluídas ou tenham excedido o tempo limite.
Replace	As tarefas simultâneas são proibidas e as tarefas antigas são canceladas a favor das novas.

Suspender execuções subsequentes

O campo spec.suspend opcional, quando definido como true, impede a execução de novas tarefas, mas permite que as execuções atuais terminem.

Especificar limites do histórico

Um CronJob cria um Pod sempre que é executado. A visualização do estado de terminação das execuções recentes de um CronJob, bem como os registos de um Pod individual, são abordados no artigo Visualizar o histórico do CronJob.

Pode configurar o número de execuções de CronJob bem-sucedidas e com falhas que são guardadas especificando valores para spec.successfulJobsHistoryLimit e spec.failedJobsHistoryLimit. Por predefinição, successfulJobsHistoryLimit está definido como 3 e failedJobsHistoryLimit está definido como 1.

Por exemplo, o manifesto seguinte indica ao GKE para guardar um máximo de cinco execuções bem-sucedidas do CronJob e um máximo de 10 execuções falhadas do CronJob:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  startingDeadlineSeconds: 100
  successfulJobsHistoryLimit: 5
  failedJobsHistoryLimit: 10
  jobTemplate:
    spec:
    ...

Pode desativar a retenção do histórico de execução de CronJobs bem-sucedidos ou com falhas definindo o valor respetivo como 0. A desativação da retenção do histórico pode dificultar a depuração de falhas. Por exemplo, o seguinte manifesto indica ao GKE que apenas guarde as execuções do CronJob com falhas:

kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  startingDeadlineSeconds: 100
  successfulJobsHistoryLimit: 0
  failedJobsHistoryLimit: 10
  jobTemplate:
    spec:
    ...

Inspeção de um CronJob

Para verificar a configuração de um CronJob, use kubectl describe:

kubectl describe cronjob CRONJOB_NAME

Substitua CRONJOB_NAME pelo nome do CronJob a inspecionar.

Visualizar o histórico de CronJob

Um CronJob é executado num Pod. Por predefinição, o Kubernetes preserva os registos dos pods terminados que representam as últimas três execuções bem-sucedidas de um CronJob e o Job com falhas mais recente. Pode alterar ou desativar estas predefinições alterando os limites do histórico de CronJob.

Para ver o histórico de um CronJob, comece por listar todos os pods. Os CronJobs concluídos são apresentados com o estado Completed, e os trabalhos com falhas têm o estado RunContainerError, CrashLoopBackOff ou outro estado que indique uma falha.

Nota: pode ver mais entradas do que o esperado. O histórico de CronJob está sujeito à recolha de lixo periódica. Por exemplo, no resultado abaixo, são apresentadas quatro instâncias do hello CronJob.

NAME                                READY   STATUS              RESTARTS   AGE
hello-1556555640-9bc5r              0/1     Completed           0          3m6s
hello-1556555700-cm6wk              0/1     Completed           0          2m6s
hello-1556555760-62wf5              0/1     Completed           0          66s
hello-1556555820-rl8kl              0/1     Completed           0          5s
hello-failed-1556555820-wrvt2       0/1     RunContainerError   1          5s

Pode fazer com que uma tarefa falhe intencionalmente modificando o manifesto de exemplo em Criar um CronJob. Altere o campo args em spec.containers para um comando inválido ou um caminho que não existe, e altere o valor metadata.name para um que indique que está a testar falhas.

Para ver os registos de um CronJob específico, execute o seguinte comando:

kubectl logs POD_NAME

Substitua POD_NAME pelo nome do Pod que quer inspecionar.

O resultado é semelhante ao seguinte:

container_linux.go:247: starting container process caused
"exec: \"/in/sh\": stat /in/sh: no such file or directory"

Eliminar um CronJob

Para eliminar um CronJob, execute o seguinte comando:

kubectl delete cronjob CRONJOB_NAME

Quando elimina um CronJob, o coletor de lixo do Kubernetes elimina os trabalhos associados e impede o início de novos trabalhos.

O que se segue?

• Leia a documentação do Kubernetes para CronJobs.
• Saiba como executar uma tarefa única.