Expose a Function with an API Rule

This tutorial shows how you can expose your Function to access it outside the cluster, through an HTTP proxy. To expose it, use an APIRule custom resource (CR) managed by the in-house API Gateway Controller. This controller reacts to an instance of the APIRule CR and, based on its details, it creates an Istio VirtualService and Oathkeeper Access Rules that specify your permissions for the exposed Function.

When you complete this tutorial, you get a Function that:

  • Is available on an unsecured endpoint (handler set to noop in the APIRule CR).
  • Accepts the GET, POST, PUT, and DELETE methods.

NOTE: To learn more about securing your Function, see the Expose and secure a workload with OAuth2 or Expose and secure a workload with JWT tutorials.

TIP: Read also about Function’s specification if you are interested in its signature, event and context objects, and custom HTTP responses the Function returns.

Prerequisites

This tutorial is based on an existing Function. To create one, follow the Create a Function tutorial.

Steps

Follow these steps:

  • Kyma CLI
  • kubectl
  • Kyma Dashboard
  1. Export these variables:

    Click to copy
    export DOMAIN={DOMAIN_NAME}
    export NAME={FUNCTION_NAME}
    export NAMESPACE={NAMESPACE_NAME}

    NOTE: The Function takes the name from the Function CR name. The APIRule CR can have a different name but for the purpose of this tutorial, all related resources share a common name defined under the NAME variable.

  1. Download the latest configuration of the Function from the cluster. This way you will update the local config.yaml file with the Function's code.

    Click to copy
    kyma sync function $NAME -n $NAMESPACE
  2. Edit the local config.yaml file and add the apiRules schema for the Function at the end of the file:

    Click to copy
    apiRules:
    - name: {FUNCTION_NAME}
    service:
    host: {FUNCTION_NAME}.{DOMAIN_NAME}
    rules:
    - methods:
    - GET
    - POST
    - PUT
    - DELETE
    accessStrategies:
    - handler: noop
  3. Apply the new configuration to the cluster:

    Click to copy
    kyma apply function
  4. Check if the Function's code was pushed to the cluster and reflects the local configuration:

    Click to copy
    kubectl get apirules $NAME -n $NAMESPACE
  5. Check that the APIRule was created successfully and has the status OK:

    Click to copy
    kubectl get apirules $NAME -n $NAMESPACE -o=jsonpath='{.status.APIRuleStatus.code}'
  6. Call the Function's external address:

    Click to copy
    curl https://$NAME.$DOMAIN