owned this note   changed 2 years ago  
Linked with GitHub

Knative Extension

Table of Contents

Introduction

This extension simplifies orchestrating Knative objects within Serverless Workflow.

Use Cases

  • Knative service invocation
  • Producing and sending CloudEvents to Knative Eventing objects
  • Knative service revision invocation
  • Sending events to Knative Broker/Channel

Context

  • Example: Serverless Workflow CRD





apiVersion: ...
kind: ServerlessWorkflow
metadata:
  name: ...
  namespace: ecommerce # use by the resolver
  • Custom application running within Kubernetes

Extension Definition

Function Definition

Parameter Description Type Required
operation must be knative string yes
destination Destination yes when operation is knative

Resolving Destination

Addressable Objects

Addressable objects receive requests delivered over HTTP to an address defined in their status.address.url field.

Knative services, brokers and channels are example of addressable objects.

Destination

A Destination is an interface which is used consistently through Knative Eventing to reference an event delivery destination. A Destination eventually resolves the supplied information to an URL, and may be an absolute URL or relative to an Addressable object reference; it also supports a Kubernetes Service object reference (as a special case). An absolute URL in a Destination may be used to reference cluster-external resources such as a virtual machine or SaaS service.

Definition

Destination
Parameter Description Type Required
ref An ObjectReference to a cluster resource Reference no
uri A URL (possibly relative to ref) string no
Reference
Parameter Description Type Required
apiVersion ApiVersion of the target reference. string yes
kind Kind of the target reference. string yes
name Name of the target reference. string yes
namespace Namespace of the target resource. If unspecified, defaults to the same namespace string no

Resolution

The resolution of a Destination into a URI string follows these steps:

  1. When ref exists, the base URL is resolved as follows:
    1. When apiVersion is v1 and kind is Service then the resolved base URL is http://<name>.<namespace>.svc.<clusterDomainName>
    2. Otherwise the revolved base URL is the address stored in status.address.url on the object identified by apiVersion, kind, name and optionally namespace fields
  2. When ref does not exist, the base URL is empty.
  3. When uri exists
    1. Raise an error when the base URL is not empty and uri is absolute
    2. When ref does not exist, the resolved URL is uri
    3. Otherwise the resolved URL is concatenation of the base URL and uri, as described here (find link)

Examples

Service Invocation







- name: processOrder
  operation: knative:services.v1.serving.knative.dev/[default]/processOrder/init
  type: custom
  metadata:
    asCloudEvent: false
    path: /init

Sending Event
















functions:
- name: processOrder
  operation: knative:brokers.v1.eventing.knative.dev/mybroker?asCloudEvent=true
  type: custom
states:
- name: send event
  type: operation
  actions:
    functionRef:
      refName: processOrder
      arguments:
        type: com.hospital.patient.heartRateMonitor
        source: hospitalMonitorSystem
        id: ${ }
        data: ${ . }

Runtime Contract

What Knative expects in the request and error handling.

Resources

References

Select a repo