Workflows

A Kratix Promise can be configured with a series of workflows for both Promises and Resources, defined within the Promise workflows field.

Within the workflows, Promise writers can define a series of actions that will be executed when certain conditions are met in the system.

Summary

The supported workflows are summarised in the table below. See the other sections on this page for details.

	Trigger(s)	Supported Pipelines
Promise Configure	The Promise is created, updated, or reconciled	Multiple, executed serially
Promise Delete	The Promise is deleted	Single
Resource Configure	The Resource is created, updated or reconciled, or the parent Promise is updated	Multiple, executed serially
Resource Delete	The Resource is deleted	Single

An example of how workflows are defined within the Promise is shown below.

platform: platform.kratix.io/v1alpha1
kind: Promise
metadata:
  ...
spec:
  ...
  workflows:
    resource:
      configure:
        - # Pipeline definitions (multiple)
      delete:
        - # Pipeline definition (single)
    promise:
      configure:
        - # Pipeline definitions (multiple)
      delete:
        - # Pipeline definition (single)

A particular workflow (e.g. resource.configure) is an array of Kratix Pipeline objects that will be executed in order.

See the next section to learn how to define a Pipeline.

Pipelines

A Kratix Pipeline kind is a simple wrapper around a Kubernetes Pod.

Pipelines will automatically mount the necessary Kratix Volumes and set Environment Variables for the provided containers.

An example Pipeline is shown below.

apiVersion: platform.kratix.io/v1alpha1
kind: Pipeline
metadata:
  name: # Name (must be unique within the Promise)
  namespace: # Namespace (optional)
spec:
  volumes:
    - # Volume definitions, in addition to `/kratix` volumes (optional)
  containers:
    - name: # Container name (must be unique within the Pipeline)
      image: # Container image to run
      # Supported fields passed through to underlying Pod spec (all optional):
      command: []
      args: []
      env: []
      envFrom: []
      volumeMounts: []
      imagePullPolicy: # Either Always, IfNotPresent or Never
  imagePullSecrets: []

Refer to the Kubernetes Pod Spec documentation for more information on the fields above.

note

Not all fields from the Pod spec are supported. We will add support for more fields in the future.

Secrets

To access Secrets in the Pipeline, you can pass in a reference to the Pipeline container's env using valueFrom.secretKeyRef in the standard Kubernetes way.

note

The Secret must be accessible within the Pipeline's namespace.

Refer to the Kubernetes documentation for more details on Secrets in Kubernetes.

Volumes

Kratix will run each container in the spec.containers list in order, providing a set of common volumes, as defined below.

Input

Kratix provides an input directory to the container, mounted at /kratix/input. This directory is populated with different files depending on the type of workflow.

object.yaml

In all workflows, all Pipeline containers will have access to an object.yaml file within the /kratix/input directory.

The contents of this file vary as follows:

• Promise workflows: The object.yaml file contains the full Promise definition.
• Resource workflows: The object.yaml file contains the Resource Request definition which was submitted to the Kratix platform.

This is a useful way to find out information about the Kubernetes Object the Pipeline is being invoked for. For example, you could read the latest status from this input Object and modify the behaviour of the Pipeline accordingly.

If your workflow contains multiple Pipelines, then the object.yaml is the only way to communicate between the Pipelines (e.g. via status updates).

Output

At the end of a Pipeline, all files present in the output directory mounted at /kratix/output will be written to the State Store.

All containers in the Pipeline can write to this volume, and any container can add, update, or remove documents from this directory.

note

Files written to /kratix/output in delete Pipelines will be ignored.

Metadata

All containers in a configure Pipeline have access a shared metadata directory mounted at /kratix/metadata.

Pipeline containers can control aspects of how Kratix behaves by creating special files in this directory:

• destination-selectors.yaml can be added to any Promise to further refine where the resources in /kratix/output will be scheduled.
• status.yaml allows the Pipeline to communicate information about the resource back to the requester. See the status documentation for more information.

Passing data between containers

Kratix scans for these files and ignores all other files in the /kratix/metadata directory. If you need to pass additional information to the next container in the Pipeline, you can safely write to the /kratix/metadata directory.

Environment Variables

Kratix will set the following environment variables for all containers in the workflow:

Variable	Description
KRATIX_WORKFLOW_ACTION	The action that triggered the workflow. Either configure or delete.
KRATIX_WORKFLOW_TYPE	The type of workflow. Either resource or promise.
KRATIX_PROMISE_NAME	The name of the Promise.

By checking the KRATIX_WORKFLOW_ACTION and KRATIX_WORKFLOW_TYPE environment variables, a container is able to discover the context in which it's being invoked (e.g. "I'm running as part of a Promise Configure workflow").

This means that you could write a single container image to be used in all four workflows (promise.configure, promise.delete, resource.configure, and resource.delete), and switch the container's mode of operation based on the context.