PodCreate

Create a pod on a Kubernetes cluster, wait until the pod stops and collect its logs.

The pod specification

Kubernetes pod specification defining containers, volumes, restart policy, and other pod settings. Must include at least one container. Supports dynamic template expressions including the special variable which resolves to '/kestra/working-dir' when inputFiles or outputFiles are used.

The connection parameters to the Kubernetes cluster

If no connection is defined, we try to load the connection from the current context in the following order:

1. System properties
2. Environment variables
3. Kube config file
4. Service account token and a mounted CA certificate.

You can pass a full configuration with all options if needed.

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 lists (like volumeMounts, env): concatenated, with defaults added first
• 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"

Whether to delete the pod after task completion

When true (default), the pod is automatically deleted after successful completion or failure. Set to false to keep the pod for debugging purposes. Note that pods are always deleted when the task is killed.

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

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.

The pod metadata configuration

Kubernetes metadata for the pod, including labels, annotations, and name. If name is not specified, it will be auto-generated based on the task execution context. Supports dynamic 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..

Whether to resume execution of an existing pod

When true (default), attempts to reconnect to an existing pod with matching taskrun ID and attempt count instead of creating a new pod. This enables recovery from interrupted executions. If no matching pod exists or multiple matching pods are found, a new pod is created.

Additional time to wait for late-arriving logs after pod completion

After the pod completes and initial log collection finishes, wait this duration to capture any remaining logs that may still be in transit. Defaults to 30 seconds. Useful as a safety net for high-throughput scenarios where logs may arrive slightly delayed.

The maximum duration to wait for pod completion

Maximum duration allowed for the pod to complete after reaching Running state. If the pod does not complete within this time, the task will fail and the pod will be deleted. Only used by PodCreate task.

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.

The maximum duration to wait until the pod is running

Maximum time to wait for the pod to reach Running state, including scheduler assignment, image pull, and container startup. Only used by PodCreate task.