Referencia y API de Batch en GKE

beta

Recursos de Batch en GKE

Batch presenta los siguientes recursos nuevos de Kubernetes:

BatchJob
Los trabajos describen el trabajo que se debe realizar y los recursos de procesamiento, datos, etc. necesarios para hacerlo.
BatchQueue
Las colas son la construcción organizativa central en Batch. Una cola especifica lo siguiente:
    BatchJobConstraint
    Una restricción especifica los trabajos y políticas aceptables en una cola determinada. Por ejemplo, una restricción puede requerir trabajos sin GPU y de menos de 4 horas de duración. Se puede asignar un mismo recurso de BatchJobConstraint a varias colas.
    BatchBudget
    Un presupuesto define cuántos recursos puede usar una cola o cuánto puede gastar a la vez o en una determinada cantidad de días. El uso previsto significa que a cada esfuerzo, proyecto o equipo se le asigna un presupuesto. Varias colas pueden consumir el mismo presupuesto.
    BatchPriority
    Los administradores pueden definir varios niveles de prioridad diferentes en el sistema. Una cola puede tener un nivel de prioridad, pero el mismo recurso de BatchPriority puede asociarse a varias colas.

BatchJobs

Un BatchJob define un único trabajo de usuario. Especifica el trabajo que se debe ejecutar, los requisitos de recursos de procesamiento para ese trabajo y el almacenamiento de datos asociado a él. Las colas organizan y priorizan trabajos en función de los recursos y las dependencias.

Un BatchJob debe enviarse a una BatchQueue para la programación y el control del presupuesto. El requisito de recursos permite que Batch cree y asigne VM para satisfacer las necesidades de procesamiento de BatchJob. Una vez que BatchJob comience a ejecutarse, se extraerá la imagen del contenedor en la especificación del trabajo y se la ejecutará hasta su finalización.

BatchJobs con una sola tarea

Una especificación de BatchJob incluye un taskGroup además del batchQueueName. Un BatchJob simple realiza solo una tarea dentro de su taskGroup.

En el siguiente default_job.yaml, se puede ver un trabajo de muestra de una sola tarea:

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
    

ArrayJobs: BatchJobs con varias tareas

Los ArrayJobs son compatibles con Batch v0.8.0. Un ArrayJob es un BatchJob cuyo taskGroup tiene varias tareas. Las tareas comparten la misma especificación para que cada una ejecute de manera eficaz la misma imagen de contenedor con los mismos requisitos de recursos y otras propiedades del trabajo como maxWallTime, etc. La cantidad de tareas para el taskGroup se especifica mediante el campo indexSpec: taskCount.

Cada tarea en un ArrayJob tiene la variable de entorno KBATCH_ARRAY_INDEX. El valor de esta variable es el índice del arreglo de esta tarea. El rango del índice del arreglo comienza con 0 y termina con taskCount-1. Esta variable de entorno se puede usar con el fin de seleccionar diferentes entradas, parámetros, etc. para cada tarea.

En el siguiente array_job.yaml, se puede ver un ArrayJob de muestra:

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
    

Después de enviar un BatchJob, Batch procesa el trabajo y marca su estado más reciente en el campo Phase del estado del trabajo. Las fases de un trabajo son las siguientes:

Fase Descripción
En cola Se admite el trabajo en el sistema y se espera a que se programe.
Programado El programador de trabajos planifica el trabajo y espera a que se lo asigne a un nodo.
Listo El trabajo se asigna a un nodo y se espera a que el nodo esté listo.
Activo El trabajo se está ejecutando.
Error El trabajo falló.
Exitoso El trabajo se completó de forma correcta.

Si un trabajo necesita acceso a algún almacenamiento de archivos para datos de entrada y salida, Batch admite la activación de un volumen basado en PersistentVolumeClaim (PVC) de Kubernetes en el contenedor del trabajo.

El siguiente comando data_job.yaml muestra un ejemplo:

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

Batch presenta un recurso nuevo, BatchQueue. En Batch, una BatchQueue permite agrupar, administrar y deducir los BatchJobs más relacionados, en general del mismo equipo.

Batch te permite tener varias BatchQueues en el clúster. Las BatchQueues son objetos para organizar y administrar esfuerzos lógicos en tu organización con presupuestos, prioridades y políticas. Los trabajos que usan el mismo presupuesto o deben tener las mismas políticas se colocan en el mismo conjunto de BatchQueues. Puedes permitir que un usuario envíe trabajos a diferentes BatchQueues.

El siguiente YAML define una BatchQueue mediante el 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

El administrador del sistema puede crear varios objetos prioritarios. Cada objeto prioritario tiene una prioridad entera. Se puede especificar un objeto prioritario en cada BatchQueue. Los trabajos y pods creados a partir de esa BatchQueue heredan esa prioridad.

En los siguientes archivos .yaml, se muestra un ejemplo 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
    

Las prioridades no tienen un espacio de nombres, por lo que se las puede aplicar a una BatchQueue en cualquier espacio de nombres. Después de crear una prioridad, se la adjunta a una BatchQueue cuando se actualiza el campo batchPriorityName en la BatchQueue con el nombre de la prioridad. El campo batchPriorityName puede actualizarse en cualquier momento.

Cuando se ejecuta un trabajo, el programador prioriza según la prioridad de la cola. En general, los trabajos provenientes de una BatchQueue con una prioridad de 88 se ejecutarán antes que los de una BatchQueue con una prioridad de 3.

Solo puedes borrar una BatchPriority si ninguna BatchQueue hace referencia a ella en un BatchPriorityName.

BatchJobConstraints

Las BatchJobConstraints son agrupaciones de restricciones que se pueden adjuntar a una BatchQueue. Las BatchJobConstraints no tienen espacio de nombres y se pueden aplicar a las BatchQueues en cualquier espacio de nombres. Cuando un BatchJob se envía a una BatchQueue, el BatchJob se valida según las restricciones. El BatchJob solo se admite en la cola si cumple con las restricciones.

Por ejemplo, si se configura una restricción para WallTime de 30 m, solo se permiten trabajos de menos de 30 m en la cola.

Es posible que el administrador quiera exigir que ciertas BatchQueues solo tengan determinados tipos de trabajos. Por ejemplo, una BatchQueue diseñada para una iteración rápida durante el desarrollo puede tener una prioridad alta, pero requiere que los trabajos tengan tiempos reales máximos más cortos y no usen muchas CPU.

Si una BatchQueue especifica una BatchJobConstraint, se aplicarán esos requisitos de forma predeterminada en cualquier trabajo en esa BatchQueue si no se especifica un valor para ellos. Si el trabajo especifica uno de esos requisitos con un valor incompatible, fallará durante el envío.

En los siguientes archivos .yaml, se muestra un ejemplo 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"]
    

En la siguiente tabla, se muestran los campos admitidos y los operadores disponibles para cada uno de esos valores:

Nombre del campo Operador Ejemplo
WallTime LessThan, GreaterThan, Equal, In, NotIn, Exists WallTime: 30 min, 1 h
Memoria LessThan, GreaterThan, Equal, In, NotIn, Exists Memoria: 128974848, 129e6, 129M y 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

En la siguiente tabla, se muestran los operadores y los requisitos de los valores para cada operador:

Operador Especificación de valores
LessThan, GreaterThan, Equal Requiere solo 1 valor.
Memoria Requiere solo 1 valor.
In, NotIn Requiere al menos 1 valor.
Ya existe. Requiere valores cero.

BatchBudgets

Una BatchQueue puede tener un batchBudgetName opcional que limite la cantidad de recursos que puede usar en un período determinado. Los presupuestos son aproximaciones útiles para configurar y evitar gastos excesivos en la CPU, la GPU y la memoria. BatchBudgets también te permite limitar el impacto de una BatchQueue de prioridad alta que consume todos los recursos disponibles.

BatchBudgets no puede dar cuenta de los recursos y las API fuera del clúster, como el tráfico de red, el almacenamiento de objetos o las API de terceros. Tampoco representan tu factura real. Si deseas usar un presupuesto, define un modelo de costos (o una hoja de precios) para cada recurso por hora. Como los trabajos de las BatchQueues usan esos recursos, su presupuesto se debita del importe total.

El siguiente comando default_budget.yaml muestra un presupuesto de ejemplo:

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
    

En este ejemplo, se limita la BatchQueue a un consumo de 100 unidades por día. El costo de cada recurso se encuentra en costModel a continuación. Una vez que se excede el presupuesto, los trabajos nuevos y en cola no podrán ejecutarse hasta que se actualice el período del presupuesto. También puedes aumentar el importe del período del presupuesto para permitir que los trabajos en cola se ejecuten antes de que ese período se actualice.

BatchBudgets usa un modelo de reserva. Por ejemplo, si 1 hora de CPU cuesta 1 unidad y un trabajo tiene un límite de tiempo de 10 horas, el programador solo permite que el trabajo se ejecute si al presupuesto le quedan al menos 10 unidades para este período. Cuando el trabajo se marca como listo, se reservan 10 unidades de presupuesto. Si el trabajo solo se ejecuta para 5 unidades de presupuesto y se completa, se reembolsan 5 unidades en el presupuesto. El uso de un modelo de reserva evita que el trabajo se quede sin presupuesto durante el procesamiento.

El siguiente comando default_costmodel.yaml muestra un ejemplo 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.
    

Borra recursos

Algunos tipos de recursos dependen de otros. Por ejemplo, BatchQueue usa BatchPriority. Batch realiza su mejor esfuerzo para evitar que se borre un recurso del que se depende. La primera línea de defensa es el controlador de admisión, que rechaza las eliminaciones de las dependencias en uso.

Debido a la naturaleza de Kubernetes, no siempre es posible detectar dependencias. En particular, puede existir una condición de carrera entre la eliminación de la dependencia y un uso nuevo de esta. Batch tiene un segundo mecanismo para manejar esos casos. Si esto ocurre, la dependencia se borra una vez que se detecta que el recurso ya no está en uso.

Administración de usuarios y accesos

Batch diferencia entre dos tipos de usuarios: los administradores, que configuran, gestionan y administran el clúster, y los profesionales, que envían BatchJobs al sistema.

Batch se rige por el principio de privilegio mínimo, es decir, otorga a los profesionales y a las VM que ejecutan sus trabajos solo el permiso y el acceso necesarios. Los administradores pueden otorgar más acceso a los usuarios, pero deben hacerlo de acuerdo con una política de seguridad bien definida.

La administración de usuarios de Batch en GKE consiste en un conjunto de RBAC de Kubernetes y un CRD de BatchUserContext para cada usuario. Batch proporciona una secuencia de comandos para configurar estos parámetros de configuración en un solo paso. Si deseas obtener más información, consulta Administra los usuarios de Batch en GKE.

De forma predeterminada, los profesionales no tienen acceso a los recursos de Batch en GKE. Batch proporciona herramientas para la administración de usuarios que admiten los siguientes casos prácticos:

  • Un usuario puede enviar trabajos por lotes y acceder al resultado del trabajo sin interactuar con el trabajo de otro usuario por error.
  • Como nivel de protección adicional, los usuarios de Batch en GKE pueden tener una separación de acceso a los datos de almacenamiento en el nivel de PersistentVolumeClaim y en el nivel de control de acceso de archivos de Unix.
  • Los administradores del sistema pueden configurar la política de seguridad de Kubernetes y la política de acceso a archivos de Unix para los usuarios. Batch adjuntará y validará estas políticas cuando un usuario envíe un trabajo.

Control de acceso según la función de usuarios de Batch en GKE

En la siguiente tabla, se describe el conjunto de RBAC para un usuario de Batch en GKE:

Recursos Alcances Verbos
BatchJobs Todo en un espacio de nombres Get, List, Watch, Create
Pods Todo en un espacio de nombres List
BatchQueue Todas las colas de lotes en el espacio de nombres Get, List
BatchPriority Todo en el clúster Get, List
BatchBudgets/BatchcostModel Todo en el clúster Get, List
PersistentVolumeClaim Solo los que puede usar este usuario en el espacio de nombres Get
Secrets Solo los que puede usar este usuario en el espacio de nombres Get

Una vez que se envía un trabajo, el creador puede finalizarlo. Los administradores de clústeres tienen permiso para borrar BatchJobs. Cuando se borra un BatchJob, también se borran los RBAC asociados al trabajo otorgados de forma dinámica.

Limitaciones en la versión Beta

  • La versión Beta de Batch solo admite trabajos de nodo único (VM). Por el momento, no se admiten los trabajos de MPI, de varios nodos o programados en conjunto.

  • Cuando se colocan pods en VM, GKE responde por la sobrecarga de sus propios agentes en VM. Por ejemplo, se considera que una VM de 4 CPU virtuales tiene una cantidad menor de CPU virtuales disponibles para trabajar (en general, algo como 3.8), por lo que no se colocará un trabajo que necesite 4 CPU virtuales en esa VM.

  • El modelo de costos solo admite un tipo de GPU.

  • El nombre de usuario, [NAME]@[PROJECT_NAME].iam.gserviceaccount.com, está limitado a 63 caracteres. Eso significa que NAME y [PROJECT_NAME] están limitados a 37 caracteres.

  • El campo runAsGroup en PodSecurityPolicy no es compatible con GKE.

  • Batch solo admite el volumen NFS a través de PersistentVolumeClaims.

  • El número máximo de envíos de trabajos simultáneos es de 10,000.

Referencia

BatchPriority v1beta1 kbatch.k8s.io

BatchPriority es el esquema de la API de batchpriorities.

Campos
metadata

Kubernetes meta/v1.ObjectMeta

Consulta la documentación de la API de Kubernetes para los campos del campo de metadatos.

spec

BatchPrioritySpec

status

BatchPriorityStatus

BatchPrioritySpec

Campos
Value

int32

Description

String

BatchJobConstraint v1beta1 kbatch.k8s.io

BatchJobConstraint es el esquema para la API de batchjobconstraints.

Campos
metadata

Kubernetes meta/v1.ObjectMeta

Consulta la documentación de la API de Kubernetes para los campos del campo de metadatos.

spec

BatchJobConstraintSpec

status

BatchJobConstraintStatus

BatchCostModel v1beta1 kbatch.k8s.io

BatchCostModel es el esquema de la API de batchcostmodels.

Campos
metadata

Kubernetes meta/v1.ObjectMeta

Consulta la documentación de la API de Kubernetes para los campos del campo de metadatos.

spec

BatchCostModelSpec

status

BatchCostModelStatus

BatchCostModelSpec v1beta1 kbatch.k8s.io

BatchCostModelSpec permite definir el costo de los recursos.

Campos
resources

ResourceCostList

Consulta la documentación de la API de Kubernetes para los campos del campo de metadatos.

ResourceName v1beta1 kbatch.k8s.io

ResourceName es el tipo de recurso.

Campos
ResourceCPU

Representa el recurso de la CPU.

ResourceMemory

Representa el recurso de la memoria.

ResourceGPU

Representa el recurso de la GPU.

BatchBudget v1beta1 kbatch.k8s.io

BatchBudget es el esquema para la API de batchbudgets.

Campos
metadata

Kubernetes meta/v1.ObjectMeta

Consulta la documentación de la API de Kubernetes para los campos del campo de metadatos.

spec

BatchBudgetSpec

status

BatchBudgetStatus

Define el estado observado de BatchBudget.

BatchBudgetSpec v1beta1 kbatch.k8s.io

BatchBudgetSpec define el estado deseado de BatchBudget.

Campos
batchCostModelName

String

Nombre del BatchCostModel que usa este presupuesto.

budgetStartTime

Kubernetes meta/v1.Time

Hora de inicio del primer período del presupuesto. Si no se la configura, se propaga como hora de creación del presupuesto.

budgetWindows

[]BudgetWindow

Un arreglo de períodos que definen un límite del importe del presupuesto para ese período. La BudgetWindows[i].Duration debe ser única dentro de BudgetWindows.

BatchBudgetStatus v1beta1 kbatch.k8s.io

BatchBudgetStatus define el estado observado de BatchBudget.

Campos
LastUpdated

String

La hora a la que se actualizó por última vez.

WindowStatusList

[]BudgetWindowStatus

(Opcional)

WindowStatusList contiene una entrada por cada período para transmitir el estado detallado. WindowStatusList [i].Start <= time.Now() debe conservarse.

BudgetWindow v1beta1 kbatch.k8s.io

BudgetWindow define el límite de importe del presupuesto dentro de ese período.

Campos
duration

Kubernetes meta/v1.Duration

Este campo especifica el tamaño del período. En este momento, solo se admiten días, por lo que los valores tendrán el sufijo “d” de días. En el futuro, se agregará la compatibilidad con cualquier unidad de duración, como hora, semana, etcétera.

amount

[]BudgetWindowStatus

(Opcional)

Este campo especifica el límite del presupuesto dentro de ese período.

BudgetWindowStatus v1beta1 kbatch.k8s.io

BudgetWindowStatus contiene información sobre el consumo de presupuesto para un período, ya sea del actual o de los anteriores.

Campos
duration

Kubernetes meta/v1.Duration

Este campo especifica el tamaño del período. En este momento, solo se admiten días, por lo que los valores tendrán el sufijo “d” de días. En el futuro, se agregará la compatibilidad con cualquier unidad de duración, como hora, semana, etcétera.

startTime

Kubernetes meta/v1.Time

Hora de inicio del período actual. Una vez que el período finaliza, se agrega al Historial y se crea un nuevo período actual.

amount

float64

Cantidad de presupuesto que se usó durante ese período.

windowHistory

[]BudgetWindowHistoryRecord

Por cada período completo de esa duración, en esta lista, se registra la cantidad de presupuesto que se usó en ese período. En el caso de la versión Alfa, conservamos 90 días del historial para los períodos diarios y 3 registros del historial para los períodos de 30 días.

BudgetWindowHistoryRecord v1beta1 kbatch.k8s.io

BudgetWindowHistoryRecord rastrea la cantidad de presupuesto que se usó durante ese período.

Campos
windowStartTime

Kubernetes meta/v1.Time

Hora de inicio del período.

windowEndTime

Kubernetes meta/v1.Time

Hora de finalización del período.

amount

float64

Cantidad de presupuesto que se usó durante ese período.

BatchQueue v1beta1 kbatch.k8s.io

BatchQueue es el esquema de la API de batchqueues.

Campos
metadata

Kubernetes meta/v1.ObjectMeta

Consulta la documentación de la API de Kubernetes para los campos del campo de metadatos.

spec

BatchQueueSpec

status

BatchQueueStatus

BatchQueueSpec v1beta1 kbatch.k8s.io

BatchQueueSpec define el estado deseado de BatchQueue.

Campos
BatchPriorityName

String

El nombre del recurso de BatchPriority asociado a esa BatchQueue. Los trabajos en esta BatchQueue se priorizarán para la programación en función de la BatchPriority que se establece aquí.

PauseAdmission

bool

(Opcional)

Si se configura como verdadero, BatchQueue no aceptará trabajos nuevos. Esto no afecta la programación de trabajos.

PauseScheduling

bool

(Opcional)

Si se configura como verdadero, BatchQueue no programará trabajos. Esto no afecta a la admisión de trabajos.

BatchBudgetName

String

El nombre del recurso de BatchBudget asociado a esa BatchQueue.

ConstraintNames

[]string

Contiene los nombres de las BatchJobConstraints que se aplicarán a la cola.

BatchJob v1beta1 kbatch.k8s.io

BatchJob es el esquema para la API de batchjobs.

Campos
metadata

Kubernetes meta/v1.ObjectMeta

Consulta la documentación de la API de Kubernetes para los campos del campo de metadatos.

spec

BatchJobSpec

BatchJobSpec define el estado deseado de BatchJob.

status

BatchJobStatus

BatchJobStatus define el estado observado de BatchJob.

BatchJob v1beta1 kbatch.k8s.io

BatchJob es el esquema para la API de batchjobs.

Campos
metadata

Kubernetes meta/v1.ObjectMeta

Consulta la documentación de la API de Kubernetes para los campos del campo de metadatos.

spec

BatchJobSpec

status

BatchJobStatus

Estado del trabajo. Este campo debe ser un puntero, opcional y omitempty./p>

BatchJobSpec v1beta1 kbatch.k8s.io

Campos
TaskGroups

[]BatchTaskGroupSpec

Especificación de grupo de tareas.

BatchQueueName

string

El nombre de la BatchQueue en la que se ejecutará ese BatchJob.

Dependencies

[]BatchJobDependency

(Opcional)

Este campo define varias dependencias de BatchJob. La lógica entre cada dependencia es la operación “OR”. Por ejemplo: Dependencies[0] Dependencies[1]. La lógica entre Dependencies[0] y Dependencies[1] es: Dependencies[0] || Dependencies[1]. Por el momento, solo admitimos una Dependency.

batchQueueName

string

El nombre de la BatchQueue en la que se ejecutará ese BatchJob.

UserCommand

string

Opcional

UserCommand de BatchJob. El valor predeterminado es una string vacía. Si este campo está vacío, no hay comando del usuario final. Si se establece en “Finalizar” mientras BatchJob se está ejecutando, finaliza el BatchJob.

taskGroupSpec v1beta1 kbatch.k8s.io

Campos
Name

string

Nombre de este grupo de tareas.

IndexSpec

BatchIndexSpec

Especifica el recuento de tareas para un trabajo de arreglos. El valor máximo permitido de taskCount es 1,000.

Template

Kubernetes pod template spec

Nombre de este grupo de tareas.

MaxWallTime

string

Tiempo máximo de ejecución por tarea.

RetryLimit

int32

(Opcional)

RetryLimit define el límite de reintentos por tarea. Los tiempos de ejecución de la tarea serán RetryLimit + 1. Si no se especifica, el valor predeterminado es 0.

BatchIndexSpec v1beta1 kbatch.k8s.io

Campos
TaskCount

string

Cantidad de tareas.

BatchJobStatus v1beta1 kbatch.k8s.io

BatchJobStatus define el estado observado del BatchJob.

Campos
Phase

BatchJobPhase

(Opcional)

La fase actual de este trabajo.

BatchPriority

BatchPriority

(Opcional)

Una copia del recurso BatchPriority asociado a ese BatchJob (según el batchPriorityName que se declaró en la BatchQueue asociada a ese BatchJob).

BudgetConsumed

float64

(Opcional)

El presupuesto agregado que se consumió para el trabajo, lo que incluye todas sus tareas.

Conditions

[]BatchJobCondition

(Opcional)

Las últimas observaciones disponibles del estado actual del batchjob.

SubmittedBy

string

(Opcional)

El usuario que envió el trabajo.

GroupStatus

string

(Opcional)

Estado por grupo de tareas.

Próximos pasos