Mapping between OpenWhisk and Knative objects

Actions

wsk action create myAction my_action.js

• kwsk server

  • Kubernetes API server

    • create service.serving.knative.dev:myaction

      • create configuration.serving.knative.dev:myaction

        • create revision.serving.knative.dev:myaction-00001

      • create route.serving.knative.dev:myaction

wsk action get myAction

• kwsk server
  • Kubernetes API server
    • get serving.serving.knative.dev:myaction

wsk action invoke myAction

• kwsk server
  • POST -H "Host: myAction" knative-ingressgateway/init
    • calls /init in the action runtime container
  • POST -H "Host: myAction" knative-ingressgateway/run
    • calls /run in the action runtime container

Note that this is considered a temporary flow until Knative Builds are wired up and OpenWhisk functions get built into a container image with some of the init and run logic built-in. Then, invoking an action should just be a matter of passing the invoke payload directly to the Knative Route.

Triggers

wsk trigger create myTrigger

• kwsk server
  • Kubernetes API server
    • create channel.channels.knative.dev:mytrigger

wsk trigger get myTrigger

• kwsk server
  • Kubernetes API server
    • get channel.channels.knative.dev:mytrigger

wsk trigger fire myTrigger

• kwsk server
  • POST mytrigger-channel.foo.svc.cluster.local

Rules

wsk rule create myRule myTrigger myAction

• kwsk server
  • Kubernetes API server
    • create subscription.channels.knative.dev:myrule, specifying
            Channel of mytrigger and Subscriber of
            myaction.internal.dns.name