Skip to main content

Google Kubernetes Engine Jobs

Disclaimer​

Your use of this download is governed by Stonebranch's Terms of Use.

Version Information​

Template Name

Extension Name

Version

Status

Google Kubernetes Engine Jobs

ue-gke-jobs

2 (Current 2.1.0)

Fixes and new Features are introduced.

Refer to Changelog for version history information.

Overview​

Google Kubernetes Engine (GKE) is a service for deploying, managing, and scaling Kubernetes containers on Google Cloud. Among other capabilities, GKE supports Jobs and CronJobs for task execution. Jobs are used for one-time tasks that run to completion, such as batch processing, while CronJobs enable scheduled, recurring task execution. To deploy a Job or CronJob, a Kubernetes resource definition is used. This file is typically defined inside of a YAML or JSON file and specifies the task details, container image, and execution configuration. Once applied to a GKE cluster, the Job runs to completion and terminates automatically, while CronJobs create new Job instances according to their defined schedule.

This integration provides the capability to define and deploy GKE Jobs and CronJobs on a specified cluster or delete them from a namespace.

Key Features​

Feature

Description

Deploy Resources

Deploy Job and CronJob resources, either declaratively or imperatively, from local YAML or JSON files, remote URLs or UAC scripts.

Create Jobs from Cronjobs

Create one-off Job resources based on existing Cronjob definitions in the cluster.

Delete Resources

Delete Job and CronJob resources via the delete action or manually through a Dynamic Command. Job resources can also be set to be deleted automatically after completion.

Pod Information Streaming

Live stream real-time updates about Kubernetes pods as they are created, modified, or terminated.

Automatic or Manual Container Information Retrieval

Option to automatically or manually retrieve information, including logs, for all containers pertaining to a specific job.

Requirements​

This integration requires a Universal Agent and a Python runtime to execute the Universal Task.

Area

Details

Python Version

Requires Python 3.11, tested with Python 3.11.8.

Universal Agent Compatibility

  • Compatible with Universal Agent for Windows x64 and version >= 7.6.0.0.
  • Compatible with Universal Agent for Linux and version >= 7.6.0.0.

Universal Controller Compatibility

Universal Controller Version >= 7.6.0.0.

Network and Connectivity

Network Connectivity towards Google Cloud Authentication Endpoints and Google Kubernetes Engine is required.

Google Kubernetes Engine

Tested with GKE 1.30.9-gke.1009000. It should be compatible with later versions as long as backwards compatibility is guaranteed on the API level.

Supported Actions​

There are six Top-Level actions controlled by the Action Field:

  • Apply a Job definition directly to the cluster
  • Apply a CronJob to schedule recurring tasks
  • Create a new Job using a provided specification
  • Create a one-time Job from an existing CronJob definition
  • Create a new CronJob for scheduled task execution
  • Delete a Job or CronJob

Additional options and post-action capabilities vary depending on the chosen Action.

Action Output​

The EXTENSION Output provides the following information:

  • "exit_code", "status_description": General info regarding the Task execution. For more information, refer to the exit code table.
  • "invocation.fields": The task configuration used for this Task execution.
  • "result.resource_specification": Specification of deployed Job or CronJob, along with the name and namespace it has been deployed on. Applicable for all Actions except "Delete Resource".
  • "result.containers": Information relating to containers, as well as container logs pertaining to execution of deployed Job. Logs are returned for all generated pods, even if they have been restarted. Applicable if Action is set to "Apply Job", "Create Job", or "Create Job from CronJob".
  • "result.errors": List of errors that might have occurred during execution.

Examples:

Successful Execution of "Create Job" Action, with all Extension Output options and Wait for Success or Failure is selected
{
  "exit_code": 0,
  "status_description": "Job created successfully.",
  "invocation": {
    "extension": "ue-gke-jobs",
    "version": "2.1.0",
    "fields": { ... }
  },
  "result": {
    "containers": [
      {
        "pod_name": "pi-json-name-wxx5r",
        "container_name": "pi",
        "container_log": "3.141592653589793",
        "exit_code": "0",
        "restart_count": "0"
      },
      {
        "pod_name": "pi-json-name-wxx5r",
        "container_name": "hello-sbaro",
        "container_log": "Hello SB Team\n",
        "exit_code": "0",
        "restart_count": "0"
      }
    ],
    "resource_specification": {
      "name": "pi-json-name",
      "namespace": "default",
      "active_deadline_seconds": 1800,
      "backoff_limit": 6,
      "completions": 1,
      "parallelism": 1,
      "pod_failure_policy": null,
      "pod_replacement_policy": "TerminatingOrFailed",
      "success_policy": null,
      "ttl_seconds_after_finished": 3600,
      "suspend": false
    }
  }
}
Failed Execution
{
  "exit_code": 21,
  "status_description": "Resource Naming Error: A job with the name pi-	json-name already exists in the namespace default",
  "invocation": {
  "extension": "ue-gke-jobs",
  "version": "2.1.0",
  "fields": { ... }
  },
  "result": {
    "errors": [
    "Resource Naming Error: A job with the name pi-json-name already exists in the namespace default"
    ]
  }
}

Configuration Examples​

Example: Apply a Job stored as a UAC Script​

Apply a Job to a specific GKE cluster, authenticating with a Service Account Key File, with the Resource Definition provided as a UAC script. The EXTENSION Output includes detailed information about the Job specification.

Example: Apply a CronJob stored as a Local File​

Apply a CronJob to a specific GKE cluster, authenticating with a Service Account Key File, with the Resource Definition provided as a Local File. Since the namespace is not specified in the resource definition file, the Namespace field input value will be used to determine where the CronJob will be applied.

Deploy a Job to a specific GKE cluster, authenticating with a Service Account Key File, with the Resource Definition provided as a HTTP Link. The Job's execution is monitored until completion for up to 1500 seconds, with any information related to the pods tied to the Job printed on STDOUT. If the Job executes successfully, it will be deleted from the designated namespace. Once the Job completes, the container logs and are printed on STDOUT. The EXTENSION Output includes detailed information about the Job specification and the containers created to complete it.

Example: Create a Job from an existing CronJob and wait for Job completion​

Deploy a Job to a specific GKE cluster, authenticating with a Service Account Key File, using the selected CronJob. The Job's execution is monitored until completion for up to 500 seconds, retrieving the Container Logs and Information if the Job fails. Once the Job completes, it will be deleted from the designated namespace.

Example: Create a CronJob stored as a UAC script using Impersonation​

Deploy a CronJob to a specific GKE cluster, authenticating with a Service Account Key File using Impersonation, with the Resource Definition provided as a UAC Script. The EXTENSION Output includes detailed information about the CronJob specification.

Example: Delete Resource​

Delete Resource of Resource Kind "Job" on the GKE cluster, retrieving the Job name using the Dynamic Choice field from specific namespace.

Input Fields​

Name

Type

Description

Version Information

Action

Choice

The action performed upon Task execution. The following options are available.

  • Apply Job (default)
  • Apply CronJob
  • Create Job
  • Create Job from CronJob
  • Create CronJob
  • Delete Resource

Introduced in 1.0.0

Authentication Method

Choice

The way the Google Cloud account will be verified. The following option is available.

  • Service Account Key

Introduced in 1.0.0

Service Account Key

Credential

The UAC Credential containing the Google Cloud Service Account Key to be used for authentication. The contents of the Service Account Key should be input on the Token field of a Resolvable UAC Credential.

Only available if Authentication Method is set to "Service Account Key".

Introduced in 1.0.0

Impersonate Service Account

Checkbox

Specifies whether a different Service Account should be impersonated.

Introduced in 1.0.0

Target Service Account

Text

The Service Account to impersonate. IAM roles required for creating short-lived tokens must be configured beforehand.

Only available if Impersonate Service Account is selected.

Introduced in 1.0.0

Cluster

Dynamic Choice

The Cluster to deploy or delete the resource on.

Introduced in 1.0.0

Namespace

Text

The namespace in which resources are deployed or deleted. In the case of resource deployment, this field is used only as a fallback in case a 'namespace' value is not specified inside of the Resource Definition.

Introduced in 1.0.0

Resource Definition Source

Choice

Specifies how to retrieve the definition of the resource to be deployed. The content of the file should be in YAML or JSON format and should contain only one resource definition. The following options are available.

  • UAC Script
  • Local File
  • HTTP Link

Only available if Action is set to "Apply Job", "Apply CronJob", "Create Job", or "Create CronJob".

Introduced in 1.0.0

Resource Definition Script

Script

UAC Script containing the definition of the resource to be deployed.

Only available if Resource Definition Source is set to "UAC Script".

Introduced in 1.0.0

Resource Definition File Path

Text

Local path to the resource definition file.

Only available if Resource Definition Source is set to "Local File".

Introduced in 1.0.0

Resource Definition Link

Text

HTTP link to file to use as resource definition. If authentication is required to retrieve the file, it should be part of the link provided. Environment variables in the URL are resolved; The GIT_TOKEN environmental variable, if set, is used as a Bearer token for authorization.

Only available if Resource Definition Source is set to "HTTP Link".

Introduced in 1.0.0

CronJob to Use

Dynamic Choice

The CronJob to use when creating a Job from CronJob.

Available and required if Action is set to "Create Job from CronJob".

Introduced in 2.0.0

New Job Name

Text

The name that the created Job should have.

Available and required if Action is set to "Create Job from CronJob"

Introduced in 2.0.0

Resource Kind

Choice

The kind of resource to be deleted. The following options are available.

  • Job (default)
  • CronJob

Available and required if Action is set to "Delete Resource".

Introduced in 2.0.0

Resource Name

Dynamic Choice

The name of the resource to be deleted.

Only available if Action is set to "Delete Resource".

Introduced in 1.0.0

Wait for Success or Failure

Checkbox

If selected, makes the Task Instance wait until the job had been completed.

Available if Action is set to "Apply Job", "Create Job", or "Create Job from CronJob".

Note: When applying to an existing Job resource, monitoring functionality is disabled by default.

Introduced in 1.0.0

Delete Job Options

Choice

Specifies the conditions under which the deployed Job should be deleted. The following options are available.

  • Do not Delete Job
  • Delete Job on Successful Execution (default)
  • Delete Job Regardless of Execution Status

Available if Action is set to "Apply Job", "Create Job", or "Create Job from CronJob" and Wait for Success or Failure is selected.

Introduced in 1.0.0

Timeout Seconds

Integer

The maximum number of seconds to monitor for Job completion. Leave empty or set to 0 to monitor indefinitely.

Available if Action is set to "Apply Job", "Create Job", or "Create Job from CronJob" and Wait for Success or Failure is selected.

Introduced in 1.0.0

Retrieve Container Information Only on Failure

Checkbox

Specifies whether container information is only retrieved when the Job fails. This option does nothing if "Include Container Logs" or "Include Container Information" options are not requested as part of the Standard Output Options or Extension Output Options, respectively.

Available if Action is set to "Apply Job", "Create Job", or "Create Job from CronJob" and Wait for Success or Failure is selected.

Introduced in 1.0.0

Extension Output Options

Multiple Choice

Controls whether additional information is printed to Extension Output. The following options are available.

  • Include Resource Specification and Metadata
  • Include Container Information (Only applicable if Wait for Success or Failure is selected)

Available for all Actions except"Delete Resource".

Introduced in 1.0.0

STDOUT Options

Multiple Choice

Controls whether additional information is printed to Standard Output. The following options are available.

  • Include Container Logs
  • Enable Pod Monitoring

Available if Action is set to "Apply Job", "Create Job", or "Create Job from CronJob" and Wait for Success or Failure is selected.

Introduced in 1.0.0

Output Fields​

The following output-only fields provide better visibility during the execution of Universal Task Instances.

Name

Type

Description

Version Information

Resource Name

Text

Name of deployed resource.

Applicable for all Actions except"Delete Resource".

Introduced in 1.0.0

Resource Namespace

Text

Namespace the resource has been deployed on.

Applicable for all Actions except"Delete Resource".

Introduced in 1.0.0

Job Status

Text

The latest status of the Job.

Available if Action is set to "Apply Job", "Create Job", or "Create Job from CronJob" and Wait for Success or Failure is selected.

Introduced in 2.0.0

Last Updated On

Text

The timestamp when the Task Instance was last updated.

Available if Action is set to "Apply Job", "Create Job", or "Create Job from CronJob" and Wait for Success or Failure is selected.

Introduced in 2.0.0

Environment Variables​

Environment Variables can be set from the Environment Variables Task definition table. They can be useful for authentication purposes when retrieving the Resource Definition via "HTTP Link".

Environment Variable Name

Description

Version Information

GIT_TOKEN

If specified, this environment variable will be used as a Bearer token in the Authorization header when making the request to retrieve a Resource Definition via HTTP Link.

Introduced in 1.0.0

UE_HTTP_TIMEOUT

This environment variable defines the global timeout value for all requests. It affects both connection and read timeouts, preventing requests from hanging.

Accepted values: Positive integer (in seconds).

If the environment variable is not set, or is set to an invalid value, the timeout will default to 60 seconds.

Introduced in 2.0.0

UE_RESOURCE_DEFINITION_LINK_GIT_PROVIDER

This environment variable is used only when GIT_TOKEN is passed and defines which Git provider to use when fetching Kubernetes job resource definitions. It ensures the correct Authorization header is generated for the selected provider.

Supported values are:

  • github
  • gitlab
  • bitbucket
  • azure_devops

If the environment variable is not set, github is used by default.

Introduced in 2.1.0

UE_JOB_FINALIZATION_POLL_INTERVAL

This environment variable defines the interval (in seconds) between successive checks for job finalization after the pods have completed. It controls the polling frequency to ensure that job completion is detected reliably without overwhelming the server or agent resources.

Accepted values: Positive integer (in seconds).

If the environment variable is not set, or is set to an invalid value, the polling interval will default to 1 second.

Introduced in 2.1.0

Cancelation and Rerun​

In case of cancellation, the extension will stop monitor the job's current status. If the deployment process has already been initiated, it will not be impacted in any way. Additionally, in case Extension Output Options have been specified, information that has been produced at the point of cancellation will be returned.

In the case of a Task Rerun, the extension follows the same execution flow as the initial execution. As such, resources will be deployed or deleted, depending on the specified input fields, with no regard to the current condition of the GKE cluster.

Dynamic Commands​

Users can Interact with Task Instances through Dynamic Commands. The following Dynamic Commands are supported.

Name

Description

Version Information

Retrieve Container Logs

Retrieves all container logs associated with the executing Job that have been generated up to that point. The name of the Job to retrieve container logs for is inferred from the Resource Name and Resource Namespace Output Fields.

Available if Action is set to "Apply Job", "Create Job", or "Create Job from CronJob".

Introduced in 1.0.0

Delete Resource

Deletes the resource from the specified namespace. The name of the resource to delete, as well as the namespace it resides inside of, is inferred from the Resource Name and Resource NamespaceOutput Fields.

Available for all Actions except"Delete Resource".

Introduced in 1.0.0

Exit Codes​

Exit Code

Status

StatusDescription

0

Success

"SUCCESS: Task executed successfully."

1

Failure

"Execution Failed: <<Error Description>>"

2

Failure

"Authentication Error: Account cannot be authenticated."

20

Failure

"Data Validation Error: <<Error Description>>"

21

Failure

"DuplicateResourceNameError: Resource Naming Error"

40

Failure

"TimeoutExceededError: Timeout Error."

STDOUT and STDERR​

By default, the integration keeps STDOUT empty, unless specified otherwise, through the STDOUT Options field when the Action is set to "Apply Job", "Create Job", or "Create Job from CronJob". You can choose to include events related to the deployed Job's pods, which will display information about pod and container creation, execution, and deletion as they happen. Additionally, selecting Include Container Logs will cause the Task Instance to print all container logs produced during the Job execution once it completes.

STDERR provides additional information specified by the Log Level field.

info

Backward compatibility is not guaranteed for the content of STDOUT/STDERR and can be changed in future versions without notice.

How To​

Import Universal Template​

To use the Universal Template, you first must perform the following steps.

  1. This Universal Task requires the Resolvable Credentials feature. Check that the Resolvable Credentials Permitted system property has been set to true.
  2. Import the Universal Template into your Controller:
    1. Extract the zip file, you downloaded from the Integration Hub.
    2. In the Controller UI, select Services > Import Integration Template option.
    3. Browse to the "export" folder under the extracted files for the ZIP file (Name of the file will be unv_tmplt_*.zip) and click Import.
    4. When the file is imported successfully, refresh the Universal Templates list; the Universal Template will appear on the list.

Modifications of this integration, applied by users or customers, before or after import, might affect the supportability of this integration. For more information refer to Integration Modifications.

Configure Universal Task​

For a new Universal Task, create a new task, and enter the required input fields.

Integration Modifications​

Modifications applied by users or customers, before or after import, might affect the supportability of this integration. The following modifications are discouraged to retain the support level as applied for this integration.

  • Python code modifications should not be done.
  • Template Modifications
    • General Section
      • "Name", "Extension", "Variable Prefix", and "Icon" should not be changed.
    • Universal Template Details Section
      • "Template Type", "Agent Type", "Send Extension Variables", and "Always Cancel on Force Finish" should not be changed.
    • Result Processing Defaults Section
      • Success and Failure Exit codes should not be changed.
      • Success and Failure Output processing should not be changed.
    • Fields Restriction Section
      The setup of the template does not impose any restrictions. However, concerning the "Exit Code Processing Fields" section.
      1. Success/Failure exit codes need to be respected.
      2. In principle, as STDERR and STDOUT outputs can change in follow-up releases of this integration, they should not be considered as a reliable source for determining the success or failure of a task.

Event Template configuration related to "Metric Label Attributes" & "Optional Metric Labels" is allowed. However, administrators should be cautious of high cardinality scenarios that might occur.

Users and customers are encouraged to report defects, or feature requests at Stonebranch Support Desk.

Changelog​

ue-gke-jobs-2.1.0 (2026-01-22)​

Enhancements​

  • Added: New environment variable to configure the polling interval for job finalization checks.
  • Added: New environment variable to allow configuration of the Git provider used for retrieving Kubernetes job resource definitions.
  • Added: Improved compatibility with future agent releases.

Fixes​

  • Fixed: Improved handling of job finalization checks to ensure completion is detected accurately and prevent timeout errors.
  • Fixed: Issue where environment variables were not being sent during dynamic choice and dynamic command execution.

ue-gke-jobs-2.0.0 (2025-06-26)​

Enhancements​

  • Support for deploying CronJobs and Jobs from CronJobs.
  • Support for deleting CronJobs.

Breaking Changes​

  • Dropped support for Application Default Credentials Authentication Method.

ue-gke-jobs-1.0.0 (2025-03-17)​

Initial Version