OpenFunction 是一个云原生、开源的 FaaS(函数即服务)框架,旨在让开发人员专注于他们的开发意图,而不必关心底层运行环境和基础设施。用户只需提交一段代码,就可以生成事件驱动的、动态伸缩的 Serverless 工作负载。
欢迎访问 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: 最佳实践
1 - 入门
概述
OpenFunction 是一个云原生、开源的 FaaS(函数即服务)框架,旨在让开发人员专注于他们的开发意图,而不必关心底层运行环境和基础设施。用户只需提交一段代码,就可以生成事件驱动的、动态伸缩的 Serverless 工作负载。
OpenFunction的特点:
- 云原生,开源
- 自动构建代码为 OCI 标准镜像
- 自动部署具有动态伸缩能力的应用程序
- 提供事件框架,使函数具备事件驱动能力
- 提供函数版本控制和入口流量管理功能
OpenFunction有两个主要框架:
- 由 CustomResourceDefinitions(CRD)Function、Builder、Serving 提供支持的无服务计算(Serverless)框架
- 由 CustomResourceDefinitions(CRD)EventSource、EventBus (ClusterEventBus)、Trigger 提供支持的事件管理框架
兼容性
Kubernetes 兼容性矩阵
我们对下列版本进行了测试验证,以确保他们可以按照所示的对应关系正常运行。但请注意,使用其他版本也可能正常运行!
OpenFunction | Kubernetes 1.19 | Kubernetes 1.20 | Kubernetes 1.21 | Kubernetes 1.22 |
---|---|---|---|---|
release-0.3 | √ | √ | √ | √ |
release-0.4 | × | √ | √ | √ |
HEAD | × | √ | √ | √ |
前提准备
当前版本的 OpenFunction 要求你有一个版本为 等于或高于 1.18.6
的 Kubernetes 集群。
此外,你需要为 OpenFunction 的 Builder
和 Serving
部署一些依赖项。
你可以使用以下命令来安装 OpenFunction 的 Builder
和 Serving
:
sh hack/deploy.sh --all
这个命令将安装 Builder
和 Serving
的所有依赖项到你的集群中。
你也可以用以下参数来定制安装的依赖软件。
参数 | 用途说明 |
---|---|
--all | 安装所有 Builder 和 Serving 的依赖软件 |
--with-shipwright | 安装 ShipWright(Builder 的依赖软件) |
--with-knative | 安装 Knative(Serving 的依赖软件) |
--with-openFuncAsync | 安装 OpenFuncAsync(Serving 的依赖软件,包含 KEDA 与 Dapr) |
--poor-network | 用于当你正使用无法有效访问 GitHub/Googleapis 的网络时 |
安装
你可以使用以下命令安装 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 获取代码、生成镜像制品和发布镜像。
支持的构建器
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 服务器、对象存储服务,也可以是一个应用。它包含这些事件生产者的定义,以便于从这些生产者处获取事件。它同时定义了这些事件将去往何处。
支持的事件源
参考
EventSource 是一种 CustomResourceDefinitions(CRD)。你可以访问 EventSource CRD Spec 了解更多信息。
2.5 - EventBus(ClusterEventBus)
EventBus 负责聚合事件并持久化事件。
EventBus 包含对事件总线后端服务的描述(通常是一个消息服务器,如 NATS Streaming、Kafka 等),然后为 EventSource 和 Trigger 提供这些配置(让它们可以从事件总线中获取事件)。
EventBus 默认负责 namespace scope 的事件总线适配,同时我们也为 cluster scope 提供了一个事件总线适配器 ClusterEventBus ,它将在命名空间中不存在 EventBus 时生效。
支持的事件总线服务器
参考
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 开发环境。
Kubernetes | 要求的 Go 版本 |
---|---|
1.18+ | go>=1.12 |
提示:
- 确保你的 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
- 访问 https://github.com/OpenFunction/OpenFunction
- 点击 “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 要提交的贡献者准备的。如果你正在寻找关于如何搭建你的开发环境以及如何为 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 从提交到合并的过程:
- 生成 pull request
@o8x-merge-robot
分配 reviewer //TODO
如果你 不是 的 OpenFunction 组织的成员:
- Reviewer/OpenFunction 成员检查 PR 是否可以安全测试。如果是的话,他们会评论
/ok-to-test
。 - Reviewer 建议编辑
- 提交编辑至你的 PR 分支
- 重复最先的两个步骤
- (可选)一些 reviewer 希望你在这一步合并(squash)提交的内容
- Owner 被安排处理这次合并,并将在 PR 上添加
/approve
标签
如果你是一个项目的成员,或者一个评论了 /ok-to-test
的成员,该 PR 将被认为是可信的。然后提交前的测试就会运行:
- 自动测试运行。参见 PR 上的当前测试列表
- 如果测试失败,通过向你的 PR 分支推送编辑来解决问题
- 如果失败是偶然的,任何受信任的 PR 上的人都可以评论
/retest
来重新运行失败的测试
一旦测试通过,所有的失败都被评论为偶然的,或者评审员添加了 lgtm
和 approved
标签,PR 就进入了最后的合并队列。合并队列是必须的,以确保在你的 PR 上最后一次运行测试后,其他 PR 没有引入不兼容的变化。
- 该 PR 进入合并队列
- 合并队列触发了一个测试的重新运行,注释为
/test all [submit-queue 正在验证这个 PR 是否可以安全合并]
。 2.1. 作者已经签署了 CLA(cncf-cla: yes
标签添加到 PR)。 2.2. 自上次应用lgtm
标签以来,没有做出任何改变 - 如果测试失败,通过向你的 PR 分支推送编辑来解决问题
- 如果失败是偶然的,任何受信任的 PR 上的人都可以评论
/retest
来重新运行失败的测试 - 如果测试通过,合并队列将自动合并 PR
这就是最后一步了。你的 PR 现在被合并了。
标记未完成的 Pull Requests
如果你想在你的 pull requests 执行完成之前征求评论,你应该保留你的 pull requests,以确保合并队列不会试图合并它。有两种方法可以实现这一点。
- 你可以添加
/hold
或/hold cancel
的注释命令 - 你可以在你的 pull requests 标题中添加或删除
WIP
或[WIP]
前缀
当你使用评论命令时,GitHub 机器人会添加和删除 do-not-merge/hold
标签,当你编辑标题时,会添加和删除 do-not-merge/work in-progress
标签。当这两个标签存在时,你的 pull requests 将不被考虑合并。
4 - 参考资料
v1alpha1
core.openfunction.io/v1alpha1,包含:
events.openfunction.io/v1alpha1,包含:
4.1 - Function 参数说明
Function
字段 | 描述 |
---|---|
apiVersion string | core.openfunction.io/v1alpha1 |
kind string | Function |
metadata v1.ObjectMeta | (可选) 参考 v1.ObjectMeta 文档 |
spec FunctionSpec | Function 的规格,参考 FunctionSpec |
status FunctionStatus | Function 的状态,参考 FunctionStatus |
FunctionSpec
从属 Function
字段 | 描述 |
---|---|
version string | (可选) 函数版本,如:“v1.0.0” |
image string | 函数构建后的镜像上传路径,如:“demorepo/demofunction:v1” |
imageCredentials v1.LocalObjectReference | (可选) 访问镜像仓库的凭证,参考 v1.LocalObjectReference |
port int32 | (可选) 函数应用监听的端口,如:“8080” |
build BuildImpl | (可选) 函数的 Builder 规格,参考 BuildImpl |
serving ServingImpl | (可选) 函数的 Serving 规格,参考 ServingImpl |
BuildImpl
从属 FunctionSpec
字段 | 描述 |
---|---|
builder string | 镜像构建器的名称 |
builderCredentials v1.LocalObjectReference | (可选) 访问镜像仓库的凭证,参考 v1.LocalObjectReference |
shipwright ShipwrightEngine | (可选) Shipwright 引擎的规格,参考 ShipwrightEngine |
params map[string]string | (可选) 传递给 Shipwright 的参数 |
env map[string]string | (可选) 传递给镜像构建器的参数 |
srcRepo GitRepo | 源代码仓库的配置,参考 GitRepo |
dockerfile string | (可选) Dockerfile 文件的路径,用于指导 Shipwright 使用 Dockerfile 构建镜像 |
ShipwrightEngine
从属 BuildImpl
字段 | 描述 |
---|---|
strategy Strategy | (可选) 镜像构建策略的名称,参考 Strategy |
timeout v1.Duration | (可选) 镜像构建超时时间,参考 v1.Duration |
Strategy
字段 | 描述 |
---|---|
name string | 镜像构建策略的名称 |
kind string | (可选) 镜像构建策略的 Kind,默认为“BuildStrategy”,可选“ClusterBuildStrategy” |
GitRepo
从属 BuildImpl
字段 | 描述 |
---|---|
url string | 代码仓库地址 |
revision string | (可选) 代码仓库中的可引用实例,如 commit id,branch name 等 |
sourceSubPath string | (可选) 目标函数在代码仓库中的目录,如:“functions/function-a/” |
credentials v1.LocalObjectReference | (可选) 代码仓库的访问凭证,参考 v1.LocalObjectReference |
ServingImpl
从属 FunctionSpec
字段 | 描述 |
---|---|
runtime string | 负载运行时的类型,可选:“Knative” 和 “OpenFuncAsync” |
params map[string]string | (可选) 传递给应用负载的环境变量参数 |
openFuncAsync OpenFuncAsyncRuntime | (可选) 当 runtime 为 OpenFuncAsync 时,用于定义 OpenFuncAsync 的配置,参考 OpenFuncAsyncRuntime |
template v1.PodSpec | (可选) 应用负载中 Pod 的定义模板,参考 v1.PodSpec |
OpenFuncAsyncRuntime
从属 ServingImpl
字段 | 描述 |
---|---|
dapr Dapr | (可选) Dapr components 的定义,参考 Dapr |
keda Keda | (可选) Keda 的定义,参考 Keda |
Dapr
字段 | 描述 |
---|---|
annotations map[string]string | (可选) Dapr components 的注解,参考 Dapr 相关文档 |
components []DaprComponent | (可选) Dapr Components Spec 数组,参考 DaprComponent |
subscriptions []DaprSubscription | (可选) Dapr Subscription Spec 数组,参考 DaprSubscription |
inputs []DaprIO | (可选) 函数输入端的定义,参考 DaprIO |
outputs []DaprIO | (可选) 函数输出端的定义,参考 DaprIO |
DaprComponent
从属 Dapr
字段 | 描述 |
---|---|
name string | Dapr component 的名称 |
v1alpha1.ComponentSpec | Dapr Components Spec 定义,参考 Dapr 相关文档 |
DaprSubscription
从属 Dapr
字段 | 描述 |
---|---|
name string | Dapr components 的注解,参考 Dapr 相关文档 |
v1alpha1.SubscriptionSpec | Dapr Subscription Spec 定义,参考 Dapr 相关文档 |
scopes []string |
DaprIO
从属 Dapr
字段 | 描述 |
---|---|
name string | 函数输入、输出端的名称,与 DaprComponent 的 name 一致即表示关联 |
type string | Dapr component 的类型,可选:bindings 、pubsub 、invoke |
topic string | (可选) 当 type 为 pubsub 时,需要设置 topic |
methodName string | (可选) 当 type 为 invoke 时,需要设置 methodName,参考 Dapr 相关文档 |
params map[string]string | (可选) 传递给 Dapr 的参数 |
Keda
字段 | 描述 |
---|---|
scaledObject KedaScaledObject | KEDA 可扩展对象(Deployments)定义,参考 KedaScaledObject |
scaledJob KedaScaledJob | KEDA 可扩展任务定义,参考 KedaScaledJob |
KedaScaledObject
从属 Keda
你可以参考 Scaling Deployments, StatefulSets & Custom Resources 获得更多信息
字段 | 描述 |
---|---|
workloadType string | 以何种方式运行函数,可选:Deployment 、 StatefulSet ,默认为 Deployment . |
pollingInterval int32 | (可选) pollingInterval 的单位是秒。这是 KEDA 检查触发器的队列长度或流滞后的时间间隔。默认是 30 秒。 |
cooldownPeriod int32 | (可选) cooldownPeriod 也是以秒为单位,它是在最后一个触发器激活后等待的时间段,然后再缩减到 0。 默认是 300 秒。 |
minReplicaCount int32 | (可选) KEDA 在收缩资源的最小副本数。默认情况下为 0 。 |
maxReplicaCount int32 | (可选) KEDA 会将该值传递给为资源创建的 HPA 定义。 |
advanced kedav1alpha1.AdvancedConfig | (可选) 此属性指定在删除 “ScaledObject” 后,目标资源(“Deployments”、“StatefulSet”…)是否应被缩减到原始副本数量。默认行为是保持复制数量与删除 “ScaledObject” 时的数量相同。参考 kedav1alpha1.AdvancedConfig |
triggers []kedav1alpha1.ScaleTriggers | 触发工作负载动态伸缩的事件源,参考 kedav1alpha1.ScaleTriggers |
KedaScaledJob
从属 Keda
你可以参考 Scaling Jobs 获得更多信息
字段 | 描述 |
---|---|
restartPolicy v1.RestartPolicy | 在 pod 内所有容器的重启策略。可选择 OnFailure 、Never 。默认为 Never 。 |
pollingInterval int32 | (可选) pollingInterval 的单位是秒。这是 KEDA 检查触发器的队列长度或流滞后的时间间隔。默认是 30 秒。 |
successfulJobsHistoryLimit int32 | (可选) 应该保留多少个已完成的 Job。默认为 100 。 |
failedJobsHistoryLimit int32 | (可选) 应该保留多少个失败的 Job。默认为 100 。 |
maxReplicaCount int32 | (可选) 在一个轮询周期内可以创建的最大 pod 的数量。 |
scalingStrategy kedav1alpha1.ScalingStrategy | (可选) 选择一个缩放策略。可能的值是 default 、custom 、accurate 。默认值是 default 。参考 kedav1alpha1.ScalingStrategy |
triggers []kedav1alpha1.ScaleTriggers | 触发工作负载动态伸缩的事件源,参考kedav1alpha1.ScaleTriggers |
4.2 - EventSource 参数说明
EventSource
字段 | 描述 |
---|---|
apiVersion string | events.openfunction.io/v1alpha1 |
kind string | EventSource |
metadata v1.ObjectMeta | (可选) 参考 v1.ObjectMeta 文档 |
spec EventSourceSpec | 事件源的规格,参考 EventSourceSpec |
status EventSourceStatus | 事件源的状态 |
EventSourceSpec
从属 EventSource
字段 | 描述 |
---|---|
eventBus string | (可选) 事件源关联的 EventBus 资源名称 |
redis map[string]RedisSpec | (可选) redis 事件源的定义,参考 RedisSpec |
kafka map[string]KafkaSpec | (可选) kafka 事件源的定义,参考 KafkaSpec |
cron map[string]CronSpec | (可选) cron 事件源的定义,参考 CronSpec |
sink SinkSpec | (可选) 事件源关联的 Sink(可寻址的访问资源,即同步请求)定义,参考 SinkSpec |
SinkSpec
字段 | 描述 |
---|---|
ref Reference | 参考 Reference |
Reference
从属 SinkSpec
引用资源一般为 Knative Service
字段 | 描述 |
---|---|
kind string | 引用资源的类型,默认为:Service |
namespace string | 引用资源的命名空间,默认与 Trigger 的命名空间一致 |
name string | 引用资源的名称,如:function-ksvc |
apiVersion string | 引用资源的 apiVersion,默认为:serving.knative.dev/v1 |
GenericScaleOption
从属 scaleOption
字段 | 描述 |
---|---|
pollingInterval int | 检查每个伸缩触发器的时间间隔。默认是30 秒 |
cooldownPeriod int | 在将资源缩减到 0 之前,最后一个伸缩触发器报告激活后的等待时间。 默认为 300 秒 |
minReplicaCount int | KEDA 将收缩资源的最小副本数。默认值是 0 |
maxReplicaCount int | 这个设置被传递给KEDA为特定资源创建的HPA定义,KEDA 扩展资源的最大副本数。 |
advanced kedav1alpha1.AdvancedConfig | 请查看 KEDA 文档 |
metadata map[string]string | KEDA 伸缩触发器的元数据 |
authRef kedav1alpha1.ScaledObjectAuthRef | 你在 TriggerAuthentication 配置中定义的每个参数都不需要包含在你的 ScaledObject 定义的触发器的 metadata 中。要从 ScaledObject 中引用 TriggerAuthentication ,你需要在触发器中添加 authRef ,请参考 KEDA 文档 |
4.2.1 - Redis 参数说明
RedisSpec
EventSource 会根据 RedisSpec 生成用于适配 Redis 事件源的 Dapr Bindings Components ,原则上我们会尽量维持相关参数的一致性。你可以通过访问 Redis binding spec 获取更多信息。
字段 | 描述 |
---|---|
redisHost string | Redis 服务器的地址,如:localhost:6379 |
redisPassword string | Redis 服务器的密码,如:123456 |
enableTLS bool | (可选) 是否启用 TLS 访问,默认为 false 。可选:true ,false |
failover bool | (可选) 是否启用 failover 特性。需要设置 sentinalMasterName 。默认为 false 。可选:true ,false |
sentinelMasterName string | (可选) sentinel master 的名称。参考 Redis Sentinel Documentation 。 |
redeliverInterval string | (可选) 重新发送的时间间隔。默认为 60s 。0 表示禁用重新发送机制。如:30s |
processingTimeout string | (可选) 消息处理超时时间。默认为 15s 。0 表示禁用超时。如:30s |
redisType string | (可选) Redis 的类型。可选:单节点模式的 node ,集群模式的 cluster 。默认为 node |
redisDB int64 | (可选) 连接到 Redis 的数据库索引值。仅在 redisType 为 node 时生效。默认为 0 。 |
redisMaxRetries int64 | (可选) 最大重试次数。默认不重试。如:5 |
redisMinRetryInterval string | (可选) 重试的最小退避时间。默认值是 8ms 。-1 表示禁用退避时间。如:10ms |
redisMaxRetryInterval string | (可选) 重试的最大退避时间。默认值是 512ms 。-1 表示禁用退避时间。如:5s |
dialTimeout string | (可选) 建立新连接的超时时间。默认为 5s 。 |
readTimeout string | (可选) 读取超时时间。如果超时则会导致 Redis 命令失败而非以阻塞方式等待。默认为 3s ,-1 表示没有超时。 |
writeTimeout string | (可选) 写入超时时间。如果超时则会导致 Redis 命令失败而非以阻塞方式等待。默认与 readTimeout 一致。 |
poolSize int64 | (可选) 最大连接数量。默认每个物理 CPU 负载 10 个连接。如:20 |
poolTimeout string | (可选) 连接池的超时时间。默认是 readTimeout + 1 秒。如:50s |
maxConnAge string | (可选) 连接老化时间。默认不关闭老化的连接。如:30m |
minIdleConns int64 | (可选) 维持的最小空闲连接数,以避免创建新连接带来的性能下降。默认为 0 。如:2 |
idleCheckFrequency string | (可选) 空闲连接回收器的检查频率。默认为 1m 。-1 表示禁用空闲连接回收器。如:-1 |
idleTimeout string | (可选) 关闭客户端闲置连接的超时时间。应该小于服务器的超时时间。默认为 5m 。-1 表示禁用空闲超时检查。如:10m |
4.2.2 - Kafka 参数说明
KafkaSpec
EventSource 会根据 KafkaSpec 生成用于适配 Kafka 事件源的 Dapr Bindings Components ,原则上我们会尽量维持相关参数的一致性。你可以通过访问 Kafka binding spec 获取更多信息。
字段 | 描述 |
---|---|
brokers string | 以逗号分隔的 Kafka 服务器地址的字符串。如:localhost:9092 |
authRequired bool | 是否启用 Kafka 服务器的 SASL 认证。可选:true , false |
topic string | Kafka 事件源的 topic 名称,如:topicA ,myTopic |
saslUsername string | (可选) 用于认证的 SASL 用户名。只有在 authRequired 为 true 时才需要设置。如:admin |
saslPassword string | (可选) 用于认证的 SASL 用户密码。只有在 authRequired 为 true 时才需要设置。如:123456 |
maxMessageBytes int64 | (可选) 单个消息允许包含的最大字节数。默认为 1024 。如:2048 |
scaleOption KafkaScaleOption | (可选) Kafka 的自动伸缩选项 |
KafkaScaleOption
从属 KafkaSpec
字段 | 描述 |
---|---|
GenericScaleOption | 通用的自动伸缩配置 |
consumerGroup string | Kafka 的 consumer group 名称 |
topic string | 伸缩器监控的 topic 名称,如:topicA , myTopic |
lagThreshold string | 伸缩器的触发阈值,此处为 Kafka 的消息延迟量 |
4.2.3 - Cron 参数说明
CronSpec
EventSource 会根据 CronSpec 生成用于适配 Cron 事件源的 Dapr Bindings Components ,原则上我们会尽量维持相关参数的一致性。你可以通过访问 Cron binding spec 获取更多信息。
字段 | 描述 |
---|---|
schedule string | 参考 Schedule format 了解合法的 schedule 格式。如:@every 15m |
4.3 - EventBus 参数说明
EventBus(ClusterEventBus)
字段 | 描述 |
---|---|
apiVersion string | events.openfunction.io/v1alpha1 |
kind string | EventBus(ClusterEventBus) |
metadata v1.ObjectMeta | (可选) 参考 v1.ObjectMeta 文档 |
spec EventBusSpec | 事件总线的规格,参考 EventBusSpec |
status EventBusStatus | 事件总线的状态 |
EventBusSpec
从属 EventBus
字段 | 描述 |
---|---|
topic string | 事件总线的 topic 名称 |
natsStreaming NatsStreamingSpec | (当前仅支持)nats streaming 事件总线的定义,参考 NatsStreamingSpec |
GenericScaleOption
从属 scaleOption
字段 | 描述 |
---|---|
pollingInterval int | 检查每个伸缩触发器的时间间隔。默认是30 秒 |
cooldownPeriod int | 在将资源缩减到 0 之前,最后一个伸缩触发器报告激活后的等待时间。 默认为 300 秒 |
minReplicaCount int | KEDA 将收缩资源的最小副本数。默认值是 0 |
maxReplicaCount int | 这个设置被传递给KEDA为特定资源创建的HPA定义,KEDA 扩展资源的最大副本数。 |
advanced kedav1alpha1.AdvancedConfig | 请查看 KEDA 文档 |
metadata map[string]string | KEDA 伸缩触发器的元数据 |
authRef kedav1alpha1.ScaledObjectAuthRef | 你在 TriggerAuthentication 配置中定义的每个参数都不需要包含在你的 ScaledObject 定义的触发器的 metadata 中。要从 ScaledObject 中引用 TriggerAuthentication ,你需要在触发器中添加 authRef ,请参考 KEDA 文档 |
4.3.1 - Nats Streaming 参数说明
NatsStreamingSpec
从属 EventBusSpec
EventBus(ClusterEventBus) 会将配置提供给 EventSource 和 Trigger 引用,以便生成对应的 Dapr Pub/Sub Components 从事件总线处获取消息,原则上我们会尽量维持相关参数的一致性。你可以通过访问 NATS Streaming pubsub spec 获取更多信息。
字段 | 描述 |
---|---|
natsURL string | NATS 服务器的地址,如:nats://localhost:4222 |
natsStreamingClusterID string | NATS 集群 ID,如:stan |
subscriptionType string | 订阅器类型,可选:topic , queue |
ackWaitTime string | (可选) 请参考 Acknowledgements 。如:300ms |
maxInFlight int64 | (可选) 请参考 Max In Flight 。如:25 |
durableSubscriptionName string | (可选) 持久化订阅器 的名称。如:my-durable |
deliverNew bool | (可选) 订阅器选项(只能使用一个)。是否只发送新消息。可选:true ,false |
startAtSequence int64 | (可选) 订阅器选项(只能使用一个)。设置起始序列位置和状态。如:100000 |
startWithLastReceived bool | (可选) 订阅器选项(只能使用一个)。是否将起始位置设置为最新消息处。可选:true ,false |
deliverAll bool | (可选) 订阅器选项(只能使用一个)。是否发送所有可用的信息。可选:true ,false |
startAtTimeDelta string | (可选) 订阅器选项(只能使用一个)。使用差值形式设置所需的开始时间位置和状态。如:10m ,23s |
startAtTime string | (可选) 订阅器选项(只能使用一个)。使用标值形式设置所需的开始时间位置和状态。如:Feb 3, 2013 at 7:54pm (PST) |
startAtTimeFormat string | (可选) 必须与 startAtTime 一起使用。设置时间的格式。如:Jan 2, 2006 at 3:04pm (MST) |
scaleOption NatsStreamingScaleOption | (可选) Nats streaming 的自动伸缩选项 |
NatsStreamingScaleOption
字段 | 描述 |
---|---|
GenericScaleOption | 通用的自动伸缩配置 |
natsServerMonitoringEndpoint string | Nats streaming 的指标监控端点 |
queueGroup string | Nats streaming 的 queue group 名称 |
durableName string | Nats streaming 的 durable 名称 |
subject string | 伸缩器监控的 subject 名称,如:topicA , myTopic |
lagThreshold string | 伸缩器的触发阈值,此处为 Nats Streaming 的消息延迟量 |
4.4 - Trigger 参数说明
Trigger
字段 | 描述 |
---|---|
apiVersion string | events.openfunction.io/v1alpha1 |
kind string | Trigger |
metadata v1.ObjectMeta | (可选) 参考 v1.ObjectMeta 文档 |
spec TriggerSpec | 事件触发器的规格,参考 TriggerSpec |
status TriggerStatus | 触发器的状态 |
TriggerSpec
从属 Trigger
字段 | 描述 |
---|---|
eventBus string | (可选) 事件触发器关联的 EventBus 资源名称 |
inputs map[string]Input | (可选) 输入触发器的事件,参考 map[string]Input |
subscribers []Subscriber | (可选) 触发器的订阅者,参考 []Subscriber |
Input
从属 TriggerSpec
字段 | 描述 |
---|---|
namespace string | (可选) 事件源的的命名空间名称,默认与 Trigger 的命名空间一致。如:default |
eventSource string | 事件源名称,如:kafka-eventsource |
event string | 事件名称,如:eventA |
Subscriber
从属 TriggerSpec
字段 | 描述 |
---|---|
condition string | 触发器的触发条件,参考 cel-spec 获取更多写法规范。如:eventA && eventB ,`eventA |
sink SinkSpec | (可选) 触发的 Sink(可寻址的访问资源,即同步请求)定义,参考 SinkSpec |
deadLetterSink SinkSpec | (可选) 触发的死信 Sink(可寻址的访问资源,即同步请求)定义,参考 SinkSpec |
topic string | (可选) 触发的发送给事件总线的 topic 名称,如:topicTriggered |
deadLetterTopic string | (可选) 触发的发送给事件总线的死信 topic 名称,如:topicDL |
SinkSpec
从属 Subscriber
字段 | 描述 |
---|---|
ref Reference | 参考 Reference |
Reference
从属 SinkSpec
引用资源一般为 Knative Service
字段 | 描述 |
---|---|
kind string | 引用资源的类型,默认为:Service |
namespace string | 引用资源的命名空间,默认与 Trigger 的命名空间一致 |
name string | 引用资源的名称,如:function-ksvc |
apiVersion string | 引用资源的 apiVersion,默认为:serving.knative.dev/v1 |
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 中目前可用的追踪参数。
名称 | 描述 | 示例 |
---|---|---|
enabled | 使能追踪功能,默认为 false | true , false |
provider.name | 可以设置为 skywalking 、opentelemetry (待定) | skywalking |
provider.oapServer | SkyWalking OAP 服务器地址 | skywalking-opa:11800 |
tags | 一组键值对,用于追踪中的追踪所使用的 Span 自定义标签 | |
tags.func | 函数的名称,该值将被自动填充 | function-a |
tags.layer | 表示被追踪的服务类型,当你使用该函数时,它应该被设置为 faas | faas |
baggage | 一个键值对的集合,存在于追踪中,也需要跨进程边界传输 |
下面是一个 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
服务的样例地址。
运行下面的命令,修改
openfunction
命名空间中的 ConfigMapopenfunction-config
。kubectl edit configmap openfunction-config -n openfunction
参照下面的例子修改
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 作为分布式追踪解决方案
通过参考 本文档 创建函数。
然后,您可以在 SkyWalking UI 界面上观察整个函数调用的链路。
您还可以比较 Knative 运行时函数(
function-front
)在运行状态和冷启动时的响应时间。在冷启动时:
在运行状态下: