Amazon Elastic Kubernetes Service Jobs
Disclaimer
Your use of this download is governed by Stonebranch’s Terms of Use.
Version Information
Template Name | Extension Name | Version | Status |
|---|---|---|---|
Amazon Elastic Kubernetes Service Jobs | ue-aws-eks-jobs | Fixes and new Features are introduced. |
Refer to Changelog for version history information.
Overview
AWS Elastic Kubernetes Service (EKS) is used to deploy and manage containerized applications. Minimal container orchestration expertise is required to use this integration. EKS is considered an ideal platform for the deployment and management of containerized applications that require high availability, scalability, and portability. It is also used for deploying applications across multiple regions, utilizing open-source tools, and integrating with existing DevOps tools.
This integration provides the capability to trigger, control, and manage Kubernetes Jobs and CronJobs on a specified EKS cluster.
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 and 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 |
|
Universal Controller Compatibility | Universal Controller Version >= 7.6.0.0. |
Network and Connectivity | Network Connectivity towards the cluster on Elastic Kubernetes Service is required. |
Southbound System | Tested with an EKS Cluster that has Kubernetes 1.33.1 installed. It should be compatible on 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
Output Type | Description | Examples |
|---|---|---|
EXTENSION |
| |
STDOUT | The STDOUT output produced during the execution of the task instance. Output can be controlled via the STDOUT Options input field. Available choices are
Both options are only applicable if Wait for Success or Failure has been selected. | |
STDERR | Shows the logs from the Task Instance execution. The verbosity is controlled by the Task configuration Log Level. |
The configuration for tasks to Create a Resource on the cluster remains unchanged compared to the configuration to Apply a Resource. Only a different action is selected from the available fields.
Create and Apply a Job on the EKS Cluster
This configuration creates a Job definition. The Job definition is retrieved from a defined script on the Controller. After the Job is created, the task waits for it to complete and deletes the Job from the cluster if it finishes successfully. All output options are enabled, providing additional information on STDOUT and Extension Output.
Create and Apply a CronJob on the EKS Cluster
This configuration applies a CronJob. The Job definition is fetched from an HTTP link, using the GIT_TOKEN and UE_RESOURCE_DEFINITION_LINK_GIT_PROVIDER environment variables for access. The resource specification for the deployed CronJob will be visible on the Extension’s output. However, container information will be omitted, as no containers are tied to the deployment of the CronJob.
Create a Job from a CronJob on the EKS Cluster
This configuration creates a Job from an existing CronJob. The Job will be created based on the CronJob's specification, and its name is specified in the relevant field. The resulting Job is to be monitored, producing information on both output streams. Note that container logs are to be retrieved and displayed only in the event that the Job results in failure.
Delete a Resource from the EKS Cluster
This configuration deletes a Job present on the EKS Cluster. The resource type chosen can be a Job or a CronJob, whereas the relevant Resource Name dynamic choice field can be used to load all resources of the specified type.
Input Fields
Name | Type | Description | Version Information |
|---|---|---|---|
Action | Choice | The action to be executed. The following options are available.
| Introduced in 1.0.0 |
Resource Type | Choice | The type of Resource to be deleted. Available options are:
Available & Mandatory if Action is set to “Delete Job” | Introduced in 1.0.0 |
AWS Credentials | Credentials | The Credentials definition should be as follows.
The field population is optional and applicable for all the Actions. When AWS Credentials is not populated as part of the task definition, during task execution the integration will look for AWS Credentials on the task execution environment. Refer to AWS Credential Configuration Options for more information | Introduced in 1.0.0 |
AWS Region | Text | Region for the Amazon Web Service i.e. "us-east-1" The field population is optional and applicable for all the Actions. When AWS Region is not populated as part of the task definition, during task execution the integration will look for AWS Region on the task execution environment (AWS configuration file or through AWS environment variables). The field is applicable for all the Actions. | Introduced in 1.0.0 |
Role ARN | Text | Role ARN of the AWS Assume Role functionality. The Assume Role functionality in AWS (Amazon Web Services) allows a user or service to take on the permissions of another IAM (Identity and Access Management) role temporarily. If the field is left empty, Role Assumption is not performed | Introduced in 1.0.0 |
Cluster | Dynamic Choice | The EKS Cluster to connect to. | Introduced in 1.0.0 |
Namespace | Text | The namespace in which resources are to be deployed or deleted. In the case of resource deployment, this field will be used only as a fallback in case a ‘namespace’ value is not specified inside of the Resource Definition. Mandatory if Action is set to “Delete Resource” or “Create Job from CronJob“ | Introduced in 1.0.0 |
Resource Definition Source | Choice | Specifies the source of the Job, CronJob, or Template manifest. The input must be in YAML or JSON format and must define exactly one resource.
Available if Action is set to any of “Apply Job”, “Apply CronJob”, “Create Job”, “Create CronJob”, “Create Template” | Introduced in 1.0.0 |
Resource Definition Script | Script | The UAC Script containing the Resource definition. Mandatory if Resource Definition Source is set to “UAC Script” | Introduced in 1.0.0 |
Resource Definition File Path | Text | The Agent’s local full filename path to the Resource Definition. Mandatory if Resource Definition Source is set to “Local File” | Introduced in 1.0.0 |
Resource Definition Link | Text | The HTTP link that points to the Job Definition or CronJob/Template Manifest. Environment variables in the URL are resolved; The Mandatory 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 Job from CronJob. Available & Mandatory if action is set to “Create Job from CronJob” | Introduced in 1.0.0 |
New Job Name | Text | The name that the created Job should have. Available & Mandatory if action is set to “Create Job from CronJob” | Introduced in 1.0.0 |
Resource Name | Dynamic Choice | The name of the Resource to be deleted. Available & Mandatory if Action is set to “Delete Job” | Introduced in 1.0.0 |
Wait for Success or Failure | Checkbox | Choose where the UAC task should wait until the deployed Job is completed. Available if Action is set to “Apply Job”, “Create Job”, “Create Job from CronJob” | Introduced in 1.0.0 |
Monitoring Timeout (sec) | Integer | The maximum number of seconds to monitor whether the job has been completed. If exceeded, a TimeoutExceededError is raised. Set to 0 to monitor indefinitely. Only available if Wait for Success or Failure is selected. | Introduced in 1.0.0 |
Extension Output Options | Choice | Controls whether additional information is printed to Extension Output. Available options are:
Available for all actions except “Delete Job” | Introduced in 1.0.0 |
STDOUT Options | Choice | Controls whether additional information is printed to Standard Output. Available options are:
Only available if Wait for Success or Failure is selected. | Introduced in 1.0.0 |
Delete Job Options | Choice | Specifies the conditions under which the Deployed Job should be deleted. When deploying a job from a Template or CronJob, only the job instance itself will be deleted. Available options are:
Only available if 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 Job fails. This option does nothing if “Include Container Logs” or "Include Container Information" options are not requested as part of the Standard Output or Extension Output options, respectively. Only available if 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.
| Field | Type | Description | Version Information |
|---|---|---|---|
Resource Name | Text | Name of deployed Resource. Applicable for all Actions except “Delete Job”. | Introduced in 1.0.0 |
Resource Namespace | Text | The Namespace in which the resource has been deployed on. Applicable for all Actions except “Delete Job”. | Introduced in 1.0.0 |
Job Status | Text | The latest status of the AKS Job. | Introduced in 1.0.0 |
Last Updated On | Text | The timestamp when the task instance was last updated. | Introduced in 1.0.0 |
Environment Variables
Environment Variables can be set from the Environment Variables task definition table. The following environment variables can affect the behavior of the extension.
| Environment Variable Name | Description | Version Information |
|---|---|---|
UE_HTTP_TIMEOUT | Specifies the timeout (in seconds) for HTTP requests made by the Task Instance. A higher value allows for slower responses, while a lower value enforces stricter time constraints. If not set, a default of 60 seconds is used. When a timeout happens, the Task Instance ends in failure. | Introduced in 1.0.0 |
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_RESOURCE_DEFINITION_LINK_GIT_PROVIDER | This environment variable is used only when Supported values are:
If the environment variable is not set, | Introduced in 1.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 1.1.0 |
Cancellation and Rerun
In case of cancellation, monitoring of the deployed job is halted. No additional actions are taken on the EKS Cluster. If the deployment process has already been initiated, it will not be impacted in any way. If Extension Output Options have been specified, information that has been produced at the point of cancellation will be returned.
In case of 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 existing condition of the EKS Cluster.
Dynamic Commands
Command Name | Allowed Task Instance Status | Description |
|---|---|---|
Delete Resource | Cancelled, Failed, Finished, Success | Deletes the deployed resource from the specified namespace. The name of the Job to delete, as well as the project it exists inside of, is inferred using the Resource Name and Resource Namespace Output Fields. Applicable for all Actions except “Delete Job”. |
Retrieve Container Logs | Running, Cancelled, Failed, Finished, Success | Retrieves all container logs associated with the deployed 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 Project Output Fields. Only applicable if Action is set to “Apply Job”, “Create Job”, “Create Job from CronJob”. |
Exit Codes
Exit Code | Status | Status Description | Meaning |
|---|---|---|---|
| 0 | Success | “Task executed successfully.“ | Successful Execution. |
| 1 | Failure | “Execution Failed: <<Error Description>>” | Generic Error. Raised in case of failure and in case no other failure exit code is applicable. |
| 2 | Failure | “Authentication Error: Account cannot be authenticated.“ | Bad Credentials. |
| 20 | Failure | “Data Validation Error: <<Error Description>>“ | Input fields validation error. |
| 21 | Failure | “DuplicateJobNameError: Job Naming Error.” | A job sharing the provided name already exists in the specified namespace. Raised only if attempting to manage resource imperatively. |
| 40 | Failure | “TimeoutExceededError: Timeout Error.“ | The number of seconds to monitor the job, specified by the Timeout Seconds field, has been exceeded. |
STDOUT and STDERR
STDOUT is used for displaying Job information. It is controlled by STDOUT Options field.
STDERR provides additional information to the user. The level of detail is tuned by Log Level Task Definition field.
Backwards 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.
This Universal Task requires the Resolvable Credentials feature. Check that the Resolvable Credentials Permitted system property has been set to true.
Import the Universal Template into your Controller:
Extract the zip file, you downloaded from the Integration Hub.
In the Controller UI, select Services > Import Integration Template option.
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.
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.Success/Failure exit codes need to be respected.
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.
Users and customers are encouraged to report defects, or feature requests at Stonebranch Support Desk.
Document References
This document references the following documents:
Document Link | Description |
|---|---|
User documentation for creating, working with and understanding Universal Templates and Integrations. | |
User documentation for creating Universal Tasks in the Universal Controller user interface. | |
Azure Kubernetes Service documentation. | |
The Kubernetes documentation. |
Changelog
ue-aws-eks-jobs-1.1.0 (2025-11-25)
Enhancements
- Added: New environment variable UE_JOB_FINALIZATION_POLL_INTERVAL to configure the polling interval for job finalization checks (#48371).
Added: New environment variable UE_RESOURCE_DEFINITION_LINK_GIT_PROVIDER to allow configuration of the Git provider used for retrieving Kubernetes job resource definitions (#51125, #51126).
Fixes
Fixed: Improved handling of job finalization checks to ensure completion is detected accurately and prevent timeout errors (#48371).
ue-aws-eks-jobs-1.0.0 (2025-06-26)
Initial Version