Kubernetes PodCreate

Pod specification

Kubernetes Pod spec map defining containers, volumes, restart policy, and related settings. Must declare at least one container. Template expressions are allowed, including {{ workingDir }} resolving to '/kestra/working-dir' when inputFiles or outputFiles are configured. See using pods in the Kubernetes documentation for the full spec format.

When inputFiles or outputFiles are configured, Kestra automatically injects file-transfer containers named init-files (init container) and out-files (sidecar). Any user-provided containers with those reserved names will be silently removed and replaced by Kestra's own containers. Additional containers you define alongside your main container are fully preserved as sidecars.

Kubernetes connection

Connection settings for the cluster. If omitted, the client resolves credentials in order: system properties, environment variables, kubeconfig, then in-cluster service account.

Default container spec applied to all containers in the pod

When set, these container spec fields are merged into all containers including:

• User-defined containers in the spec
• Init and sidecar containers for file transfer (unless fileSidecar.defaultSpec is set)

This provides a convenient way to apply uniform container settings across all containers, which is especially useful in restrictive environments like GovCloud.

Supports any valid Kubernetes container spec fields such as:

• securityContext: Security settings for all containers
• volumeMounts: Volume mounts to add to all containers
• resources: Resource limits/requests for all containers
• env: Environment variables for all containers

Merge behavior:

• For nested objects (like securityContext): deep merge, container-specific values take precedence
• For volumeMounts: concatenated, with defaults added first
• For env: deduplicated by name — container-specific values always win over defaults on collision
• Container-specific values always override defaults

Example configuration:

containerDefaultSpec: 
  securityContext: 
    allowPrivilegeEscalation: false
    capabilities: 
      drop: 
      - ALL
    readOnlyRootFilesystem: true
    seccompProfile: 
      type: RuntimeDefault
  volumeMounts: 
    - name: tmp
      mountPath: /tmp
  resources: 
    limits: 
      memory: "256Mi"

Delete pod after task completion

Default true. Deletes the pod after success or failure; set to false to keep it for debugging. Pods are still deleted when the task is killed.

The configuration of the file sidecar container that handles the download and upload of files

Inherit cluster auto-config

When true and a connection is set, the client config is seeded from the ambient auto-config (system properties, env, kubeconfig, in-cluster service account) before applying connection, so a partial connection (e.g. only a namespace) keeps the resolved credentials instead of starting blank. Default false.

The files to create on the local filesystem – it can be a map or a JSON object

The files will be available inside the kestra/working-dir directory of the container. You can use the special variable {{workingDir}} in your command to refer to it.

Pod metadata

Name, labels, and annotations applied to the pod. Name is auto-generated from the task run when omitted. Supports template expressions.

The namespace where the operation will be done

The Kubernetes namespace in which to execute the operation. Defaults to 'default' if not specified.

The files from the container filesystem to send to Kestra's internal storage

Only files created inside the kestra/working-dir directory of the container can be retrieved. Must be a list of glob expressions relative to the current working directory, some examples: my-dir/**, my-dir/*/** or my-dir/my-file.txt..

Reference (ref) of the pluginDefaults to apply to this task.

Resume an existing pod when possible

Default true. Reconnects to a pod labeled with the current taskrun ID, whatever attempt created it. A completed (Succeeded) pod is only resumed within the same attempt, so task retries re-run the workload. Stale pods from previous attempts are deleted. Still-active stale pods are removed even when delete is false, to protect quotas and concurrency limits.

Grace period for late logs

Duration to wait after completion before fetching final logs. Default PT30S; increase in high-throughput clusters to avoid missing trailing logs.

Wait for pod completion

Maximum run time after reaching Running (defaults to PT1H). PodCreate fails and deletes the pod when exceeded.

The maximum duration to wait until the resource becomes ready

When set to a positive duration, waits for the resource to report Ready=True in its status conditions. Set to PT0S (zero, default) to skip waiting. Supports Pods, StatefulSets, and custom resources that use the Ready condition. Note: Deployments are not supported as they use the Available condition instead of Ready.

Wait for pod to reach Running

Maximum time to reach Running (defaults to PT10M). Covers scheduling, image pulls, and startup. Used by PodCreate.