Azure Kubernetes Service Jobs

Azure Kubernetes Service Jobs

Disclaimer

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

Version Information

Template NameExtension NameVersionStatus
Azure Kubernetes Service Jobsue-aks-jobs1 (Current 1.0.0)Fixes and new Features are introduced.

Refer to Changelog for version history information.

Overview

Azure Kubernetes Service (AKS) is a managed Kubernetes service that you can use to deploy and manage containerized applications. You need minimal container orchestration expertise to use AKS. AKS reduces the complexity and operational overhead of managing Kubernetes by offloading much of that responsibility to Azure. AKS is an ideal platform for deploying and managing containerized applications that require high availability, scalability, and portability, and for deploying applications to multiple regions, using open-source tools, and integrating with existing DevOps tools.

This integration provides the capability to define, deploy, and delete AKS Jobs and CronJobs on a specified Azure-powered Kubernetes cluster directly from UAC.

Key Features

FeatureDescription
Deploy ResourcesDeploy Job and Cronjob resources, either declaratively or imperatively, from local YAML or JSON files, remote URLs, or UAC scripts.
Create Jobs from CronjobsCreate one-off Job resources based on existing Cronjob definitions in the cluster.
Delete ResourcesDelete 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 StreamingLive stream real-time updates about Kubernetes pods as they are created, modified, or terminated.
Automatic or Manual Container Information RetrievalOption 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.

AreaDetails
Python VersionRequires Python 3.11, tested with Agent bundled python distribution.
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 CompatibilityUniversal Controller Version >= 7.6.0.0.
Network and ConnectivityNetwork Connectivity towards a job definition directly to the cluster Azure Kubernetes Service is required.
Southbound SystemTested with an Azure Cluster that has Kubernetes 1.30.12 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 TypeDescriptionExamples
EXTENSION
  • exit_code, status, status_description: General info regarding the task execution. In case of failure, it’s set according to the specific error that happened during the execution. A list of possible values is provided in the exit codes table in this document.

  • invocation.fields: The task configuration used for this task execution.

  • result.containers: Information gathered related to the containers spawned by the deployed job. Information is retrieved from the AKS cluster using the values appointed to the Output Only fields during execution. Only available if the corresponding Extension Output option has been selected.

  • result.resource_specification: Information relating to the specification of the deployed resource. Only available if the corresponding Extension Output option has been selected.

Successful Execution of "Apply Job" Action, with all Extension Output options and Wait for Success or Failure selected
{
	"exit_code": 0,
	"status_description": "Job applied successfully.",
	"invocation": {
		"extension": "ue-aks-jobs",
		"version": "1.0.0",
		"fields": {...}
	},
	"result": {
		"containers": [
			{
				"pod_name": "pi-simple-deploy-mwmmf",
				"container_name": "pi",
				"container_log": "3.1416",
				"exit_code": "0",
				"restart_count": "0"
			},
			{
				"pod_name": "pi-simple-deploy-mwmmf",
				"container_name": "hello-sbaro",
				"container_log": "Hello SB Team\n",
				"exit_code": "0",
				"restart_count": "0"
			}
		],
		"resource_specification": {
				"name": "pi-simple-deploy-",
				"namespace": "ue",
				"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-simple-deploy already exists in the namespace ue",
	"invocation": {
		"extension": "ue-aks-jobs",
		"version": "1.0.0",
		"fields": {...}
		}
	},
"result": {
	"errors": [
		"Resource Naming Error: A job with the name pi-simple-deploy already exists in the namespace ue"
		]
	}
}
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

  • “Enable Pod Monitoring”, which streams information about the state of pods relating to the deployed job.

  • “Include Container Logs” which outputs logs for all containers tied to the deployed job.

Both options are only applicable if Wait for Success or Failure has been selected.

Truncated STDOUT, generated by the above successful task, which has all STDOUT options selected
--- Pod Monitoring Events ---
Event: ADDED
Event Time: 2025-06-06 13:13:47 +0300
Pod Name: pi-simple-deploy-mwmmf
Phase: Pending
Conditions: Not available yet
Start Time: None

Event: MODIFIED
Event Time: 2025-06-06 13:13:47 +0300
Pod Name: pi-simple-deploy-mwmmf
Phase: Pending
Conditions: PodScheduled
Start Time: None

Event: MODIFIED
Event Time: 2025-06-06 13:13:47 +0300
Pod Name: pi-simple-deploy-mwmmf
Phase: Pending
Conditions: PodReadyToStartContainers, Initialized, Ready, ContainersReady, PodScheduled
Start Time: 2025-06-06 10:13:47+00:00
	Container: hello-sbaro
		Waiting:
			Reason: PodInitializing

	Container: pi
		Waiting:
			Reason: PodInitializing


Event: MODIFIED
Event Time: 2025-06-06 13:13:48 +0300
Pod Name: pi-simple-deploy-mwmmf
Phase: Pending
Conditions: PodReadyToStartContainers, Initialized, Ready, ContainersReady, PodScheduled
Start Time: 2025-06-06 10:13:47+00:00
	Container: hello-sbaro
		Waiting:
			Reason: PodInitializing

	Container: pi
		Waiting:
			Reason: PodInitializing

[...]

Pod pi-simple-deploy-mwmmf has reached phase 'Succeeded' but is pending deletion due to finalizers

Event: MODIFIED
Event Time: 2025-06-06 13:13:51 +0300
Pod Name: pi-simple-deploy-mwmmf
Phase: Succeeded
Conditions: PodReadyToStartContainers, Initialized, Ready, ContainersReady, PodScheduled
Start Time: 2025-06-06 10:13:47+00:00
	Container: hello-sbaro
		Terminated:
			Exit Code: 0
			Reason: Completed
			Started at: 2025-06-06 10:13:48+00:00
			Finished at: 2025-06-06 10:13:48+00:00

	Container: pi
		Terminated:
			Exit Code: 0
			Reason: Completed
			Started at: 2025-06-06 10:13:48+00:00
			Finished at: 2025-06-06 10:13:48+00:00

Pod pi-simple-deploy-mwmmf has reached phase 'Succeeded'

Pod pi-simple-deploy-mwmmf successfully completed, 1/1 pods completed.

Job pi-simple-deploy- execution finished, status is 'Complete'.

--- Logs for containers generated for job pi-simple-deploy- at 2025-06-06 13:13:52 +0300 ---
Logs for pod pi-simple-deploy-mwmmf
	Logs for container pi:
		3.1416
	Logs for container hello-sbaro:
		Hello SB Team

Configuration Examples

Example: Apply a Job stored as a UAC Script

Apply a Job to a specific AKS cluster, 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 AKS cluster, with the Resource Definition provided as a Local File. The Namespace field is used for specifying the namespace where the CronJob will be applied.

Example: Create a Job defined on an external HTTP Link and wait for Job completion

Deploy a Job to a specific AKS cluster, with the Resource Definition provided as an 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 AKS cluster, 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

Deploy a CronJob to a specific AKS cluster, 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 AKS cluster, retrieving the Job name using the Dynamic Choice field from specific namespace.

Importable Configuration Examples

This integration provides importable configuration examples along with their dependencies, grouped as Use Cases to better describe end to end capabilities. 

These examples aid in allowing task authors to get more familiar with the configuration of tasks and related Use Cases. Such tasks should be imported in a Test system and should not be used directly in production.

Initial Preparation Steps

  • STEP 1: Go to Stonebranch Integration Hub download integration with name "Azure Kubernetes Service Jobs" and extract the archive in a local directory.
  • STEP 2: Locate and import the "Azure Kubernetes Service Jobs" integration to the target Universal Controller. For more information refer to the How To section in this document.
  • STEP 3: Inside directory named "configuration_examples" you will find a list of definition zip files. Upload them one by one respecting the order presented below, by using the "Upload" functionality of Universal Controller:
    • variables.zip
    • credentials.zip
    • scripts.zip
    • tasks.zip
    • workflows.zip
  • The order indicated above ensures that the dependencies of the imported entities need to be uploaded first. 
  • All imported entities are prefixed with UC1.
  • STEP 4: Update the uploaded UAC Credential entity, with the proper Client ID/Client Secret.
  • STEP 5: Update the UAC global variables introduced with the "variables.zip" definition file. Their name is prefixed with "ue_aks_jobs". Review the description of the variables as they include information on how should be populated.
  • STEP 6: Create an OMS record on the Universal Controller. Ensure the address matches the one assigned to the relevant global variable from the previous step. For more information refer to the Creating OMS Server Records in this document.
  • STEP 7: Create an Agent Cluster on the Universal Controller. Ensure the name matches the one assigned to the relevant global variable from the previous step. For more information refer to the Creating an Agent Cluster in this document,

How to "Upload" Definition Files to a Universal Controller

The "Upload" functionality of Universal Controller allows Users to import definitions exported with the "Download" functionality.

Login to Universal Controller and:

  • STEP 1: Click on "Tasks"  "All Tasks"
  • STEP 2: Right click on the top of the column named "Name"
  • STEP 3: Click "Upload..."

In the pop-up "Upload..." dialogue:

  • STEP 1: Click "Choose File".
  • STEP 2: Select the appropriate zip definition file and click "Upload".
  • STEP 3: Observe the Console for possible errors.

Use Case 1: Deploy a Universal Agent inside an AKS Cluster, using it to execute a Linux Task.

Description

In this Use Case, a Job is executed on the AKS cluster that creates an agent. This agent is used for running a Linux Task. Upon successful completion of the Linux Task, the created agent (resource) is deleted from the AKS cluster.

The tasks configured demonstrate the following capabilities among others:

  • Capability to use the extension for executing various jobs that have different functionalities.
  • Demonstrate a case where the deployed resources can be used for executing other tasks on the Controller.
  • Combining the different actions in a single workflow. (Create the resource → Delete the resource)

The components of the solution are described below:

  1. "UC1: AKS Jobs - Single-Container - Agent" - This is the starting task of the workflow. It triggers the execution of a Job on the AKS cluster that creates the agent. 
  2. "UC1: Run with AKS Agent" - The Linux Task to be executed on the deployed agent.
  3. "UC1: AKS Jobs - Delete Resource - Agent" - This task deletes the deployed agent on the AKS Cluster.

How to Run

Execution Steps:

  • STEP 1: Launch Workflow "UC1: AKS Jobs - Agent Workflow".
  • STEP 2: Review the outputs of the task instances.

Expected Results:

  • The Job that creates the agent is executed successfully on the AKS cluster.
  • The Linux Task is executed successfully on the deployed agent.
  • The Job is deleted successfully on the AKS cluster.

Input Fields

FieldTypeDescriptionVersion Information
ActionChoice

The action to be executed. The following options are available.

  • Apply Job

  • Apply CronJob

  • Create Job

  • Create Job from CronJob

  • Create CronJob

  • Create Template

  • Delete Resource

Introduced in 1.0.0
Azure Authentication MethodChoice

The authentication method used to connect to AKS.

Authentication methods currently supported:

  • Service Principal (Client Credentials)

Introduced in 1.0.0
Client CredentialsCredentialsThe Client Credentials that have access to the AKS Resource. The Runtime User field should be populated with the Application (client) ID, while the Runtime Password with the Application (client) Secret.Introduced in 1.0.0
Tenant IDTextThe Directory (Tenant) ID of the Application with access to the AKS Resource.Introduced in 1.0.0
Subscription IDDynamic ChoiceThe Subscription ID associated with the AKS Resource.Introduced in 1.0.0
Resource GroupDynamic ChoiceThe Resource Group associated with the AKS Cluster.Introduced in 1.0.0
ClusterDynamic ChoiceThe AKS Cluster.Introduced in 1.0.0
NamespaceTextThe 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.Introduced in 1.0.0
Resource Definition SourceChoice

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.

  • UAC Script

  • Local File

  • HTTP Link

Available if Action is set to any of “Apply Job”, “Apply CronJob”, “Create Job”, “Create CronJob”.

Introduced in 1.0.0
Resource Definition ScriptScript

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 PathText

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 LinkText

The HTTP link that points to the Job Definition or CronJob Manifest. Environment variables in the URL are resolved; The GIT_TOKEN environmental variable, if set, is used as a Bearer token for authorization.

Mandatory if Resource Definition Source is set to “HTTP Link”.

Introduced in 1.0.0
CronJob to UseDynamic Choice

The CronJob to use when creating Job from CronJob.

Available and Mandatory if Action is set to “Create Job from CronJob”.

Introduced in 1.0.0
New Job NameText

The name that the created Job should have.

Available and Mandatory if Action is set to “Create Job from CronJob”

Introduced in 1.0.0
Resource KindChoice

The type of Resource to be deleted. Available options are:

  • Job

  • CronJob

Available and Mandatory if Action is set to “Delete Resource”.

Introduced in 1.0.0
Resource NameDynamic Choice

The name of the Resource to be deleted.

Available and Mandatory if Action is set to “Delete Resource”.

Introduced in 1.0.0
Wait for Success or FailureCheckbox

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 OptionsChoice

Controls whether additional information is printed to Extension Output. Available options are:

  • Include AKS Resource Specification

  • 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 OptionsChoice

Controls whether additional information is printed to Standard Output. Available options are:

  • Include Container Logs

  • Enable Pod Monitoring

Only available if Wait for Success or Failure is selected.

Introduced in 1.0.0
Delete Job OptionsChoice

Specifies the conditions under which the Deployed Job should be deleted. When deploying a job from CronJob, only the job instance itself will be deleted. Available options are:

  • Do not Delete Job

  • Delete Job on Successful execution (default)

  • Delete Job regardless of execution status

Only available if Wait for Success or Failure is selected.

Introduced in 1.0.0
Retrieve Container Information Only on FailureCheckbox

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.

NameTypeDescriptionVersion Information
Resource NameTextName of deployed Resource. Applicable for all Actions except “Delete Resource”.Introduced in 1.0.0
Resource NamespaceTextThe Namespace in which the resource has been deployed on. Applicable for all Actions except “Delete Resource”.Introduced in 1.0.0
Job StatusTextThe latest status of the AKS Job.Introduced in 1.0.0
Last Updated OnText

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.

Environment Variables can be used for authentication purposes when retrieving the Resource Definition via HTTP Link. Environment variables will be resolved when provided inside of the specified link (Example https://${GITLAB_TOKEN}@stonebranch.com/path/to/file.json).

Alternatively, the GIT_TOKEN variable can be used to specify a value for the Authorization header when making the request.

Environment Variable NameDescriptionVersion Information
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 1.0.0
GIT_TOKENIf 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

Cancellation and Rerun

  • In case of cancellation, monitoring of the deployed job is halted. No additional actions are taken on the AKS Cluster. If the deployment process has already been initiated, it will not be impacted in any way.

  • 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 regards to the existing condition of the AKS Cluster.

Dynamic Commands

Command NameAllowed Task Instance StatusDescription
Delete ResourceCancelled, 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 Resource”.

Retrieve Container LogsRunning, 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

StatusStatus DescriptionMeaning
0Success“Task executed successfully.“Successful Execution.
1Failure

“Execution Failed: <<Error Description>>”

Generic Error. Raised in case of failure and in case no other failure exit code is applicable.
2Failure“Authentication Error: Account cannot be authenticated.“Bad Credentials.
20Failure“Data Validation Error: <<Error Description>>“Input fields validation error.
21Failure

“DuplicateJobNameError: Job Naming Error.”

A job sharing the provided name already exists in the specified namespace. Raised only if attempting to manage resource imperatively.
40Failure“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 and its controlled by STDOUT Options field.

STDERR provides additional information to the user, the detail of it 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.

  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.

Document References

This document references the following links:

Document LinkDescription
Universal TemplatesUser documentation for creating, working with, and understanding Universal Templates and Integrations.
Universal TasksUser documentation for creating Universal Tasks in the Universal Controller user interface.
Azure Kubernetes ServiceAzure Kubernetes Service documentation.
Kubernetes The Kubernetes documentation.

Changelog

ue-aks-jobs-1.0.0 (2025-09-04)

Initial Release