Skip to content

Kubernetes Object Trigger

Apart from Argo workflow objects, the sensor lets you trigger any Kubernetes objects including Custom Resources such as Pod, Deployment, Job, CronJob, etc. Having the ability to trigger Kubernetes objects is quite powerful as providing an avenue to set up event-driven pipelines for existing workloads.

K8s Trigger

Trigger a K8s Pod

  1. We will use webhook event-source and sensor to trigger a K8s pod.

  2. Lets set up a webhook event source to process incoming requests.

    kubectl apply -n argo-events -f
  3. To trigger a pod, we need to create a sensor as defined below.

    kind: Sensor
      name: webhook
        serviceAccountName: create-pod-sa # A service account has privileges to create a Pod
        - name: test-dep
          eventSourceName: webhook
          eventName: example
        - template:
            name: webhook-pod-trigger
              operation: create
                  apiVersion: v1
                  kind: Pod
                    generateName: hello-world-
                      - name: hello-container
                          - "hello-world"
                          - cowsay
                        image: "docker/whalesay:latest"
                - src:
                    dependencyName: test-dep
                  dest: spec.containers.0.args.0
  4. Create the sensor.

    kubectl apply -n argo-events -f
  5. Lets expose the webhook event-source pod using port-forward so that we can make a request to it.

    kubectl -n argo-events port-forward <name-of-event-source-pod> 12000:12000
  6. Use either Curl or Postman to send a post request to the http://localhost:12000/example.

    curl -d '{"message":"ok"}' -H "Content-Type: application/json" -X POST http://localhost:12000/example
  7. After the pod was completed, inspect the logs of the pod, you will see something similar as below.

    / {"context":{"type":"webhook","specVersi \
    | on":"0.3","source":"webhook","e |
    | ventID":"30306463666539362d346666642d34 |
    | 3336332d383861312d336538363333613564313 |
    | 932","time":"2020-01-11T21:23:07.682961 |
    | Z","dataContentType":"application/json" |
    | ,"subject":"example"},"data":"eyJoZWFkZ |
    | XIiOnsiQWNjZXB0IjpbIiovKiJdLCJDb250ZW50 |
    | LUxlbmd0aCI6WyIxOSJdLCJDb250ZW50LVR5cGU |
    | iOlsiYXBwbGljYXRpb24vanNvbiJdLCJVc2VyLU |
    | FnZW50IjpbImN1cmwvNy41NC4wIl19LCJib2R5I |
    \ jp7Im1lc3NhZ2UiOiJoZXkhISJ9fQ=="}       /
                      ##        .            
                ## ## ##       ==            
             ## ## ## ##      ===            
         /""""""""""""""""___/ ===        
    ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~   
         \______ o          __/            
          \    \        __/             


You can specify the operation for the trigger using the operation key under triggers->template->k8s.

Operation can be either.

  1. create: Creates the object if not available in K8s cluster.
  2. update: Updates the object.
  3. patch: Patches the object using given patch strategy.
  4. delete: Deletes the object if it exists.

More info available at here.


Similar to other type of triggers, sensor offers parameterization for the K8s trigger. Parameterization is specially useful when you want to define a generic trigger template in the sensor and populate the K8s object values on the fly.

You can learn more about trigger parameterization here.


Trigger policy helps you determine the status of the triggered K8s object and decide whether to stop or continue sensor.

To determine whether the K8s object was successful or not, the K8s trigger provides a Resource Labels policy. The Resource Labels holds a list of labels which are checked against the triggered K8s object to determine the status of the object.

            # Policy to configure backoff and execution criteria for the trigger
            # Because the sensor is able to trigger any K8s resource, it determines the resource state by looking at the resource's labels.
                # Backoff before checking the resource labels
                  # Duration is the duration in nanoseconds
                  duration: 1000000000 # 1 second
                  # Duration is multiplied by factor each iteration
                  factor: 2
                  # The amount of jitter applied each iteration
                  jitter: 0.1
                  # Exit with error after these many steps
                  steps: 5
                # labels set on the resource decide if the resource has transitioned into the success state.
                # Determines whether trigger should be marked as failed if the backoff times out and sensor is still unable to decide the state of the trigger.
                # defaults to false
                errorOnBackoffTimeout: true

Complete example is available here.