下面介绍如何在 Kyma 控制台里扩展新的 UI.

方法是创建一个新的resource，类型为ClusterMicroFrontend.

使用命令行kubectl get ClusterMicroFrontend查看这些UI扩展：

最后自定义的UI出现在Kyma console的这个位置：

下面我们详细分析 Kyma Lambda Function 的技术实现细节。

我在Kyma上创建了一个名为zjerry-lambda的函数，基于nodejs8：

可以直接在Kyma的测试控制台里调用这个Lambda Function：

Serverless的字面意思，不是暗示我们没有服务器了吗？那么这段函数代码到底运行在哪里的？

因为SAP Kyma是基于Kubernetes的，因此我们还是可以通过Kubernetes提供的一些工具，来探索SAP Kyma上Lambda Function运行原理的一些蛛丝马迹。

首先找到zjerry-lambda函数创建后，对应生成的pod，把名字抄下来：zjerry-lambda-86668f75d4-pfbk6

使用kubectl的交互式参数-ti，进入这个pod内部：

kubectl exec -ti zjerry-lambda-86668f75d4-pfbk6 -n ctu-demo -- /bin/sh

进入之后，查看进程列表，发现了node kubeless这个进程，Jerry顿时觉得有点眉目了：

看样子，SAP Kyma的Lambda Function是通过一个node进程执行的。查看一下这个pod里都有哪些文件：

打开kubeless.js看看里面的内容：

如果您是一位nodejs开发人员，看到上面Jerry高亮的红色内容，一定会恍然大悟。SAP Kyma的Lambda Function，其实运行在对应的Kubernetes pod里启动的express应用框架上。

Express的依赖定义在pod内部的package.json里：

而待执行的Lambda Function逻辑，通过环境变量FUNC_HANDLER进行注入，在Jerry这个例子里，函数体名称为main：

在Lambda Function的Serverless框架，即kubeless.js运行时，会从pod内部的kubeless这个文件夹里，找到应用开发人员编写的Lambda Function，加载并运行。

大家可以看到，Jerry红色高亮的位于pod内部的handler.js, 其内容就是Kyma控制台里编写的函数体。

至此，SAP Kyma的Lambda Function实现，在Jerry眼中没有任何神秘可言了。回到Serverless这个术语本身，并不意味着整个场景里不再需要服务器的参与，而是服务器的这个关注点，在Serverless架构下，已经从应用开发人员的视角中隐藏起来罢了。

总结

本文首先介绍了在云原生平台 Kyma 上创建 Lambda Function 的详细步骤，接着深入分析了 Kyma Lambda Function 的实现原理，希望对希望了解 Lambda Function 幕后实现细节的云原生开发人员有所帮助。