Kyma Hands-On – Part 3

Welcome to the third part of my Kyma Hands-On series.

This series shares my learning outcomes of exploring Kyma first-hand. It aims to enable anyone interested in Kyma by sharing the steps I took, the lessons I learned, and the tips I gathered.

If you haven’t already, please also check out part 1 and part 2 of the series.

In the previous post, I shared my experience learning about the Application Connector component of Kyma. In the same post, I also mentioned how I purposely avoided steps related to eventing so that it can be covered at another time. Well, this is it! I felt it was natural to dig into this topic as it fits well with how we left things off last time.

At a high level, an event mesh can be defined as a layer of infrastructure that delivers events to any applications in any environment. Kyma offers this component to let users connect events from an external source and enable serverless computing using Knative eventing powered by Istio Service Mesh.

Let’s go back to the previous blog post where I followed the WordPress article to register an external API. Instead of ending the steps with creating a custom Deploymentresource, I am going to use the same setup to trigger a function by an event. To keep it continuous with the previous post, I am going to assume that you have completed all the steps of deploying the WordPress application, enabling the Kyma plugin, and have the service registered with the Service Catalog. If this is not the case, please follow the Build a cloud-native extension for WordPress blog post to set up your environment before continuing.

Create a Function that Triggers Based on an Event

What I want to achieve here is when an action is triggered from an external application, WordPress, Kyma receives an event and a Function is triggered based on its subscription. Achieving this requires a WordPress application to be registered as a Service in the Service Catalog (Steps covered in the last blog post). Then, only two other custom resource creations are required: a Function and a Trigger.

A high-level overview of the steps I took for the eventing are listed below
1. Create a Function
2. Create a Trigger for the Function
3. Send an event by posting a comment on the WordPress Hello World blog post

?Lessons Learned

1. A Function must be written in JavaScript and takes an event and a context as parameters.

• An event parameter represents the event that caused the function to be invoked
• A context parameter represents properties related to the function and the environment information

2. A Function can be called using APIRules, Triggers, and/or Service Bindings.

• APIRule allows Function to be exposed externally. This means that the Function can be a standalone service that gets called without being attached to an event.
• Trigger allows Function to be called by an event trigger. This means that the Function is not externally exposed and is only accessible by the trigger.
• Service Binding allows Function to be bound to a Service. This means that the Function is available for only that specific application and a secret with application environment variables are created to be used by the Function.

3. Kyma console provides a space for you to type out the function logic in a user-friendly way than adding it to a yaml file. If you don’t have access to an IDE, this might be a good alternative. However, it doesn’t provide you with the option of testing your code.

4. As described in the architecture diagram, when a Function is created, it creates a ConfigMap, a Job, a Deployment, a Service, and a HorizontalPodAutoscaler

• ConfigMap contains your code
• Job creates a docker image based on the code and pushes to a Docker registry
• Deployment with the Function image created by the Job is created
• Service for the Deployment is created

5. As mentioned in the previous blogpost, creating an Application custom resource creates resources for eventing by default. Kyma will take care of creating all resources related to an application so that when necessary, the eventing component can be utilized. One resource that is important to note is the creation of the Broker. An event is sent to the Broker and is forwarded to a Subscriber, which in this example is the Function.

?Tips

1. There are two subscriptions resources in the Kyma environment. Use the following code to list either Knative or Kyma subscription resources.

kubectl get subscriptions.messaging.knative.dev –all-namespaces
kubectl get subscriptions.messaging.knative.dev –all-namespaces

2. When a Trigger custom resource is created using a yaml file via command line instead of the console, I ran into a problem where Trigger custom resource never became “Ready” and received the following message: “Unable to get the Subscriber’s URI”.

• If creating a Trigger does not work for you, try listing the resource
• I was able to get it working by changing the apiVersion version to v1 instead of serving.knative.dev/v1

3. To fully understand the eventing component of Kyma, general knowledge of Knative is necessary. I recommend a read through Knative eventing documentation to understand what’s happening underneath a bit better!

4. While I don’t want this blog post to become about Knative, I think understanding Broker and Trigger components might be useful. In a very high level, both Broker and Trigger enables the filtering of events.

• A Broker receives events and forward it to the Subscribers based on the Trigger.
• A Trigger allows filtering events and makes sure that Subscriber receives only the event they want.

5. Remember that Knative requires a networking layer to be installed in the cluster. Kyma deploys Istio Service Mesh during installation which gives you the setup required to leverage Knative resources.

6. Following the Trigger a Function with Event that is part of the Application Connector tutorial did not work for me as I received the following error {"code":405,"error":"Method not allowed."} when trying to curl the /v1/events endpoint. Therefore, I used the WordPress blog post to go through the steps necessary to test out the eventing components.

• GitHub issue is open to address this bug
  • Application Connector tutorial unable to hit the events endpoint

7. I recommend writing your own source code for the Function instead of copying and pasting an example from the tutorial. You can always start with simple “Hello World” and add on from there.

module.exports = { 
  main: function (event, context) {
    console.log("Hello World");
    return "Hello World!";
  }
}

?What Have I Learned So Far?

Kyma not only allows to use of any service running outside of the cluster by bringing in the APIs and Events as a service into the cluster, but it also can extend the service by allowing the trigger of serverless functions based on events driven by the external application.

However, not all serverless needs to be triggered by an event either. Allowing the support of serverless in a Kyma environment is a huge plus as it allows developers to forget about the infrastructure layer that is running the code and focus solely on the development of the business logic.

I hope you came to similar conclusions as I have. If you have any feedback on my insights or want to share your insights, I would love to hear from you!

See you in the next post! ?