As mentioned in four points above, Nuclio allows developers to switch event sources and data sources, and provide event simulation without changing function code. Each function will be packaged by language runtime, which could be Python, Go, Java, or C#. Nuclio utilizes processor service to integrate event and data sources, and use supporting platform API to perform function logging, monitoring, and configuration, in order to resolve the above mentioned serverless issues.
In order to clearly illustrate the remaining Nuclio services described in Figure 3, we need to understand how Nuclio constructs and deploys functions. Figure 4 incdicates the entire CI/CD process of Nuclio’s function from development to deployment. If we take K8s as an example, developers’ function code will automatically run Docker Build Image by using Builder Service, Nuclio CLI with runtime Yaml, integrate the Processor Base Image with function and runtime, build the processor-function Image of the function and send it to the specified repository/artifact, or generate binary file for local regression testing.
As for CI/CD, when image is completely built and saved in repo successfully, controller service will be used, as illustrated in Figure 5 above, to automatically allocate K8s CLI to generate K8s deploy and svc, utilize K8s CRD to customize function type that enables users to manage function by using K8s CLI. Eventually, when that pod is running, we can use K8s function pod (Function Instance illustrated in Figure 4 above), which is triggered and specified by Nuclio CLI. Since these function pods are running on K8s, controllers will receive event sources to invoke functions, and flexibly manage replica, life cycle, and version of these functions.
In Figure 1 function may receive all kinds of event sources. When source is a set of tasks, such as batch jobs, or stream like Kafka, dealer service is used to distribute these partitions, and to ensure all tasks are finished successfully. In Figure 5 above, dealer will divide the received jobs or stream into N smaller Tasks, and allocate these partitions to processor service of Nuclio.
Meanwhile, Nuclio provides dashboard service. It is an additional and independent microservice, which enables developers to use web GUI via HTTP to write and configure functions, and set up events and data binding. This provides developers a friendly user interface for function deployment and testing.
Please correspond the text in red in Figure 5 above to the following Figure 6 shown below:
Nuclio installation (on K8s)
Create Nuclio K8s namespace
Create a registry secret. Local registry can be used. Simply modify the following registry.hub.docker.com. The registry here is Docker hub. Its secret is required by the following image for automatic uploading. Please modify username, password, and email of Docker hub personal information accordingly.
Create the RBAC roles
In order to enable external machine to open Nuclio dashboard, expose dashboard SVC here. Change type:ClusterIP into type:NodePort, and then save and exit it.
View exposed port of dashboard
Open browser and link to http://k8s-any-node-ip:32480
Nuclio Function Deployment and triggering
Download the latest Nuclio CLI: Release Page
Modify CLI for local use
Since testing demonstrates that if not logging in Docker hub ahead of time, image may fail to be successfully uploaded to Docker hub (denied: requested access to the resource is denied) during deploying the function by using Nuctl. This issue can be solved later, after logging in to Docker hub in advance.
Deploy Hello World example code
View function deployment status
Meanwhile, the following code can obtain Triggering event information (Python 3):
Click Project name: test, view the port of Invocation URL
Or use kubectl to view NodePort of svc of function. use HTTP POST to trigger function. The following IP can be any Node IP of K8s Cluster. Port is NodePort.
The Pod log of that function. It displays the information of Event body size and context.logger.debug