欢迎访问 OpenFunction

• 1: 入门
• 2: 概念术语
• 2.1: Function
• 2.2: Builder
• 2.3: Serving
• 2.4: EventSource
• 2.5: EventBus（ClusterEventBus）
• 2.6: Trigger
• 3: 开发 & 贡献指南
• 3.1: 快速上手
• 3.2: 开发流程
• 3.3: Pull Request 流程
• 4: 参考资料
• 4.1: Function 参数说明
• 4.2: EventSource 参数说明
• 4.2.1: Redis 参数说明
• 4.2.2: Kafka 参数说明
• 4.2.3: Cron 参数说明
• 4.3: EventBus 参数说明
• 4.3.1: Nats Streaming 参数说明
• 4.4: Trigger 参数说明
• 5: 路线图
• 6: 最佳实践
• 6.1: 使用 SkyWalking 为 OpenFunction 提供可观测能力

1 - 入门

概述

OpenFunction 是一个云原生、开源的 FaaS（函数即服务）框架，旨在让开发人员专注于他们的开发意图，而不必关心底层运行环境和基础设施。用户只需提交一段代码，就可以生成事件驱动的、动态伸缩的 Serverless 工作负载。

OpenFunction的特点：

• 云原生，开源
• 自动构建代码为 OCI 标准镜像
• 自动部署具有动态伸缩能力的应用程序
• 提供事件框架，使函数具备事件驱动能力
• 提供函数版本控制和入口流量管理功能

OpenFunction有两个主要框架：

• 由 CustomResourceDefinitions（CRD）Function、Builder、Serving 提供支持的无服务计算（Serverless）框架
• 由 CustomResourceDefinitions（CRD）EventSource、EventBus (ClusterEventBus)、Trigger 提供支持的事件管理框架

兼容性

Kubernetes 兼容性矩阵

我们对下列版本进行了测试验证，以确保他们可以按照所示的对应关系正常运行。但请注意，使用其他版本也可能正常运行！

前提准备

当前版本的 OpenFunction 要求你有一个版本为 等于或高于 1.18.6 的 Kubernetes 集群。

此外，你需要为 OpenFunction 的 Builder 和 Serving 部署一些依赖项。

你可以使用以下命令来安装 OpenFunction 的 Builder 和 Serving：

sh hack/deploy.sh --all

这个命令将安装 Builder 和 Serving 的所有依赖项到你的集群中。

你也可以用以下参数来定制安装的依赖软件。

安装

你可以使用以下命令安装 OpenFunction：

• 安装最新稳定版本

kubectl create -f https://github.com/OpenFunction/OpenFunction/releases/download/v0.4.0/bundle.yaml

• 安装最新开发版本

kubectl create -f https://raw.githubusercontent.com/OpenFunction/OpenFunction/main/config/bundle.yaml

注意：当使用非默认的命名空间时，确保命名空间中的 ClusterRoleBinding 是匹配的。

案例：运行一个简单函数

如果你已经安装了 OpenFunction，推荐参考 OpenFunction samples 运行一个函数案例。

卸载

• 卸载最新的稳定版本

kubectl delete -f https://raw.githubusercontent.com/OpenFunction/OpenFunction/release-0.4/config/bundle.yaml

• 卸载最新的开发版本

kubectl delete -f https://raw.githubusercontent.com/OpenFunction/OpenFunction/main/config/bundle.yaml

2 - 概念术语

2.1 - Function

Function 是直接由使用者定义、控制的资源，它是使用者对其业务应用的一段描述，即用何种原料（源代码）加工成何种制品（应用镜像），最终又将以何种方式运作（工作负载、运行时）。

在 OpenFunction 中，Function 资源会根据配置有序控制 Builder 和 Serving 资源的协调过程，进而实现使用者函数的生命周期管理。

参考

Function 是一种 CustomResourceDefinitions（CRD）。你可以访问 Function CRD Spec 了解更多信息。

2.2 - Builder

Builder 定义了 OpenFunction 中由源代码生成应用镜像的构建工作。

当前，OpenFunction Builder 使用 Shipwright 和 Cloud Native Buildpacks 来构建应用镜像。它通过 Shipwright 控制应用镜像的构建过程，包括通过 Cloud Native Buildpacks 获取代码、生成镜像制品和发布镜像。

支持的构建器

• OpenFunction Builder
• GoogleCloudPlatform Builder
• Paketo Builder

Shipwright

Shipwright 是一个可扩展的镜像流水线框架，用于在 Kubernetes 上构建容器镜像。

Cloud Native Buildpacks

Cloud Native Buildpacks 是一个 OCI 标准的镜像构建框架，无需 Dockerfile 即可根据自定义步骤（buildpack）将源代码转化为容器镜像制品。

参考

Builder 是一种 CustomResourceDefinitions（CRD）。你可以访问 Builder CRD Spec 了解更多信息。

2.3 - Serving

Serving 的目标是以高度弹性的方式（动态伸缩：0 <-> N）为使用者运行应用负载。

当前，OpenFunction Serving 支持两种负载运行时：Knative 和 OpenFuncAsync。设置其中一种负载运行时之后，Serving 才能正常工作。

Knative

Knative Serving 建立在 Kubernetes 之上，支持部署和运行 Serverless 应用。Knative Serving 很容易上手，并可延伸支持复杂的应用场景。

OpenFuncAsync

OpenFuncAsync 是一个事件驱动的负载运行时。它基于 KEDA 与 Dapr 实现。OpenFuncAsync 负载的函数可以由各类事件、消息触发，如 MQ、cronjob、DB 事件等。在 Kubernetes 集群中，OpenFuncAsync 负载的函数可以通过无状态工作负载或任务的形式运行。

参考

Serving 是一种 CustomResourceDefinitions（CRD）。你可以访问 Serving CRD Spec 了解更多信息。

2.4 - EventSource

EventSource 代表一个事件的生产者，如 Kafka 服务器、对象存储服务，也可以是一个应用。它包含这些事件生产者的定义，以便于从这些生产者处获取事件。它同时定义了这些事件将去往何处。

支持的事件源

• Kafka
• Cron (scheduler)
• Redis

参考

EventSource 是一种 CustomResourceDefinitions（CRD）。你可以访问 EventSource CRD Spec 了解更多信息。

2.5 - EventBus（ClusterEventBus）

EventBus 负责聚合事件并持久化事件。

EventBus 包含对事件总线后端服务的描述（通常是一个消息服务器，如 NATS Streaming、Kafka 等），然后为 EventSource 和 Trigger 提供这些配置（让它们可以从事件总线中获取事件）。

EventBus 默认负责 namespace scope 的事件总线适配，同时我们也为 cluster scope 提供了一个事件总线适配器 ClusterEventBus ，它将在命名空间中不存在 EventBus 时生效。

支持的事件总线服务器

• NATS Streaming

参考

EventBus 是一种 CustomResourceDefinitions（CRD）。你可以访问 EventBus CRD Spec 了解更多信息。

2.6 - Trigger

Trigger 是对事件目的的抽象，即在收到一个消息时需要做什么。

Trigger 包含了使用者对事件目的的描述，它指导 Trigger 应该从哪些事件源获取事件，随后根据给定的条件决定是否触发目标函数。

参考

Trigger 是一种 CustomResourceDefinitions（CRD）。你可以访问 Trigger CRD Spec 了解更多信息。

3 - 开发 & 贡献指南

3.1 - 快速上手

前提准备

如果你对开发控制器、管理器感兴趣，请参阅 sample-controller 和 kubebuilder。

Go

OpenFunction 基于 Kubernetes。它们都是用 Go 编写的。如果你没有 Go 开发环境，请先 设置 Go 开发环境。

提示：

• 确保你的 GOPATH 和 PATH 已经按照 Go 环境说明进行了配置。
• 在使用 MacOS 进行开发时，建议安装 macOS GNU tools。

Docker

OpenFunction 组件通常在 Kubernetes 中以容器方式部署。如果你需要在 Kubernetes 集群中部署 OpenFunction 组件，你需要提前 安装 Docker。

依赖管理

OpenFunction 使用 Go Modules 管理依赖包。

制作镜像 & 运行

你可以通过修改 cmd/Dockerfile 来为你的本地环境制作 openfunction 镜像。

将镜像上传到你的个人镜像仓库后，在工作负载（Deployment）openfunction-controller-manager 中改变 openfunction 容器的镜像为你的个人镜像。

kubectl edit deployments.apps -n openfunction openfunction-controller-manager

保存后，Kubernetes 将自动应用新的镜像运行工作负载。

3.2 - 开发流程

步骤1. Fork

1. 访问 https://github.com/OpenFunction/OpenFunction
2. 点击 “Fork” 按钮，在你的 GitHub 账户中创建一个 fork 项目。

步骤2. 克隆 fork 项目至本地

Per Go’s workspace instructions, place OpenFunction code on your GOPATH using the following cloning procedure.

根据 Go 的 workspace instructions，使用以下克隆工序将 OpenFunction 代码放在你的 GOPATH 上。

定义一个本地目录：

export working_dir=$GOPATH/src/openfunction.io
export user={your github profile name}

将代码克隆到本地：

mkdir -p $working_dir
cd $working_dir
git clone https://github.com/$user/OpenFunction.git
cd $working_dir/OpenFunction
git remote add upstream https://github.com/OpenFunction/OpenFunction.git

# Never push to upstream master
git remote set-url --push upstream no_push

# Confirm your remotes make sense:
git remote -v

步骤3. 保持与上游分支的同步

git fetch upstream
git checkout main
git rebase upstream/main

步骤4. 增加新特性或补丁

从 master 中创建一个新分支：

git checkout -b myfeature

然后在 myfeature 分支上开发代码。参考 effective_go 有助于你的编码。

测试与构建

目前，make 规则只包含简单的检查，如 vet、unit 测试，很快会加入 e2e 测试。

使用 KubeBuilder

• 对于 Linux 操作系统，你可以下载并执行这个 KubeBuilder脚本。
• 对于 MacOS，你可以按照这个 指南 来安装 KubeBuilder。

运行与测试

make all
# Run every unit test
make test

运行 make help 以获得关于 make 的额外信息。

步骤5. 开新分支开发

与上游分支同步

测试完成后，让你本地的代码与上游分支保持同步有助于避免冲突。

# Rebase your master branch of your local repo.
git checkout main
git rebase upstream/main

# Then make your development branch in sync with master branch
git checkout new_feature
git rebase -i main

提交本地变化

git add <file>
git commit -s -m "add your description"

步骤6. 推送至你的 fork 仓库

当准备好审查时（或者只是为了建立一个异地的工作备份），把你的本地分支推送到 GitHub 上的 fork 仓库。

git push -f ${your_remote_name} myfeature

步骤7. 创建一个 PR

• 访问你在 GitHub 上的 fork 仓库 https://github.com/$user/OpenFunction
• 点击你的 myfeature 分支旁的 Compare & Pull Request 按钮
• 请查看 pull requests 流程，了解更多细节和建议

3.3 - Pull Request 流程

本文档演示了向 OpenFunction 项目 提交 PR 的过程和最佳实践。它可以为所有贡献者（尤其是新接触或不经常提交 PR 的开发者）提供有价值的参考。

• 在提交 PR 之前
  • 运行本地验证
• PR 的提交流程
  • 如有需要，编写 Release notes
  • 测试与合并工作流
  • 标记未完成的 Pull Requests

在提交 PR 之前

本指南是为已经有 PR 要提交的贡献者准备的。如果你正在寻找关于如何搭建你的开发环境以及如何为 OpenFunction 贡献代码的信息，请参见 开发指南 。

确保你的 PR 符合我们的最佳实践。这包括遵循项目惯例，提交小型 PR，以及全面地进行评论。请阅读本文件末尾关于加快评审的最佳实践的更详细章节。

运行本地验证

你可以在提交 PR 之前运行这些本地验证，以预测持续集成的通过或失败。

PR 的提交流程

合并一个 PR 需要在自动合并 PR 之前完成以下步骤。关于每个步骤的细节，请参见下面的测试和合并工作流程部分。

• 生成 PR
• Release notes – 包含以下一项：
  • 在 release notes 中添加说明，或
  • 上传 release notes 的标签
• 通过所有测试
• 从 reviewer 处获得一个 /lgtm 标签
• 从 owner 处获得一个 approval

如果你的 PR 符合上述所有步骤，它将进入提交队列被合并。当它成为下一个被合并的队列时，测试将运行第二次。如果所有的测试都通过了，PR 将被自动合并。

如有需要，编写 Release notes

任何带有用户可见变化的 PR 都需要 release notes，例如错误修复、功能添加和输出格式变化。

如果你不在 PR 模板中添加 release notes，那么在你创建 PR 后，“do-not-merge/release-note-label-needed” 的标签会自动添加到你的 PR 中。有几种方法可以更新它。

在 PR 描述中增加一个 release-note 部分。

对于有 release notes 的 PR：

```release-note
Your release note here
```

对于需要用户在切换到新版本时采取额外操作的 PR，请在发布说明中加入 “action required” 的字符串（不区分大小写）：

```release-note
action required: your release note here
```

对于不需要在发布时提及的 PR，只需写上 “NONE”（不区分大小写）：

```release-note
NONE
```

/release-note-none 注释命令仍然可以用来替代在 release-note 块中写 “NONE”，如果它留空的话。

要了解如何格式化您的 release notes，请查看 PR 模板 以了解一个简单的例子。PR 的标题和正文注释可以在发布前的任何时候进行修改，以使其对发布注释友好。 // PR template TODO

Release notes 适用于主分支上的 PR 。对于 cherry-pick PR，请参阅 cherry-pick instructions 。这些规则的唯一例外是，当一个 PR 不是 cherry-pick，而是直接针对非主干分支时。 在这种情况下，非主分支 PR 需要一个 release-note-* 标签。

// cherry-pick TODO

现在你的 release notes 已经成型了，让我们看看 PR 是如何被测试和合并的。

测试与合并工作流

OpenFunction 的合并工作流程使用注释来运行测试和标签来合并 PR。

注意：对于正在进行但尚未准备好接受审查的拉动请求，在 PR 标题前加上 “WIP” 或 “[WIP]”，并在 pull requests 描述中的检查清单中跟踪任何剩余的 TODO。

以下是 PR 从提交到合并的过程：

1. 生成 pull request
2. @o8x-merge-robot 分配 reviewer //TODO

如果你 不是 的 OpenFunction 组织的成员：

1. Reviewer/OpenFunction 成员检查 PR 是否可以安全测试。如果是的话，他们会评论 /ok-to-test。
2. Reviewer 建议编辑
3. 提交编辑至你的 PR 分支
4. 重复最先的两个步骤
5. （可选）一些 reviewer 希望你在这一步合并（squash）提交的内容
6. Owner 被安排处理这次合并，并将在 PR 上添加 /approve 标签

如果你是一个项目的成员，或者一个评论了 /ok-to-test 的成员，该 PR 将被认为是可信的。然后提交前的测试就会运行：

1. 自动测试运行。参见 PR 上的当前测试列表
2. 如果测试失败，通过向你的 PR 分支推送编辑来解决问题
3. 如果失败是偶然的，任何受信任的 PR 上的人都可以评论 /retest 来重新运行失败的测试

一旦测试通过，所有的失败都被评论为偶然的，或者评审员添加了 lgtm 和 approved 标签，PR 就进入了最后的合并队列。合并队列是必须的，以确保在你的 PR 上最后一次运行测试后，其他 PR 没有引入不兼容的变化。

1. 该 PR 进入合并队列
2. 合并队列触发了一个测试的重新运行，注释为 /test all [submit-queue 正在验证这个 PR 是否可以安全合并]。 2.1. 作者已经签署了 CLA（cncf-cla: yes 标签添加到 PR）。 2.2. 自上次应用 lgtm 标签以来，没有做出任何改变
3. 如果测试失败，通过向你的 PR 分支推送编辑来解决问题
4. 如果失败是偶然的，任何受信任的 PR 上的人都可以评论 /retest 来重新运行失败的测试
5. 如果测试通过，合并队列将自动合并 PR

这就是最后一步了。你的 PR 现在被合并了。

标记未完成的 Pull Requests

如果你想在你的 pull requests 执行完成之前征求评论，你应该保留你的 pull requests，以确保合并队列不会试图合并它。有两种方法可以实现这一点。

1. 你可以添加 /hold 或 /hold cancel 的注释命令
2. 你可以在你的 pull requests 标题中添加或删除 WIP 或 [WIP] 前缀

当你使用评论命令时，GitHub 机器人会添加和删除 do-not-merge/hold 标签，当你编辑标题时，会添加和删除 do-not-merge/work in-progress 标签。当这两个标签存在时，你的 pull requests 将不被考虑合并。

4 - 参考资料

v1alpha1

core.openfunction.io/v1alpha1，包含：

• functions.core.openfunction.io

events.openfunction.io/v1alpha1，包含：

• eventsources.events.openfunction.io
• eventbus.events.openfunction.io
• clustereventbus.events.openfunction.io
• triggers.events.openfunction.io

4.1 - Function 参数说明

Function

FunctionSpec

从属 Function

BuildImpl

从属 FunctionSpec

ShipwrightEngine

从属 BuildImpl

Strategy

从属 ShipwrightEngine

GitRepo

从属 BuildImpl

ServingImpl

从属 FunctionSpec

OpenFuncAsyncRuntime

从属 ServingImpl

Dapr

从属 OpenFuncAsyncRuntime

DaprComponent

从属 Dapr

DaprSubscription

从属 Dapr

DaprIO

从属 Dapr

Keda

从属 OpenFuncAsyncRuntime

KedaScaledObject

从属 Keda

你可以参考 Scaling Deployments, StatefulSets & Custom Resources 获得更多信息

KedaScaledJob

从属 Keda

你可以参考 Scaling Jobs 获得更多信息

4.2 - EventSource 参数说明

EventSource

EventSourceSpec

从属 EventSource

SinkSpec

从属 EventSourceSpec

Reference

从属 SinkSpec

引用资源一般为 Knative Service

GenericScaleOption

从属 scaleOption

4.2.1 - Redis 参数说明

RedisSpec

从属 EventSourceSpec

EventSource 会根据 RedisSpec 生成用于适配 Redis 事件源的 Dapr Bindings Components ，原则上我们会尽量维持相关参数的一致性。你可以通过访问 Redis binding spec 获取更多信息。

4.2.2 - Kafka 参数说明

KafkaSpec

从属 EventSourceSpec

EventSource 会根据 KafkaSpec 生成用于适配 Kafka 事件源的 Dapr Bindings Components ，原则上我们会尽量维持相关参数的一致性。你可以通过访问 Kafka binding spec 获取更多信息。

KafkaScaleOption

从属 KafkaSpec

4.2.3 - Cron 参数说明

CronSpec

从属 EventSourceSpec

EventSource 会根据 CronSpec 生成用于适配 Cron 事件源的 Dapr Bindings Components ，原则上我们会尽量维持相关参数的一致性。你可以通过访问 Cron binding spec 获取更多信息。

4.3 - EventBus 参数说明

EventBus(ClusterEventBus)

EventBusSpec

从属 EventBus

GenericScaleOption

从属 scaleOption

4.3.1 - Nats Streaming 参数说明

NatsStreamingSpec

从属 EventBusSpec

EventBus（ClusterEventBus） 会将配置提供给 EventSource 和 Trigger 引用，以便生成对应的 Dapr Pub/Sub Components 从事件总线处获取消息，原则上我们会尽量维持相关参数的一致性。你可以通过访问 NATS Streaming pubsub spec 获取更多信息。

NatsStreamingScaleOption

从属 NatsStreamingSpec

4.4 - Trigger 参数说明

Trigger

TriggerSpec

从属 Trigger

Input

从属 TriggerSpec

Subscriber

从属 TriggerSpec

SinkSpec

从属 Subscriber

Reference

从属 SinkSpec

引用资源一般为 Knative Service

5 - 路线图

v0.1.0，2021年5月

• Create Function, Builder and Serving CRDs and corresponding controllers

• Support using existing function framework & buildpacks such as Google Cloud Function to build functions

• Support using Tekton and Cloud Native Buildpacks as Builder backend to build functions

• Support Knative as Serving backend

• Optimize and localize existing function framework & buildpacks

v0.2.0，2021年6月

• Support OpenFunctionAsync serving runtime（backed by Dapr + KEDA + Deployment/Job)
• Functions Frameworks async function support
• Customized go function framework & builders for both Knative and OpenFunctionAsync serving runtime

v0.3.0，2021年7~8月

• Add OpenFunction Events: OpenFunction’s own event management framework
• Support using ShipWright as Builder backend to build functions or apps
• Build and serving can be launched separately
• Support running an application (container image) as a serverless workload directly

v0.4.0+，2021年Q4

• OpenFunction CLI
• Support more EventSources
• Use OpenFunction async functions to drive EventSource & EventTrigger workloads
• OpenFunction sync function
• Python functions frameworks & builder
• Nodejs functions frameworks & builder
• OpenFunction Console (WebUI)
• Support scheduling functions to Edge
• Use ShipWright to build functions or apps with Dockerfile.
• Support Rust functions & WebAssembly runtime.

6 - 最佳实践

6.1 - 使用 SkyWalking 为 OpenFunction 提供可观测能力

功能概览

尽管 FaaS 允许开发者专注于他们的业务代码而不用担心底层的实现，但对函数服务进行功能调试和故障排除是很困难的。因此，OpenFunction 设法引入了可观测性能力来提高其可用性和稳定性。

SkyWalking 提供了在许多不同场景下观测和监控分布式系统的解决方案。OpenFunction 将 go2sky（SkyWalking 的 Go 语言代理）捆绑在 OpenFunction 追踪器选项中，以提供分布式追踪、函数性能统计和函数依赖关系图。

先决条件

• 您已安装了 OpenFunction。
• 您已创建了一个 Kubernetes Secret。
• 您已安装了 SkyWalking v9。
• 您已创建了一个 Kafka 服务和主题。

追踪功能的可配置参数

下表描述了 OpenFunction 中目前可用的追踪参数。

下面是一个 JSON 格式的配置参考，您可以基于此了解追踪配置的大致数据格式。

{
  "enabled": true,
  "provider": {
    "name": "skywalking",
    "oapServer": "skywalking-oap:11800"
  },
  "tags": {
    "func": "function-a",
    "layer": "faas",
    "tag1": "value1",
    "tag2": "value2"
  },
  "baggage": {
    "key": "key1",
    "value": "value1"
  }
}

启用 OpenFunction 的追踪功能

选项一：全局配置

下文使用 skywalking-oap.default:11800 作为集群中 skywalking-oap 服务的样例地址。

1. 运行下面的命令，修改 openfunction 命名空间中的 ConfigMap openfunction-config。

   kubectl edit configmap openfunction-config -n openfunction
   

2. 参照下面的例子修改 data.plugins.tracing 中的内容，并保存这个修改。

   data:
     plugins.tracing: |
       enabled: true
       provider:
         name: "skywalking"
         oapServer: "skywalking-oap:11800"
       tags:
         func: tracing-function
         layer: faas
         tag1: value1
         tag2: value2
       baggage:
         key: "key1"
         value: "value1"    
   

选项二：函数级别配置

要在函数级别启用跟踪配置，请在函数清单的 metadata.annotations 下添加 plugins.tracing 字段，如下所示。

metadata:
  name: tracing-function
  annotations:
    plugins.tracing: |
      enabled: true
      provider:
        name: "skywalking"
        oapServer: "skywalking-oap:11800"
      tags:
        func: tracing-function
        layer: faas
        tag1: value1
        tag2: value2
      baggage:
        key: "key1"
        value: "value1"      

建议您使用全局跟踪配置，否则您必须为您创建的每个函数逐一添加函数级跟踪配置。

使用 SkyWalking 作为分布式追踪解决方案

1. 通过参考 本文档 创建函数。

2. 然后，您可以在 SkyWalking UI 界面上观察整个函数调用的链路。

   

3. 您还可以比较 Knative 运行时函数（function-front）在运行状态和冷启动时的响应时间。

   在冷启动时:

   

   在运行状态下: