Documentation

AKS Job

The AKS Job job type runs a Kubernetes Job resource in an AKS cluster namespace. Polysync clones an existing Job spec, overrides the first container's environment variables with the Polysync parameter values, and submits the new Job via the Kubernetes API. The source Job is identified by its name — Polysync stores that in the External Id.

This job type is supported on the Azure Kubernetes Service platform.

Required job fields

  • External Id — the source Kubernetes Job's metadata.name in the configured namespace.
  • Job Type — AKS Job (set automatically on import).

Optional job attributes (used as a fallback if the source Job is deleted): Container Image, Container Command, Container Args.

Job discovery

BatchV1.ListNamespacedJob (with continueToken / limit=100) in the configured namespace. The first container's env block is captured and exposed as the Polysync parameter list (each env var name becomes a string parameter with its current default value).

Parameter handling

The provider takes the source Job's spec.template.spec.containers[0].env array and overlays the Polysync Input / Input&Output values, keyed by parameter name. The amended spec is submitted as a brand-new Job whose name is derived from the External Id with a unique suffix.

Direction Sent as container env vars Updated from response
Input ✅ ❌
Output ❌ ❌ (not supported)
Input&Output ✅ ❌ (not supported)

All values are strings — Kubernetes env vars have no type metadata. The Polysync Data Type is informational only.

Output parameters are not supported. Persist results to a shared volume / object store and read them from a downstream Job.

Execution flow

  1. Polysync Gets the source V1Job from the namespace (or reconstructs a busybox-based spec from the stored attributes if the source has been deleted).

  2. Container[0]'s env vars are overlaid with Polysync parameter values.

  3. The new Job is created via BatchV1.CreateNamespacedJob and its metadata.name becomes the Polysync RunId.

  4. Status is polled with ReadNamespacedJobStatus and decoded from the Job's status.conditions[]:

    Kubernetes Job condition / state Polysync status
    conditions[type==Complete].status==True Success
    conditions[type==Failed].status==True Failed
    conditions[type==Suspended].status==True Cancelled
    status.active > 0 or status.startTime set Running
    (no conditions, no startTime) Starting
    (other) Unknown

  5. Cancel is supported via DeleteNamespacedJob with propagationPolicy = "Background" — Kubernetes terminates and garbage-collects the Job and its Pods.

Monitor URL

https://portal.azure.com/#resource/subscriptions/{subId}/resourceGroups/{rg}
  /providers/Microsoft.ContainerService/managedClusters/{clusterName}/workloads

(Generic Workloads blade — drill into the namespace from there.)

Best practices

  • Keep the source Job spec parameterised via env vars (don't bake per-run values into the image / command line) so Polysync's env-var override mechanism reaches them.
  • Set explicit resources.requests / resources.limits on the source spec so Polysync-cloned Jobs don't oversubscribe the cluster.
  • For long-running Jobs, set activeDeadlineSeconds so Kubernetes eventually fails the Job rather than letting Polysync poll forever.

Troubleshooting

  • Job stays in Starting forever — the cluster has no schedulable node matching the Pod's resource requests / node selector. Inspect Pod events with kubectl describe pod.
  • Cancel returns true but Pods linger — Background propagation garbage-collects asynchronously; Pods will be cleaned up within seconds.
  • Source job not found — the source Job was deleted from the cluster. Set Container Image / Command / Args on the Polysync Job to enable the fallback reconstruction path.