Support for Jobs emulation

Summary

Kubernetes Jobs are vital for handling one-off tasks, periodic jobs, and other similar scenarios where a task needs to run to completion before being considered successful.

Implementing support for Kubernetes Jobs will involve parsing and translating these API calls into Docker instructions, similar to how other Kubernetes resources are handled by k2d.

The base implementation could be spawning containers that will immediately reach Running state, and based on the exit code (EC), can be marked as Completed (EC == 0) or Failed (EC != 0).

If you are open to considering this feature request, I would be happy to provide further input or assist in any way that I can. Please let me know if you have any questions or if there's anything I can do to support the development of this enhancement.

Goals

Implementation of translation layer from Kubernetes jobs.batch to Docker containers;
Support for Create, Delete, Get, List and Patch operations;

Proposal

Example

The following is an example Job config (source: kubernetes.io: Running an example job). It computes π to 2000 places and prints it out.

# job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
        - name: pi
          image: perl:5.34.0
          command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

Using the kubectl create -f job.yaml, I expect the following actions to occur:

Job Creation: When you execute kubectl create -f job.yaml, Kubernetes will receive this YAML configuration and create a Job resource based on the specifications defined in the YAML file.
Job Scheduling: Kubernetes will attempt to schedule the Job for execution. This involves finding an appropriate node in the cluster where the Job's pod can run. The Job pod will consist of a single container defined in the containers section of the Job configuration.
Pod Creation: Once a suitable node is found, Kubernetes will create a pod based on the template specified in the Job configuration. In this case, it's a single pod with a container named "pi," running the "perl:5.34.0" image.
Container Initialization: The container within the pod is started. It will execute the command specified in the command field of the container definition. In this example, it runs a Perl script that calculates π to 2000 decimal places using the Perl bpi module and prints the result.
Pod Execution: The container will run until it completes the assigned task. In this example, it computes π to 2000 decimal places and prints it. Once the command finishes, the container will terminate.
Job Status Tracking: Kubernetes continuously monitors the status of the pod and the container within the pod. If the container exits with a status code of 0 (indicating success), Kubernetes marks the pod as "Succeeded." If the container exits with a non-zero status code (indicating failure), Kubernetes marks the pod as "Failed."
Job Completion: The Job itself will be marked as "Completed" if all its pods complete successfully (i.e., with an exit code of 0) or "Failed" if any of its pods fail (i.e., exit with a non-zero code). The backoffLimit field in the Job configuration specifies the number of retries allowed for failed pods. In this example, it's set to 4, so Kubernetes will retry running the Job up to four times if it fails.
Job Cleanup: Once the Job is completed (either successfully or after reaching the backoffLimit), Kubernetes cleans up any associated resources, such as pods, unless you specify otherwise.

Solution

From the k2d standpoint, the best way to treat the following example would be starting new container for each of the containers in the template, similarly to the deployment.apps (ref. docs.k2d.io).

The inspect object of the Job container would look like this (truncated to the important fields only):

[
  {
    "Id": "DATA+OMITTED",
    "Path": "perl",
    "Args": ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"],
    "State": {
      "Status": "running",
      "Running": true,
      "Paused": false,
      "Restarting": false,
      "OOMKilled": false,
      "Dead": false,
      "Pid": 41222,
      "ExitCode": 0,
      "Error": "",
      "StartedAt": "2023-09-04T15:52:43.601028251Z",
      "FinishedAt": "0001-01-01T00:00:00Z"
    },
    "Config": {
      "Cmd": ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"],
      "Image": "perl:5.34.0",
      "Labels": {
        "namespace.k2d.io/name": "default",
        "networking.k2d.io/network-name": "k2d-default",
        "pod.k2d.io/last-applied-configuration": "DATA+OMITTED",
        "workload.k2d.io/last-applied-configuration": "DATA+OMITTED",
        "workload.k2d.io/name": "pi",
        "workload.k2d.io/type": "job"
      }
    }
  }
]

Mappings

Each Pod in Kubernetes Jobs can have various statuses that indicate the progress and outcome of the job's execution, and based on them we can mark the job status. Here is a table with Possible mappings

Job Status	Container State	Container Exit Code	Remarks	Description
`Active`	`Running`	-	-	It indicates that the Job is currently running or actively being processed. There might be one or more pods associated with the Job in the "Running" state.
`Succeeded`	`Exited`	each pod `EC == 0`	-	It signifies that all the pods created by the Job have completed successfully. In other words, all the pods associated with the Job have exited with a status code of 0. The Job itself is considered successfully completed.
`Failed`	`Exited`	at least one pod`EC != 0`	-	It indicates that at least one pod created by the Job has failed. A pod is marked as "Failed" when its main container exits with a non-zero status code. The Job itself is considered to have failed if any of its pods fail.
`Completed`	`Exited`	-	-	It signifies that the Job has completed its execution, but it does not provide information about whether the execution was successful or not.
`Pending`	`Created`	-	Should this be supported?	It means that the Job has been created, but no pods have been scheduled and started yet. Kubernetes is still in the process of scheduling the Job for execution.
`Unknown`	?	-	-	It is used when there is an issue with retrieving the Job's status. This might occur if there are problems with communication between the Kubernetes control plane and the cluster nodes.
`Expiered`	Any state		execution time exceeds `spec.activeDeadlineSeconds`	This status is used when a Job has reached its active deadline or has been terminated due to exceeding its specified `activeDeadlineSeconds` field.

Use-case

Kubernetes Jobs are primarily designed for running one-off or batch tasks in a Kubernetes cluster. They are a useful resource for managing short-lived and parallelizable workloads. Here are some common use cases for Kubernetes Jobs:

Data Processing and ETL (Extract, Transform, Load):
- Running data processing jobs, such as log analysis, data transformation, or data migration tasks.
- Executing ETL pipelines to clean, enrich, and transfer data between different systems.
Cron Jobs:
- Scheduling periodic tasks or batch jobs at specific intervals using the Kubernetes CronJob resource. CronJobs are built on top of Jobs and are suitable for tasks like periodic backups, data synchronization, or report generation.
Database Migrations:
- Performing database schema updates or migrations as part of application deployments.
- Running scripts to apply schema changes, seed data, or perform maintenance tasks on databases.
Periodic Cleanup:
- Automating the cleanup of temporary files, log rotation, or purging outdated data.
- Managing resources by periodically deleting or archiving unused objects in a cluster.
Testing and CI/CD Pipelines:
- Running tests, build jobs, or integration tests as part of a continuous integration and continuous deployment (CI/CD) pipeline.
- Isolating test environments and executing tests in parallel.
Batch Processing:
- Handling parallel batch processing tasks where each unit of work is independent and can be processed concurrently.
- Examples include processing invoices, generating reports, or transcoding media files.
Backup and Restore:
- Automating backup and restore procedures for applications, databases, or configuration files.
- Ensuring data resilience and disaster recovery.
Resource Scaling and Parallelization:
- Scaling applications horizontally by launching multiple parallel instances to handle increased workloads.
- Parallelizing tasks to complete them faster, such as image or video processing.
Job Queue Workers:
- Creating workers to process tasks from a job queue or message queue system like RabbitMQ or Apache Kafka.
- Scaling the number of workers based on queue backlog.
Scientific and Computational Workloads:
- Running scientific simulations, calculations, or numerical analysis.
- Utilizing Kubernetes clusters for high-performance computing (HPC) tasks.
Backup and Restore:
- Automating backup and restore procedures for applications, databases, or configuration files.
- Ensuring data resilience and disaster recovery.
Ad-Hoc Administrative Tasks:
- Executing one-time administrative tasks or system maintenance operations on Kubernetes nodes or applications.

Kubernetes Jobs provide a reliable and declarative way to manage these tasks within a Kubernetes cluster. They ensure that tasks are executed to completion, handle retries, and provide a framework for tracking job status, which is particularly useful for monitoring and managing batch workloads.

Sep 02 '23 19:09 shanduur

Hi @shanduur, thanks for the feat request.. Adding jobs would be excellent... we would need to use cron or something similar to schedule the job.

If you can share your thoughts, and/or contribute a PR that would be awesome.. we will look to include in the release version, but unlikely it would make it in time for the BETA, which we are earmarking to have out in 2 weeks.

Sep 04 '23 08:09 ncresswell

Hey @shanduur, I see that you have already opened a PR, that's great!

Before we actually go further into review, I'd like you to give us more information about the implementation you have in mind. Examples of translation between Kubernetes to Docker as well as usage examples (example manifest, kubectl commands) would be great to see.

Sep 04 '23 14:09 deviantony

@deviantony I updated the description of the issue. I thought it will be little bit easier to implement, but got some hiccups. Will be spending more time on the PR in the upcoming days, probably.

Sep 04 '23 18:09 shanduur

@shanduur amazing contribution, I'll review it soon !

Sep 04 '23 18:09 deviantony

Support for Jobs emulation

Support for Jobs emulation

Table of Contents

Summary

Goals

Proposal

Example

Solution

Mappings

Use-case