Instale el SchedulerX agent en Kubernetes para programar Pods y Jobs nativos. SchedulerX ofrece monitoreo de estado, alertas, recopilación de registros y diagnósticos para sus jobs.
Funcionamiento
El siguiente diagrama muestra cómo SchedulerX programa un job de Kubernetes:

La siguiente tabla compara los jobs de Kubernetes con los jobs de script.
|
Escenario |
Job de script |
Job de Kubernetes |
|
Ejecución poco frecuente con alto consumo de recursos. |
No recomendado. Crear un proceso secundario para cada ejecución consume recursos en la máquina del agente y puede sobrecargar el sistema. |
Recomendado. Kubernetes utiliza su estrategia de balanceo de carga para iniciar un nuevo Pod en cada ejecución, lo que garantiza una alta estabilidad. |
|
Ejecución frecuente con bajo consumo de recursos. |
Recomendado. La creación de un proceso secundario es rápida y eficiente en el uso de recursos. |
No recomendado. Descargar una imagen e iniciar un Pod para cada ejecución resulta lento. Las llamadas frecuentes al servidor API para programar Pods o Jobs pueden provocar limitaciones de tasa. |
|
Cómo compilar dependencias. |
Despliegue manualmente las dependencias en instancias ECS con anticipación. |
Compile las dependencias en una imagen base. Debe recompilar la imagen base si cambian las dependencias. |
Requisitos previos
Conéctese a SchedulerX. Para obtener más información, consulte Deploy SchedulerX in a Kubernetes cluster.
Crear un job de Kubernetes
Script de shell
Para ejecutar un script de shell en un Pod sin compilar su propia imagen, cree un job de Kubernetes en la página Tasks y seleccione Shell-Script como tipo de recurso. La imagen predeterminada es BusyBox, pero puede reemplazarla por la suya.
Configuración de ejemplo: Establezca Task type en K8s y resource type en Shell-Script. La Image predeterminada es BusyBox. Introduzca el contenido de su script de shell, como echo hello schedulerx, en el editor de scripts.
Haga clic en Run once. Un Pod llamado schedulerx-shell-{JobId} se inicia en el clúster de Kubernetes.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
schedulerx-shell-xxx 1/1 Running 0 xxx
En la página Task Management de la consola de SchedulerX, puede consultar el historial de ejecución y los registros del Pod. El área de salida de registros muestra el resultado del script, como hello schedulerx, junto con el tiempo de ejecución y el estado.
Script de Python
Para ejecutar un script de Python en un Pod sin compilar su propia imagen, cree un job de Kubernetes en la página Tasks y seleccione Python-Script como tipo de recurso. La imagen predeterminada es python, pero puede reemplazarla por la suya.
Configuración de ejemplo: Establezca Task type en K8s y resource type en Python-Script. La Image predeterminada es python. Introduzca el contenido de su script de Python, como print('hello schedulerx'), en el editor de scripts.
Haga clic en Run once. Un Pod llamado schedulerx-python-{JobId} se inicia en el clúster de Kubernetes.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
schedulerx-python-xxx 1/1 Running 0 xxx
En la página Task Management de la consola de SchedulerX, puede consultar el historial de ejecución y los registros del Pod. El procedimiento es el mismo que para los scripts de shell. El área de salida de registros muestra el resultado del script.
Script de PHP
Para ejecutar un script de PHP en un Pod sin compilar su propia imagen, cree un job de Kubernetes en la página Tasks y seleccione Php-Script como tipo de recurso. La imagen predeterminada es php:7.4-cli, pero puede reemplazarla por la suya.
Configuración de ejemplo: Establezca Task type en K8s y resource type en Php-Script. La Image predeterminada es php:7.4-cli. Introduzca el contenido de su script de PHP en el editor de scripts.
Haga clic en Run once. Un Pod llamado schedulerx-php-{JobId} se inicia en el clúster de Kubernetes.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
schedulerx-php-xxx 1/1 Running 0 xxx
En la página Task Management de la consola de SchedulerX, puede consultar el historial de ejecución y los registros del Pod. El procedimiento es el mismo que para los scripts de shell. El área de salida de registros muestra el resultado del script.
Script de Node.js
Para ejecutar un script de Node.js en un Pod sin compilar su propia imagen, cree un job de Kubernetes en la página Tasks y seleccione Node.js-Script como tipo de recurso. La imagen predeterminada es node:16, pero puede reemplazarla por la suya.
Configuración de ejemplo: Establezca Task type en K8s y resource type en Node.js-Script. La Image predeterminada es node:16. Introduzca el contenido de su script de Node.js, como console.log('hello schedulerx'), en el editor de scripts.
Haga clic en Run once. Un Pod llamado schedulerx-node-{JobId} se inicia en el clúster de Kubernetes.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
schedulerx-node-xxx 1/1 Running 0 xxx
En la página Task Management de la consola de SchedulerX, puede consultar el historial de ejecución y los registros del Pod. El procedimiento es el mismo que para los scripts de shell. El área de salida de registros muestra el resultado del script.
Job-YAML
También puede usar SchedulerX para ejecutar un Job nativo de Kubernetes. Establezca el tipo de tarea en K8s y el tipo de recurso en Job-YAML.
Configuración de ejemplo: Establezca Task type en K8s y resource type en Job-YAML. Introduzca la definición estándar del Job de Kubernetes en el editor YAML, incluidos campos como apiVersion, kind, metadata y spec.
Haga clic en Run once. El Job y su Pod asociado se inician en el clúster de Kubernetes.
$ kubectl get jobs
NAME COMPLETIONS DURATION AGE
schedulerx-xxx 1/1 xxx xxx
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
schedulerx-xxx 0/1 Completed 0 xxx
En la página Task Management de la consola de SchedulerX, puede consultar el historial de ejecución y los registros del Pod. El área de salida de registros muestra el resultado del Job, el tiempo de ejecución y el estado.
Al ejecutar un Job de Kubernetes con SchedulerX, se recomienda no utilizar CronJob. En su lugar, configure la programación en SchedulerX para garantizar que se recopilen el historial de ejecución y los registros de cada Pod.
Pod-YAML
También puede usar SchedulerX para ejecutar un Pod nativo de Kubernetes. Establezca el tipo de tarea en K8s y el tipo de recurso en Pod-YAML.
Configuración de ejemplo: Establezca Task type en K8s y resource type en Pod-YAML. Introduzca la definición estándar del Pod de Kubernetes en el editor YAML, incluidos campos como apiVersion, kind, metadata y spec.
Haga clic en Run once. El Pod se inicia en el clúster de Kubernetes.
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
schedulerx-xxx 1/1 Running 0 xxx
En la página Task Management de la consola de SchedulerX, puede consultar el historial de ejecución y los registros del Pod. El área de salida de registros muestra el resultado del Pod, el tiempo de ejecución y el estado.
Cuando utilice SchedulerX para ejecutar un Pod de Kubernetes, se recomienda no ejecutar Pods de larga duración, como los destinados a aplicaciones web que nunca finalizan. Debe establecer la directiva de reinicio en Never. De lo contrario, el Pod se reiniciará continuamente.
Parámetros de job desde variables de entorno
SchedulerX inyecta los parámetros del job como variables de entorno. Los scripts, Pods y Jobs pueden leer estos parámetros directamente del entorno.
Esta función requiere la versión 1.10.14 o posterior del agente de SchedulerX.
|
Parámetro |
Descripción |
|
SCHEDULERX_JOB_NAME |
Nombre del job. |
|
SCHEDULERX_SCHEDULE_TIMESTAMP |
Marca de tiempo de programación del job. |
|
SCHEDULERX_DATA_TIMESTAMP |
Marca de tiempo de datos del job. |
|
SCHEDULERX_WORKFLOW_INSTANCE_ID |
ID de la instancia del flujo de trabajo, si el job forma parte de uno. |
|
SCHEDULERX_JOB_PARAMETERS |
Parámetros del job. |
|
SCHEDULERX_INSTANCE_PARAMETERS |
Parámetros de la instancia del job. |
|
SCHEDULERX_JOB_SHARDING_PARAMETER |
Parámetros de fragmentación, si el job está fragmentado. |
El siguiente ejemplo recupera un parámetro de job de SchedulerX:
Ejemplo: Introduzca un valor en el campo Job Parameters dentro de la configuración del job. Posteriormente, en su script, puede leer la variable de entorno SCHEDULERX_JOB_PARAMETERS para acceder a este valor. Por ejemplo, un script de shell puede usar echo $SCHEDULERX_JOB_PARAMETERS para imprimir el parámetro.
Ventajas
Programar un Job de Kubernetes con SchedulerX ofrece las siguientes ventajas frente a los Jobs nativos de Kubernetes:
Edición de scripts en línea
Los Jobs de Kubernetes se utilizan comúnmente para tareas de procesamiento de datos u operaciones implementadas mediante scripts. De forma nativa, debe empaquetar cada script en una imagen y configurar el comando en un archivo YAML; además, debe recompilar y redesplegar la imagen ante cualquier cambio. Por ejemplo:
apiVersion: batch/v1
kind: Job
metadata:
name: hello
spec:
template:
spec:
containers:
- name: hello
image: busybox
command: ["sh", "/root/hello.sh"]
restartPolicy: Never
backoffLimit: 4
SchedulerX elimina la necesidad de compilar imágenes o escribir YAML para los scripts. Puede editar scripts de Shell, Python, PHP y Node.js directamente en la consola, y el sistema los ejecuta automáticamente en un Pod. Las actualizaciones surten efecto en la siguiente ejecución programada.
Por ejemplo:
En la página de edición de jobs de la consola de SchedulerX, puede escribir y modificar el contenido del script directamente en el script editor. Al finalizar, haga clic en Save. La versión más reciente del script se ejecutará automáticamente en la siguiente hora programada.
Orquestación visual de jobs
En el ecosistema de Kubernetes, Argo es una solución popular para la orquestación de flujos de trabajo. Por ejemplo:
# The following workflow executes a diamond workflow
#
# A
# / \
# B C
# \ /
# D
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: dag-diamond-
spec:
entrypoint: diamond
templates:
- name: diamond
dag:
tasks:
- name: A
template: echo
arguments:
parameters: [{name: message, value: A}]
- name: B
depends: "A"
template: echo
arguments:
parameters: [{name: message, value: B}]
- name: C
depends: "A"
template: echo
arguments:
parameters: [{name: message, value: C}]
- name: D
depends: "B && C"
template: echo
arguments:
parameters: [{name: message, value: D}]
- name: echo
inputs:
parameters:
- name: message
container:
image: alpine:3.7
command: [echo, "{{inputs.parameters.message}}"]
SchedulerX permite orquestar visualmente Jobs de Kubernetes mediante una interfaz de arrastrar y soltar.
En comparación con Argo, SchedulerX proporciona un gráfico visual del flujo de trabajo durante la ejecución que rastrea el progreso del job, lo que facilita la identificación de cuellos de botella o fallos.
En la vista de instancias del flujo de trabajo, cada nodo de tarea tiene un código de colores según su estado (por ejemplo, verde para éxito y rojo para fallo), lo que le permite localizar visualmente el error.
Monitoreo y alertas
SchedulerX incluye monitoreo y alertas integrados para Pods y Jobs.
Canales de alerta compatibles: SMS, llamada telefónica, correo electrónico y webhook (para DingTalk, WeCom y Lark).
Directivas de alerta compatibles: alerta por fallo y alerta por tiempo de espera de ejecución.
Servicio de registros
SchedulerX recopila automáticamente los registros de la ejecución del Pod sin requerir un servicio de registros independiente. Si un Pod falla, puede consultar el motivo del fallo en la consola de SchedulerX para solucionar problemas rápidamente.
Los detalles de la instancia de la tarea incluyen registros completos de ejecución del Pod con seguimientos de pila y motivos de fallo.
Panel de monitoreo
SchedulerX proporciona un panel de monitoreo de jobs integrado, lo que elimina la necesidad de configurar Prometheus o un servicio similar.
El panel muestra métricas clave como recuentos de ejecución de jobs, tasas de éxito y fallo, y tendencias de duración de ejecución.
Despliegue mixto de jobs
SchedulerX admite tipos de jobs tanto de Java como de Kubernetes para despliegues mixtos. Utilice invocaciones de métodos en proceso para jobs en línea sensibles a la latencia, como el procesamiento de pedidos, y ejecute jobs sin conexión que consumen muchos recursos, como exportaciones de informes, como scripts en Pods separados.