这是本节可打印的多页视图 点击这里开始打印.

返回常规视图.

欢迎访问 OpenFunction

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

1 - 入门

这里将指引您快速入门 OpenFunction,包括安装及一些案例的演示

概述

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

OpenFunction的特点:

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

OpenFunction有两个主要框架:

兼容性

Kubernetes 兼容性矩阵

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

OpenFunctionKubernetes 1.19Kubernetes 1.20Kubernetes 1.21Kubernetes 1.22
release-0.3
release-0.4×
HEAD×

前提准备

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

此外,你需要为 OpenFunction 的 BuilderServing 部署一些依赖项。

你可以使用以下命令来安装 OpenFunction 的 BuilderServing

sh hack/deploy.sh --all

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

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

参数用途说明
--all安装所有 BuilderServing 的依赖软件
--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 - 概念术语

向您介绍 OpenFunction 中的概念

2.1 - Function

OpenFunction 概念之核心框架资源,函数实例 Function

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

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

参考

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

2.2 - Builder

OpenFunction 概念之核心框架资源,函数构建器 Builder

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

当前,OpenFunction Builder 使用 ShipwrightCloud 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

OpenFunction 概念之核心框架资源,函数负载器 Serving

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

当前,OpenFunction Serving 支持两种负载运行时:KnativeOpenFuncAsync。设置其中一种负载运行时之后,Serving 才能正常工作。

Knative

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

OpenFuncAsync

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

参考

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

2.4 - EventSource

OpenFunction 概念之事件框架资源,事件源 EventSource

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

支持的事件源

参考

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

2.5 - EventBus(ClusterEventBus)

OpenFunction 概念之事件框架资源,事件总线 EventBus(ClusterEventBus)

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

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

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

支持的事件总线服务器

参考

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

2.6 - Trigger

OpenFunction 概念之事件框架资源,事件触发器 Trigger

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

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

参考

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

3 - 开发 & 贡献指南

学习怎样开发 OpenFunction 及怎样贡献您的代码

3.1 - 快速上手

本文将指导你如何在你的本地环境中开始构建 OpenFunction。

前提准备


如果你对开发控制器、管理器感兴趣,请参阅 sample-controllerkubebuilder

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

  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

3.3 - Pull Request 流程

本文档将帮助你学习如何提交 pull requests。

本文档演示了向 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 从提交到合并的过程:

  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 来重新运行失败的测试

一旦测试通过,所有的失败都被评论为偶然的,或者评审员添加了 lgtmapproved 标签,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 - 参考资料

参阅 OpenFunction 中资源的详细使用说明

v1alpha1

core.openfunction.io/v1alpha1,包含:

events.openfunction.io/v1alpha1,包含:

4.1 - Function 参数说明

Function CRD 参数规范说明

Function

字段描述
apiVersion stringcore.openfunction.io/v1alpha1
kind stringFunction
metadata v1.ObjectMeta(可选) 参考 v1.ObjectMeta 文档
spec FunctionSpecFunction 的规格,参考 FunctionSpec
status FunctionStatusFunction 的状态,参考 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

从属 ShipwrightEngine

字段描述
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

从属 OpenFuncAsyncRuntime

字段描述
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 stringDapr component 的名称
v1alpha1.ComponentSpecDapr Components Spec 定义,参考 Dapr 相关文档

DaprSubscription

从属 Dapr

字段描述
name stringDapr components 的注解,参考 Dapr 相关文档
v1alpha1.SubscriptionSpecDapr Subscription Spec 定义,参考 Dapr 相关文档
scopes []string

DaprIO

从属 Dapr

字段描述
name string函数输入、输出端的名称,与 DaprComponent 的 name 一致即表示关联
type stringDapr component 的类型,可选:bindingspubsubinvoke
topic string(可选)typepubsub 时,需要设置 topic
methodName string(可选)typeinvoke 时,需要设置 methodName,参考 Dapr 相关文档
params map[string]string(可选) 传递给 Dapr 的参数

Keda

从属 OpenFuncAsyncRuntime

字段描述
scaledObject KedaScaledObjectKEDA 可扩展对象(Deployments)定义,参考 KedaScaledObject
scaledJob KedaScaledJobKEDA 可扩展任务定义,参考 KedaScaledJob

KedaScaledObject

从属 Keda

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

字段描述
workloadType string以何种方式运行函数,可选:DeploymentStatefulSet,默认为 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 内所有容器的重启策略。可选择 OnFailureNever。默认为 Never
pollingInterval int32(可选) pollingInterval 的单位是秒。这是 KEDA 检查触发器的队列长度或流滞后的时间间隔。默认是 30 秒。
successfulJobsHistoryLimit int32(可选) 应该保留多少个已完成的 Job。默认为 100
failedJobsHistoryLimit int32(可选) 应该保留多少个失败的 Job。默认为 100
maxReplicaCount int32(可选) 在一个轮询周期内可以创建的最大 pod 的数量。
scalingStrategy kedav1alpha1.ScalingStrategy(可选) 选择一个缩放策略。可能的值是 defaultcustomaccurate。默认值是 default。参考 kedav1alpha1.ScalingStrategy
triggers []kedav1alpha1.ScaleTriggers触发工作负载动态伸缩的事件源,参考kedav1alpha1.ScaleTriggers

4.2 - EventSource 参数说明

EventSource CRD 参数规范说明

EventSource

字段描述
apiVersion stringevents.openfunction.io/v1alpha1
kind stringEventSource
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

从属 EventSourceSpec

字段描述
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 intKEDA 将收缩资源的最小副本数。默认值是 0
maxReplicaCount int这个设置被传递给KEDA为特定资源创建的HPA定义,KEDA 扩展资源的最大副本数。
advanced kedav1alpha1.AdvancedConfig请查看 KEDA 文档
metadata map[string]stringKEDA 伸缩触发器的元数据
authRef kedav1alpha1.ScaledObjectAuthRef你在 TriggerAuthentication 配置中定义的每个参数都不需要包含在你的 ScaledObject 定义的触发器的 metadata 中。要从 ScaledObject 中引用 TriggerAuthentication,你需要在触发器中添加 authRef,请参考 KEDA 文档

4.2.1 - Redis 参数说明

Redis 事件源参数说明

RedisSpec

从属 EventSourceSpec

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

字段描述
redisHost stringRedis 服务器的地址,如:localhost:6379
redisPassword stringRedis 服务器的密码,如:123456
enableTLS bool(可选) 是否启用 TLS 访问,默认为 false 。可选:truefalse
failover bool(可选) 是否启用 failover 特性。需要设置 sentinalMasterName 。默认为 false 。可选:truefalse
sentinelMasterName string(可选) sentinel master 的名称。参考 Redis Sentinel Documentation
redeliverInterval string(可选) 重新发送的时间间隔。默认为 60s0 表示禁用重新发送机制。如:30s
processingTimeout string(可选) 消息处理超时时间。默认为 15s0 表示禁用超时。如: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 参数说明

Kafka 事件源参数说明

KafkaSpec

从属 EventSourceSpec

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

字段描述
brokers string以逗号分隔的 Kafka 服务器地址的字符串。如:localhost:9092
authRequired bool是否启用 Kafka 服务器的 SASL 认证。可选:truefalse
topic stringKafka 事件源的 topic 名称,如:topicAmyTopic
saslUsername string(可选) 用于认证的 SASL 用户名。只有在 authRequired 为 true 时才需要设置。如:admin
saslPassword string(可选) 用于认证的 SASL 用户密码。只有在 authRequired 为 true 时才需要设置。如:123456
maxMessageBytes int64(可选) 单个消息允许包含的最大字节数。默认为 1024。如:2048
scaleOption KafkaScaleOption(可选) Kafka 的自动伸缩选项

KafkaScaleOption

从属 KafkaSpec

字段描述
GenericScaleOption通用的自动伸缩配置
consumerGroup stringKafka 的 consumer group 名称
topic string伸缩器监控的 topic 名称,如:topicA, myTopic
lagThreshold string伸缩器的触发阈值,此处为 Kafka 的消息延迟量

4.2.3 - Cron 参数说明

Cron 事件源参数说明

CronSpec

从属 EventSourceSpec

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

字段描述
schedule string参考 Schedule format 了解合法的 schedule 格式。如:@every 15m

4.3 - EventBus 参数说明

EventBus 及 ClusterEventBus CRD 参数规范说明

EventBus(ClusterEventBus)

字段描述
apiVersion stringevents.openfunction.io/v1alpha1
kind stringEventBus(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 intKEDA 将收缩资源的最小副本数。默认值是 0
maxReplicaCount int这个设置被传递给KEDA为特定资源创建的HPA定义,KEDA 扩展资源的最大副本数。
advanced kedav1alpha1.AdvancedConfig请查看 KEDA 文档
metadata map[string]stringKEDA 伸缩触发器的元数据
authRef kedav1alpha1.ScaledObjectAuthRef你在 TriggerAuthentication 配置中定义的每个参数都不需要包含在你的 ScaledObject 定义的触发器的 metadata 中。要从 ScaledObject 中引用 TriggerAuthentication,你需要在触发器中添加 authRef,请参考 KEDA 文档

4.3.1 - Nats Streaming 参数说明

Nats Streaming 事件总线参数说明

NatsStreamingSpec

从属 EventBusSpec

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

字段描述
natsURL stringNATS 服务器的地址,如:nats://localhost:4222
natsStreamingClusterID stringNATS 集群 ID,如:stan
subscriptionType string订阅器类型,可选:topicqueue
ackWaitTime string(可选) 请参考 Acknowledgements 。如:300ms
maxInFlight int64(可选) 请参考 Max In Flight 。如:25
durableSubscriptionName string(可选) 持久化订阅器 的名称。如:my-durable
deliverNew bool(可选) 订阅器选项(只能使用一个)。是否只发送新消息。可选:truefalse
startAtSequence int64(可选) 订阅器选项(只能使用一个)。设置起始序列位置和状态。如:100000
startWithLastReceived bool(可选) 订阅器选项(只能使用一个)。是否将起始位置设置为最新消息处。可选:truefalse
deliverAll bool(可选) 订阅器选项(只能使用一个)。是否发送所有可用的信息。可选:truefalse
startAtTimeDelta string(可选) 订阅器选项(只能使用一个)。使用差值形式设置所需的开始时间位置和状态。如:10m23s
startAtTime string(可选) 订阅器选项(只能使用一个)。使用标值形式设置所需的开始时间位置和状态。如:Feb 3, 2013 at 7:54pm (PST)
startAtTimeFormat string(可选) 必须与 startAtTime 一起使用。设置时间的格式。如:Jan 2, 2006 at 3:04pm (MST)
scaleOption NatsStreamingScaleOption(可选) Nats streaming 的自动伸缩选项

NatsStreamingScaleOption

从属 NatsStreamingSpec

字段描述
GenericScaleOption通用的自动伸缩配置
natsServerMonitoringEndpoint stringNats streaming 的指标监控端点
queueGroup stringNats streaming 的 queue group 名称
durableName stringNats streaming 的 durable 名称
subject string伸缩器监控的 subject 名称,如:topicA, myTopic
lagThreshold string伸缩器的触发阈值,此处为 Nats Streaming 的消息延迟量

4.4 - Trigger 参数说明

Trigger CRD 参数规范说明

Trigger

字段描述
apiVersion stringevents.openfunction.io/v1alpha1
kind stringTrigger
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 - 路线图

了解 OpenFunction 的演进计划

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 - 最佳实践

了解使用 OpenFunction 的最佳实践。

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

本文介绍了如何使用 SkyWalking 为 OpenFunction 构建可观测性解决方案。

功能概览

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

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

先决条件

追踪功能的可配置参数

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

名称描述示例
enabled使能追踪功能,默认为 falsetrue, false
provider.name可以设置为 skywalkingopentelemetry(待定)skywalking
provider.oapServerSkyWalking OAP 服务器地址skywalking-opa:11800
tags一组键值对,用于追踪中的追踪所使用的 Span 自定义标签
tags.func函数的名称,该值将被自动填充function-a
tags.layer表示被追踪的服务类型,当你使用该函数时,它应该被设置为 faasfaas
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 服务的样例地址。

  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)在运行状态和冷启动时的响应时间。

    在冷启动时:

    在运行状态下: