Referência e APIs Batch no GKE

beta

Recursos do Batch no GKE

O Batch traz os novos recursos a seguir do Kubernetes:

BatchJob
Os Jobs descrevem o trabalho a ser feito e os recursos de computação, dados etc. necessários para isso.
BatchQueue
As filas são o elemento organizacional central do Batch. Uma fila define:
    BatchJobConstraint
    Uma restrição define os jobs e políticas aceitáveis de uma determinada fila. Por exemplo, uma restrição pode exigir jobs sem GPUs e menos de 4 horas de duração. Um único recurso BatchJobConstraint pode ser atribuído a várias filas.
    BatchBudget
    Um orçamento define quantos recursos uma fila pode usar ou quanto pode gastar por vez ou em um determinado número de dias. Espera-se que cada esforço, projeto ou equipe receba um orçamento. Várias filas podem consumir o mesmo orçamento.
    BatchPriority
    Os administradores podem definir vários níveis diferentes de prioridade no sistema. Uma fila pode ter um nível de prioridade, mas o mesmo recurso BatchPriority pode ser vinculado a várias filas.

BatchJobs

Um BatchJob define um job de um único usuário. Ele especifica o trabalho que precisa ser executado, as exigências de recursos de computação para esse trabalho e o armazenamento de dados associado ao job. As filas organizam e priorizam jobs de acordo com recursos e dependências.

Um BatchJob precisa ser enviado a uma BatchQueue para programação e controle de orçamento. O requisito de recurso permite que o Batch crie e atribua VMs para cumprir as necessidades computacionais do BatchJob. Quando o BatchJob começar a ser executado, a imagem do contêiner na especificação do job será extraída e executada até terminar.

BatchJobs com uma única tarefa

Uma especificação de BatchJob inclui um taskGroup, além do batchQueueName. Um BatchJob simples tem apenas uma única tarefa no taskGroup.

A seguir, default_job.yaml mostra uma única tarefa de amostra de job:

apiVersion: kbatch.k8s.io/v1beta1
    kind: BatchJob
    metadata:
      # generateName allows the system to generate a random name with a set prefix every time this BatchJob is submitted.
      generateName: pi-
      namespace: default
    spec:
      batchQueueName: default
      taskGroups:
      - name: main
        maxWallTime: 5m
        template:
          spec:
            containers:
            - name: pi
              # This image has been made public so it can be pulled from any project.
              image: gcr.io/kbatch-images/generate-pi/generate-pi:latest
              resources:
                requests:
                  cpu: 1.0
                  memory: 2Gi
                limits:
                  cpu: 1.0
                  memory: 2Gi
              imagePullPolicy: IfNotPresent
            restartPolicy: Never
    

Jobs de matriz: BatchJobs com várias tarefas

ArrayJobs são compatíveis com o Lote v0.8.0. Um Job de matriz é um BatchJob que tem um taskGroup com várias tarefas. Cada tarefa compartilha a mesma especificação de tarefa para que cada uma execute efetivamente a mesma imagem de contêiner com os mesmos requisitos de recursos e outras propriedades do job, como maxWallTime etc. O número de tarefas do taskGroup é especificado pelo campo indexSpec: taskCount.

Cada tarefa em um ArrayJob tem a variável de ambiente KBATCH_ARRAY_INDEX. O valor dessa var é o índice da matriz dessa tarefa. O intervalo do índice da matriz começa em 0 e termina em taskCount-1. Essa variável de ambiente pode ser usada para selecionar entradas e parâmetros diferentes etc., para cada tarefa.

Os seguintes array_job.yaml mostram uma amostra de ArrayJob:

apiVersion: kbatch.k8s.io/v1beta1
    kind: BatchJob
    metadata:
      generateName: array-image-
      namespace: default
    spec:
      batchQueueName: default
      taskGroups:
      - name: main
        maxWallTime: 10m
        indexSpec:
          taskCount: 5
        template:
          spec:
            containers:
              - name: greyimage
                # This image has been made public so it can be pulled from any project.
                image: gcr.io/kbatch-images/greyimage/greyimage:latest
                command: ["./greyimage"]
                args: ["-in=/mnt/pv/array-image-data/input_$(KBATCH_ARRAY_INDEX).png", "-out=/mnt/pv/array-image-data/output_$(KBATCH_ARRAY_INDEX).png"]
                volumeMounts:
                  - mountPath: /mnt/pv
                    name: mypvc
                resources:
                  limits:
                    cpu: 1.0
                    memory: 2Gi
                  requests:
                    cpu: 1.0
                    memory: 2Gi
                imagePullPolicy: IfNotPresent
            restartPolicy: Never
            volumes:
              - name: mypvc
                persistentVolumeClaim:
                  claimName: pvc
                  readOnly: false
    

Depois que um BatchJob é enviado, o Batch processa o job e marca o status mais recente dele no campo Phase. As fases de um job são estas:

Fase Descrição
Na fila O job foi aceito no sistema e está aguardando para ser programado.
Programado O job foi programado pelo programador de jobs e está aguardando para ser atribuído a um nó.
Pronto O job foi atribuído a um nó e está aguardando que o nó esteja pronto.
Em execução O job está em execução.
Falha Houve uma falha no job.
Concluído O job foi concluído.

Caso algum job precise acessar alguns armazenamentos de dados de entrada e saída, o Batch é compatível com a ativação de um volume baseado no Kubernetes PersistentVolumeClaim (PVC) (em inglês) no contêiner do job.

O data_job.yaml a seguir mostra um exemplo:

apiVersion: kbatch.k8s.io/v1beta1
    kind: BatchJob
    metadata:
      name: data-job
      namespace: default
    spec:
      batchQueueName:  default
      taskGroups:
        maxWallTime:  10m
        name: default
        retryLimit:    0
        template:
          spec:
            containers:
              image:  ubuntu:latest
              name:   data-util
              volumeMounts:
              - mountPath:  /jobdata
                name:        data-volume
            restartPolicy:  Never
            volumes:
              name:  data-volume
              persistentVolumeClaim:
                claimName:  pvc
    

BatchQueues

O Batch introduz um novo recurso, o BatchQueue. No Batch, uma BatchQueue é uma forma de agrupar, gerenciar e lidar com BatchJobs estritamente relacionados, normalmente da mesma equipe.

O Batch permite ter vários BatchQueues em um cluster. BatchQueues são objetos para organizar e gerenciar esforços lógicos da sua organização por meio de orçamentos, prioridades e políticas. Jobs que usam o mesmo orçamento ou com as mesmas políticas precisam ser colocados no mesmo conjunto de BatchQueues. É possível permitir que um usuário envie para diferentes BatchQueues.

O YAML a seguir define uma BatchQueue usando o BatchBudget default:

apiVersion: kbatch.k8s.io/v1beta1
    kind: BatchQueue
    metadata:
      labels:
        controller-tools.k8s.io: "1.0"
      name: default
      namespace: default
    spec:
      batchPriorityName: high
      batchBudgetName: default
      constraintNames: ["default"]
    

BatchPriority

O administrador do sistema pode criar vários objetos prioritários. Cada objeto prioritário tem uma prioridade definida por um número inteiro. É possível especificar um objeto prioritário em cada BatchQueue. Os jobs e pods criados a partir dessa BatchQueue herdam essa prioridade.

Os arquivos .yaml a seguir mostram um exemplo de BatchPriority:

apiVersion: kbatch.k8s.io/v1beta1
    kind: BatchPriority
    metadata:
      labels:
        controller-tools.k8s.io: "1.0"
      name: high
    spec:
      value: 100
      description: High Priority
    

As prioridades não são namespace, então podem ser aplicadas a uma BatchQueue em qualquer namespace. Depois de criar uma prioridade, ela é vinculada a uma BatchQueue atualizando o campo batchPriorityName na BatchQueue com o nome da prioridade. O campo batchPriorityName pode ser atualizado a qualquer momento.

Quando um job é executado, o programador ordena com base na prioridade da fila. Em geral, os jobs provenientes de uma BatchQueue com prioridade 88 serão executados antes de uma BatchQueue com prioridade 3.

Um BatchPriority só poderá ser excluído se uma BatchQueue não se referir a ele em um BatchPriorityName.

BatchJobConstraints

BatchJobConstraints são agrupamentos de restrições que podem ser vinculados a uma BatchQueue. BatchJobConstraints não são namespaces e podem ser aplicados a BatchQueues em qualquer namespace. Quando um BatchJob é enviado a uma BatchQueue, as restrições são verificadas para validar o BatchJob. O BatchJob só será inserido na fila se atender às restrições.

Por exemplo, se uma restrição de WallTime estiver configurada para 30 m, apenas jobs com menos de 30 m serão permitidos na fila.

O administrador pode exigir que determinadas BatchQueues tenham apenas certos tipos de jobs. Por exemplo, uma BatchQueue criada para uma iteração rápida durante o desenvolvimento pode ter alta prioridade, mas exigir que os jobs tenham um tempo decorrido menor e não usem muitas CPUs.

Se uma BatchQueue especificar um BatchJobConstraint, esses requisitos serão aplicados por padrão a qualquer job dessa BatchQueue, caso os valores desses requisitos não sejam especificados. Caso o job especifique um desses requisitos com um valor incompatível, haverá uma falha durante o envio.

Os arquivos .yaml a seguir mostram um exemplo de BatchJobConstraint:

apiVersion: kbatch.k8s.io/v1beta1
    kind: BatchJobConstraint
    metadata:
      labels:
        controller-tools.k8s.io: "1.0"
      name: default
    spec:
      # The system supports the following constraints:
      # Cpu, Memory, WallTime, Gpu, GpuModel, RetryLimit
      # Adding a BatchJobConstraint to a BatchQueue means that the BatchQueue will only accept jobs that satisfy the
      # listed constraints.
      constraints:
        - name: WallTime
          operator: LessThan
          values: ["24h"]
    

A tabela a seguir mostra os campos compatíveis e os operadores disponíveis para cada um desses valores:

Nome do campo Operador Exemplo
WallTime LessThan, GreaterThan, Equal, In, NotIn, Exists WallTime : 30m, 1h
Memory LessThan, GreaterThan, Equal, In, NotIn, Exists Memory: 128974848, 129e6, 129M, 123Mi
Cpu LessThan, GreaterThan, Equal, In, NotIn, Exists Cpu: 0.1, 100m, 1
Gpu LessThan, GreaterThan, Equal, In, NotIn, Exists Gpu: 0, 1, 2
GpuModel Equal, In, NotIn, Exists GpuModel: nvidia-tesla-p4, nvidia-tesla-k80, nvidia-tesla-v100, nvidia-tesla-p100, nvidia-tesla-t4
RetryLimit LessThan, GreaterThan, Equal, In, NotIn, Exists RetryLimit: 0, 1, 2

A tabela a seguir mostra os operadores e requisitos de valores para cada operador:

Operador Especificação de valores
LessThan, GreaterThan, Equal Requer apenas um valor
Memory Requer apenas um valor
In, NotIn Requer pelo menos um valor
Exists Não requer valores

BatchBudgets

Uma BatchQueue pode ter um batchBudgetName opcional que limita quantos recursos a BatchQueue pode usar em uma determinada janela. Os orçamentos são aproximações úteis para adaptar e evitar gastos excessivos de CPU, GPUs e memória. BatchBudgets também permitem limitar o impacto de uma BatchQueue de alta prioridade que esteja consumindo todos os recursos disponíveis.

BatchBudgets não podem considerar recursos e APIs fora do cluster, como tráfego de rede, armazenamento de objetos ou APIs de terceiros. Eles também não são uma representação da fatura real. Para usar um orçamento, defina um modelo de custo (ou tabela de preços) para cada recurso por hora. Conforme os jobs de BatchQueues usam esses recursos, o orçamento é debitado do valor total.

O default_budget.yaml a seguir mostra um exemplo de orçamento:

apiVersion: kbatch.k8s.io/v1beta1
    kind: BatchBudget
    metadata:
      labels:
        controller-tools.k8s.io: "1.0"
      name: default
    spec:
      batchCostModelName: "default"
      # Two durations are currently supported: 24h and 720h (30d). These may be combined, by specifying
      # two budget windows, to enforce both a daily and monthly limit.
      budgetWindows:
        - duration: "24h"
          amount: 100
    

Este exemplo limita a BatchQueue a um gasto de 100 unidades por dia. O custo de cada recurso está definido no costModel abaixo. Quando o orçamento for excedido, jobs novos e na fila só poderão ser executados após a atualização da janela de orçamento. Também é possível aumentar o valor da janela de orçamento para permitir que jobs na fila sejam executados antes da atualização da janela.

BatchBudgets usam um modelo de reserva. Por exemplo, se 1 hora de CPU custa 1 unidade e o job tem um limite de tempo de 10 horas, o programador só permitirá que o job seja executado se o orçamento tiver pelo menos 10 unidades restantes para o período. Quando o job for marcado como pronto, serão reservadas 10 unidades de orçamento. Se o job for executado e concluído com cinco unidades, as outras cinco retornarão ao orçamento. O modelo de reserva evita que jobs sejam interrompidos no meio do processo por falta de orçamento.

O default_costmodel.yaml a seguir mostra um exemplo de costModel:

apiVersion: kbatch.k8s.io/v1beta1
    kind: BatchCostModel
    metadata:
      labels:
        controller-tools.k8s.io: "1.0"
      name: default
    spec:
      resources:
        # These costs are hourly and in USD. For example, based on the numbers below, running using 1 CPU
        # 1 GB of RAM, and 1 Tesla T4 GPU for 2 hours would cost 2 * ($0.031611 + $0.004237 + $0.95)
        # The values are taken from https://cloud.google.com/compute/pricing for
        # region us-west1. The values are accurate as of April 2019. Actual pricing depends on various factors,
        # such as long-term contracts, use of standard machine types, the region, etc.
        cpu: 0.031611  # This is the on-demand price for a single vCPU
        memory: 0.004237  # This is the on-demand price for 1GB of memory
        nvidia.com/gpu: 0.95  # This is the cost for use of the Tesla T4 GPU. Currently the system does not support breaking out prices for specific GPU types, so an average price for the intended GPUs should be used here.
    

Como excluir recursos

Alguns tipos de recursos dependem de outros. Por exemplo, a BatchQueue usa o BatchPriority. O Batch se esforça ao máximo para evitar excluir recursos de que os outros dependam. A primeira linha de defesa é o controlador de admissão, que rejeita exclusões de dependências em uso.

Devido à natureza do Kubernetes, nem sempre é possível detectar dependências. Particularmente, pode haver uma disputa entre a exclusão e um novo uso da dependência. O Batch tem um segundo mecanismo que lida com esses casos. Caso isso aconteça, a dependência será excluída quando detectar que o recurso não está mais em uso.

Gerenciamento de usuários e acesso

O Batch diferencia dois tipos de usuários: administradores, que configuram, gerenciam e administram o cluster, e praticantes, que enviam BatchJobs ao sistema.

O Batch segue o princípio de privilégio mínimo, que é conceder aos praticantes e às VMs que executam os jobs o escopo e o acesso mínimo necessário. Os administradores podem conceder mais acesso aos usuários, mas para isso precisam seguir uma política de segurança bem definida.

O gerenciamento de usuários do Batch no GKE é realizado por meio de um conjunto de RBACs do Kubernetes (em inglês) e um CRD BatchUserContext para cada usuário. O Batch fornece um script para definir essas configurações em uma única etapa. Para mais informações, consulte Como gerenciar usuários do Batch no GKE.

Por padrão, os praticantes não têm acesso aos recursos do Batch no GKE. O Batch oferece ferramentas de gerenciamento de usuários compatíveis com os casos de uso a seguir:

  • Usuários podem enviar jobs em lote e acessar o resultado do job sem interagir com o job de outro usuário por engano.
  • Como um nível extra de proteção, usuários do Batch no GKE podem ter um acesso separado a dados de armazenamento no nível PersistentVolumeClaim e no nível de controle de acesso a arquivos Unix.
  • Administradores do sistema podem configurar a política de segurança do Kubernetes (em inglês) e a política de acesso a arquivos do Unix para os usuários. O Batch vinculará e validará essas políticas quando um usuário enviar um job.

Controle de acesso do Batch no GKE baseado no papel do usuário

A tabela a seguir descreve o conjunto de RBACs de um usuário do Batch no GKE:

Recursos Escopos Verbos
BatchJobs Tudo em um namespace Get, List, Watch, Create
Pods Tudo em um namespace List
BatchQueue Todas as filas de lote no namespace Get, List
BatchPriority Tudo no cluster Get, List
BatchBudgets/BatchcostModel Tudo no cluster Get, List
PersistentVolumeClaim Somente o que pode ser usado por esse usuário no namespace Get
Secrets Somente o que pode ser usado por esse usuário no namespace Get

Depois que um job é enviado, o criador de conteúdo pode encerrá-lo. Administradores de cluster têm permissão para excluir BatchJobs. Quando um BatchJob é excluído, o mesmo acontece com os RBACs dinamicamente concedidos associados ao job.

Limitação da versão Beta

  • A versão Beta do Batch é compatível apenas com jobs de nó único (VM). Jobs de vários nós, programados em grupo ou de MPI não são compatíveis no momento.

  • Ao colocar pods em VMs, o GKE considera a sobrecarga dos agentes na própria VM. Por exemplo, ele considera uma VM de quatro vCPUs como tendo apenas um número menor de vCPUs disponíveis para trabalho (normalmente algo como 3,8), para não colocar nessa VM um job que precise de quatro vCPUs.

  • O modelo de custo só é compatível com um tipo de GPU.

  • O nome de usuário, [NAME]@[PROJECT_NAME].iam.gserviceaccount.com, é limitado a 63 caracteres. Isso significa que NAME e [PROJECT_NAME] estão limitados a 37 caracteres.

  • O campo runAsGroup em PodSecurityPolicy não é compatível com o GKE.

  • O Batch é compatível com volumes NFS usando PersistentVolumeClaims.

  • O número máximo de envios de jobs simultâneos é 10.000.

Referência

BatchPriority v1beta1 kbatch.k8s.io

BatchPriority é o esquema da API batchpriorities.

Campos
metadata

Kubernetes meta/v1.ObjectMeta

Consulte a documentação da API Kubernetes para saber mais sobre os campos de metadados.

spec

BatchPrioritySpec

status

BatchPriorityStatus

BatchPrioritySpec

Campos
Value

int32

Description

String

BatchJobConstraint v1beta1 kbatch.k8s.io

BatchJobConstraint é o esquema da API batchjobconstraints.

Campos
metadata

Kubernetes meta/v1.ObjectMeta

Consulte a documentação da API Kubernetes para saber mais sobre os campos de metadados.

spec

BatchJobConstraintSpec

status

BatchJobConstraintStatus

BatchCostModel v1beta1 kbatch.k8s.io

BatchCostModel é o esquema da API batchcostmodels

Campos
metadata

Kubernetes meta/v1.ObjectMeta

Consulte a documentação da API Kubernetes para saber mais sobre os campos de metadados.

spec

BatchCostModelSpec

status

BatchCostModelStatus

BatchCostModelSpec v1beta1 kbatch.k8s.io

BatchCostModelSpec permite definir o custo dos recursos.

Campos
resources

ResourceCostList

Consulte a documentação da API Kubernetes para saber mais sobre os campos de metadados.

ResourceName v1beta1 kbatch.k8s.io

ResourceName é o tipo de recurso.

Campos
ResourceCPU

representa o recurso da CPU.

ResourceMemory

representa o recurso da memória.

ResourceGPU

representa o recurso da GPU.

BatchBudget v1beta1 kbatch.k8s.io

BatchBudget é o esquema da API batchbudgets.

Campos
metadata

Kubernetes meta/v1.ObjectMeta

Consulte a documentação da API Kubernetes para saber mais sobre os campos de metadados.

spec

BatchBudgetSpec

status

BatchBudgetStatus

Define o estado observado do BatchBudget.

BatchBudgetSpec v1beta1 kbatch.k8s.io

BatchBudgetSpec define o estado desejado do BatchBudget.

Campos
batchCostModelName

String

Nome do BatchCostModel usado neste orçamento.

budgetStartTime

Kubernetes meta/v1.Time

Horário de início da primeira janela do orçamento. Caso não seja definido, ele é preenchido com a hora de criação do orçamento.

budgetWindows

[]BudgetWindow

Uma matriz de janelas, cada uma definindo um valor limite de orçamento para a janela. BudgetWindows [i].Duration precisa ser exclusivo dentro do BudgetWindows.

BatchBudgetStatus v1beta1 kbatch.k8s.io

BatchBudgetStatus define o estado observado do BatchBudget

Campos
LastUpdated

String

Hora da atualização mais recente.

WindowStatusList

[]BudgetWindowStatus

(Opcional)

WindowStatusList tem uma entrada para cada janela exibir o status detalhado. WindowStatusList[i].Start <= time.Now() precisa ser mantido.

BudgetWindow v1beta1 kbatch.k8s.io

BudgetWindow define o valor limite do orçamento na janela.

Campos
duration

Kubernetes meta/v1.Duration

A duração define o tamanho da janela. Neste momento, só podem ser usados dias, então os valores terão apenas o sufixo "d" referente a "dias". Posteriormente, haverá compatibilidade para qualquer unidade de duração, como hora, semana etc.

amount

[]BudgetWindowStatus

(Opcional)

O valor é o limite do orçamento da janela.

BudgetWindowStatus v1beta1 kbatch.k8s.io

BudgetWindowStatus mostra informações de consumo de orçamento de uma janela, incluindo a janela atual e as anteriores.

Campos
duration

Kubernetes meta/v1.Duration

A duração define o tamanho da janela. Neste momento, só podem ser usados dias, então os valores terão apenas o sufixo "d" referente a "dias". Posteriormente, haverá compatibilidade para qualquer unidade de duração, como hora, semana etc.

startTime

Kubernetes meta/v1.Time

Horário de início da janela atual. Quando a janela termina, ela é adicionada ao Histórico e uma nova janela atual é criada.

amount

float64

Orçamento usado na janela.

windowHistory

[]BudgetWindowHistoryRecord

Para cada janela concluída com essa duração, essa lista monitora o orçamento usado. Na versão alfa, o histórico de janelas diárias é mantido por 90 dias e são mantidos 3 registros de histórico para janelas de 30 dias.

BudgetWindowHistoryRecord v1beta1 kbatch.k8s.io

BudgetWindowHistoryRecord registra o orçamento usado na janela.

Campos
windowStartTime

Kubernetes meta/v1.Time

Horário de início da janela.

windowEndTime

Kubernetes meta/v1.Time

Horário de término da janela.

amount

float64

Orçamento usado na janela.

BatchQueue v1beta1 kbatch.k8s.io

BatchQueue é o esquema da API batchqueues.

Campos
metadata

Kubernetes meta/v1.ObjectMeta

Consulte a documentação da API Kubernetes para saber mais sobre os campos de metadados.

spec

BatchQueueSpec

status

BatchQueueStatus

BatchQueueSpec v1beta1 kbatch.k8s.io

BatchQueueSpec define o estado desejado da BatchQueue.

Campos
BatchPriorityName

String

O nome do recurso BatchPriority associado à BatchQueue. Os jobs nessa BatchQueue terão prioridade na programação com base no BatchPriority definido aqui.

PauseAdmission

bool

(Opcional)

Se verdadeiro, a BatchQueue não aceitará novos jobs. Isso não afeta a programação de jobs.

PauseScheduling

bool

(Opcional)

Se verdadeiro, a BatchQueue não programará jobs. Isso não afeta a admissão de jobs.

BatchBudgetName

String

O nome do recurso BatchBudget associado à BatchQueue.

ConstraintNames

[]string

Tem os nomes de BatchJobConstraints a serem aplicados à fila.

BatchJob v1beta1 kbatch.k8s.io

BatchJob é o esquema da API batchjobs

Campos
metadata

Kubernetes meta/v1.ObjectMeta

Consulte a documentação da API Kubernetes para saber mais sobre os campos de metadados.

spec

BatchJobSpec

BatchJobSpec define o estado desejado do BatchJob

status

BatchJobStatus

BatchJobStatus define o estado observado do BatchJob

BatchJob v1beta1 kbatch.k8s.io

BatchJob é o esquema da API batchjobs

Campos
metadata

Kubernetes meta/v1.ObjectMeta

Consulte a documentação da API Kubernetes para saber mais sobre os campos de metadados.

spec

BatchJobSpec

status

BatchJobStatus

Status do job Este campo precisa ser um ponteiro, opcional e omitempty./p>

BatchJobSpec v1beta1 kbatch.k8s.io

Campos
TaskGroups

[]BatchTaskGroupSpec

Especificação do grupo de tarefas.

BatchQueueName

string

O nome da BatchQueue em que o BatchJob será executado.

Dependencies

[]BatchJobDependency

(Opcional)

Dependencies define várias dependências do BatchJob. A lógica entre cada dependência é a operação "OR". Por exemplo: Dependencies[0] Dependencies[1] A lógica entre Dependencies[0] e Dependencies[1] é: Dependencies[0] || Dependencies[1]Por enquanto só há compatibilidade com uma dependência.

batchQueueName

string

O nome da BatchQueue em que o BatchJob será executado.

UserCommand

string

Opcional

UserCommand do BatchJob. O padrão é uma string vazia. Se o campo estiver vazio, não haverá comando do usuário final. Se for definido como" "Terminate" "enquanto o BatchJob estiver em execução, encerre o BatchJob

taskGroupSpec v1beta1 kbatch.k8s.io

Campos
Name

string

Nome deste grupo de tarefas.

IndexSpec

BatchIndexSpec

especifique a contagem de tarefas para um job de matriz. O TaskCount máximo permitido é 1000.

Template

Kubernetes pod template spec

Nome deste grupo de tarefas.

MaxWallTime

string

Por tarefa, tempo máximo de execução em uma única execução.

RetryLimit

int32

(Opcional)

RetryLimit define o limite de tentativas por tarefa. Os ambientes de execução da tarefa serão RetryLimit + 1. Caso não seja especificado, o padrão será 0.

BatchIndexSpec v1beta1 kbatch.k8s.io

Campos
TaskCount

string

Número de tarefas.

BatchJobStatus v1beta1 kbatch.k8s.io

BatchJobStatus define o estado observado do BatchJob.

Campos
Phase

BatchJobPhase

(opcional)

A fase atual do job.

BatchPriority

BatchPriority

(Opcional)

Uma cópia do recurso BatchPriority associado ao BatchJob (com base no batchPriorityName declarado na BatchQueue associada ao BatchJob).

BudgetConsumed

float64

(Opcional)

Orçamento agregado consumido para o job, incluindo todas as tarefas.

Conditions

[]BatchJobCondition

(opcional)

As últimas observações disponíveis do estado atual do batchjob.

SubmittedBy

string

(opcional)

O usuário que enviou o job.

GroupStatus

string

(opcional)

Status por grupo de tarefas.

A seguir