关于云计算:开源函数计算平台-OpenFunction-保姆级入门教程

OpenFunction 0.6.0 上周曾经正式公布了，带来了许多值得注意的性能，包含函数插件、函数的分布式跟踪、管制主动缩放、HTTP 函数触发异步函数等。同时，异步运行时定义也被重构了。外围 API 也曾经从 v1alpha1 降级到 v1beta1。

官宣链接🔗：https://openfunction.dev/blog…

近年来，随着 无服务器计算 的衰亡，呈现了很多十分优良的 Serverless 开源我的项目，其中比拟卓越的有 Knative 和 OpenFaaS。但 Knative Serving 仅仅能运行利用，还不能运行函数，而 Serverless 的外围是函数计算，也就是 FaaS，因而比拟遗憾；OpenFaaS 尽管很早就出圈了，但技术栈过于老旧，不能满足现代化函数计算平台的需要。

OpenFunction 便是这样一个现代化的云原生 FaaS（函数即服务）框架，它引入了很多十分优良的开源技术栈，包含 Knative、Tekton、Shipwright、Dapr、KEDA 等，这些技术栈为打造新一代开源函数计算平台提供了有限可能：

• Shipwright 能够在函数构建的过程中让用户自由选择和切换镜像构建的工具，并对其进行形象，提供了对立的 API；
• Knative 提供了优良的同步函数运行时，具备弱小的主动伸缩能力；
• KEDA 能够基于更多类型的指标来主动伸缩，更加灵便；
• Dapr 能够将不同利用的通用能力进行形象，加重开发分布式应用的工作量。

本文不打算讲一些十分浅近的实践，作为刚跨进 Serverless 门槛的用户，更须要的是如何疾速上手，以便对函数计算有一个理性的认知，在后续应用的过程中，咱们再缓缓了解其中的架构和设计。

本文将会率领大家疾速部署和上手 OpenFunction，并通过一个 demo 来体验同步函数是如何运作的。

OpenFunction CLI 介绍

OpenFunction 从 0.5 版本开始应用全新的命令行工具 ofn 来装置各个依赖组件，它的性能更加全面，反对一键部署、一键卸载以及 Demo 演示的性能。用户能够通过设置相应的参数自定义地抉择装置各个组件，同时能够抉择特定的版本，使装置更为灵便，装置过程也提供了实时展现，使得界面更为好看。它反对的组件和其依赖的 Kubernetes 版本如下：

<center> 表一 OpenFunction 应用的第三方组件依赖的 Kubernetes 版本 </center>

ofn 的装置参数 ofn install 解决了 OpenFunction 和 Kubernetes 的兼容问题，会主动依据 Kubernetes 版本抉择兼容组件进行装置，同时提供多种参数以供用户抉择。

<center> 表二 install 命令参数列表 </center>

应用 OpenFunction CLI 部署 OpenFunction

有了命令行工具 ofn 之后，OpenFunction 部署起来非常简单。首先须要装置 ofn，以 amd64 版本的 Linux 为例，仅需两步即可：

1、下载 ofn

$ wget -c  https://github.com/OpenFunction/cli/releases/download/v0.5.1/ofn_linux_amd64.tar.gz -O - | tar -xz

2、为 ofn 赋予权限并挪动到 /usr/local/bin/ 文件夹下。

$ chmod +x ofn && mv ofn /usr/local/bin/

装置好 ofn 之后，仅需一步即可实现 OpenFunction 的装置。尽管应用 --all 选项能够装置所有组件，但我晓得大部分小伙伴的实在需要是不想再额定装一下 Ingress Controller 的，这个也好办，咱们能够间接指定须要装置的组件，排除 ingress，命令如下：

$ ofn install --knative --async --shipwright --cert-manager --region-cn
Start installing OpenFunction and its dependencies.
The following components will be installed:
+------------------+---------+
| COMPONENT        | VERSION |
+------------------+---------+
| OpenFunction     | 0.6.0   |
| Keda             | 2.4.0   |
| Dapr             | 1.5.1   |
| Shipwright       | 0.6.1   |
| CertManager      | 1.5.4   |
| Kourier          | 1.0.1   |
| DefaultDomain    | 1.0.1   |
| Knative Serving  | 1.0.1   |
| Tekton Pipelines | 0.30.0  |
+------------------+---------+
 ✓ Dapr - Completed!
 ✓ Keda - Completed!
 ✓ Knative Serving - Completed!
 ✓ Shipwright - Completed!
 ✓ Cert Manager - Completed!
 ✓ OpenFunction - Completed!
🚀 Completed in 2m47.901328069s.

 ██████╗ ██████╗ ███████╗███╗   ██╗
██╔═══██╗██╔══██╗██╔════╝████╗  ██║
██║   ██║██████╔╝█████╗  ██╔██╗ ██║
██║   ██║██╔═══╝ ██╔══╝  ██║╚██╗██║
╚██████╔╝██║     ███████╗██║ ╚████║
 ╚═════╝ ╚═╝     ╚══════╝╚═╝  ╚═══╝

███████╗██╗   ██╗███╗   ██╗ ██████╗████████╗██╗ ██████╗ ███╗   ██╗
██╔════╝██║   ██║████╗  ██║██╔════╝╚══██╔══╝██║██╔═══██╗████╗  ██║
█████╗  ██║   ██║██╔██╗ ██║██║        ██║   ██║██║   ██║██╔██╗ ██║
██╔══╝  ██║   ██║██║╚██╗██║██║        ██║   ██║██║   ██║██║╚██╗██║
██║     ╚██████╔╝██║ ╚████║╚██████╗   ██║   ██║╚██████╔╝██║ ╚████║
╚═╝      ╚═════╝ ╚═╝  ╚═══╝ ╚═════╝   ╚═╝   ╚═╝ ╚═════╝ ╚═╝  ╚═══╝

尽管本文演示的是同步函数，但这里把异步运行时也装上了，如果你不须要，能够把 --async 这个参数去掉，不影响本文的试验。

装置实现后，会创立这几个 namespace：

$ kubectl get ns
NAME                              STATUS   AGE
cert-manager                      Active   17m
dapr-system                       Active   4m34s
io                                Active   3m31s
keda                              Active   4m49s
knative-serving                   Active   4m41s
kourier-system                    Active   3m57s
openfunction                      Active   3m37s
shipwright-build                  Active   4m26s
tekton-pipelines                  Active   4m50s

每个 namespace 对应下面装置的各个组件。目前 OpenFunction 的 Webhook 须要应用 CertManager 来验证 API 拜访，后续咱们会去掉这个依赖，不再须要装置 CertManager。

自定义域名后缀

Knative Serving 目前应用 Kourier 作为入口网关，因为咱们没有部署 Ingress Controller，所以咱们拜访函数只有 Kourier 这一个入口。

Kourier 是一个基于 Envoy Proxy 的轻量级网关，是专门对于 Knative Serving 服务拜访提供的一个网关实现。对于 Envoy 管制立体的细节本文不作赘述，感兴趣的能够去浏览 Kourier 官网文档和源码。这里咱们只须要晓得 Kourier 会为函数拜访提供一个入口，这个拜访入口是通过域名来提供的，咱们要做的工作就是将相干域名解析到 Kourier 的 ClusterIP。

Kourier 默认创立了两个 Service：

$ kubectl -n kourier-system get svc
NAME               TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
kourier            LoadBalancer   10.233.7.202   <pending>     80:31655/TCP,443:30980/TCP   36m
kourier-internal   ClusterIP      10.233.47.71   <none>        80/TCP                       36m

只须要将与函数拜访相干域名解析到 10.233.47.71 即可。

尽管每个函数的域名都是不同的，但域名后缀是一样的，能够通过泛域名解析来实现解析与函数相干的所有域名。Kourier 默认的域名后缀是 example.com，通过 Knative 的 ConfigMap config-domain 来配置：

$ kubectl -n knative-serving get cm config-domain -o yaml
apiVersion: v1
data:
  _example: |
    ################################
    #                              #
    #    EXAMPLE CONFIGURATION     #
    #                              #
    ################################

    # This block is not actually functional configuration,
    # but serves to illustrate the available configuration
    # options and document them in a way that is accessible
    # to users that `kubectl edit` this config map.
    #
    # These sample configuration options may be copied out of
    # this example block and unindented to be in the data block
    # to actually change the configuration.

    # Default value for domain.
    # Although it will match all routes, it is the least-specific rule so it
    # will only be used if no other domain matches.
    example.com: |

    # These are example settings of domain.
    # example.org will be used for routes having app=nonprofit.
    example.org: |
      selector:
        app: nonprofit

    # Routes having the cluster domain suffix (by default 'svc.cluster.local')
    # will not be exposed through Ingress. You can define your own label
    # selector to assign that domain suffix to your Route here, or you can set
    # the label
    #    "networking.knative.dev/visibility=cluster-local"
    # to achieve the same effect.  This shows how to make routes having
    # the label app=secret only exposed to the local cluster.
    svc.cluster.local: |
      selector:
        app: secret
kind: ConfigMap
metadata:
  annotations:
    knative.dev/example-checksum: 81552d0b
  labels:
    app.kubernetes.io/part-of: knative-serving
    app.kubernetes.io/version: 1.0.1
    serving.knative.dev/release: v1.0.1
  name: config-domain
  namespace: knative-serving

将其中的 _example 对象删除，增加一个默认域名（例如 openfunction.dev），最终批改后果如下：

$ kubectl -n knative-serving get cm config-domain -o yaml
apiVersion: v1
data:
  openfunction.dev: ""
kind: ConfigMap
metadata:
  annotations:
    knative.dev/example-checksum: 81552d0b
  labels:
    app.kubernetes.io/part-of: knative-serving
    app.kubernetes.io/version: 1.0.1
    serving.knative.dev/release: v1.0.1
  name: config-domain
  namespace: knative-serving

配置集群域名解析

为了便于在 Kubernetes 的 Pod 中拜访函数，能够对 Kubernetes 集群的 CoreDNS 进行革新，使其可能对域名后缀 openfunction.dev 进行泛解析，须要在 CoreDNS 的配置中增加一段内容：

        template IN A openfunction.dev {
          match .*\.openfunction\.dev
          answer "{{.Name}} 60 IN A 10.233.47.71"
          fallthrough
        }

批改实现后的 CoreDNS 配置如下：

$ kubectl -n kube-system get cm coredns -o yaml
apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        template IN A openfunction.dev {
          match .*\.openfunction\.dev
          answer "{{.Name}} 60 IN A 10.233.47.71"
          fallthrough
        }
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          fallthrough in-addr.arpa ip6.arpa
        }
        hosts /etc/coredns/NodeHosts {
          ttl 60
          reload 15s
          fallthrough
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }
    ...

同步函数 demo 示例

配置完域名解析后，接下来能够运行一个同步函数的示例来验证一下。OpenFunction 官网仓库提供了多种语言的同步函数示例：

这里咱们抉择 Go 语言的函数示例，先来看一下最外围的部署清单：

# function-sample.yaml
apiVersion: core.openfunction.io/v1beta1
kind: Function
metadata:
  name: function-sample
spec:
  version: "v2.0.0"
  image: "openfunctiondev/sample-go-func:latest"
  imageCredentials:
    name: push-secret
  port: 8080 # default to 8080
  build:
    builder: openfunction/builder-go:latest
    env:
      FUNC_NAME: "HelloWorld"
      FUNC_CLEAR_SOURCE: "true"
    srcRepo:
      url: "https://github.com/OpenFunction/samples.git"
      sourceSubPath: "functions/knative/hello-world-go"
      revision: "main"
  serving:
    template:
      containers:
        - name: function
          imagePullPolicy: Always
    runtime: "knative"

Function 是由 CRD 定义的一个 CR，用来将函数转换为最终运行的利用。这个例子外面蕴含了两个组件：

• build : 通过 Shipwright 抉择不同的镜像构建工具，最终将利用构建为容器镜像；
• Serving : 通过 Serving CRD 将利用部署到不同的运行时中，能够抉择同步运行时或异步运行时。这里抉择的是同步运行时 knative。

国内环境因为不可抗因素，能够通过 GOPROXY 从公共代理镜像中疾速拉取所需的依赖代码，只需在部署清单中的 build 阶段增加一个环境变量 FUNC_GOPROXY 即可：

# function-sample.yaml
apiVersion: core.openfunction.io/v1beta1
kind: Function
metadata:
  name: function-sample
spec:
  version: "v2.0.0"
  image: "openfunctiondev/sample-go-func:latest"
  imageCredentials:
    name: push-secret
  port: 8080 # default to 8080
  build:
    builder: openfunction/builder-go:latest
    env:
      FUNC_NAME: "HelloWorld"
      FUNC_CLEAR_SOURCE: "true"
      FUNC_GOPROXY: "https://proxy.golang.com.cn,direct"
    srcRepo:
      url: "https://github.com/OpenFunction/samples.git"
      sourceSubPath: "functions/knative/hello-world-go"
      revision: "main"
  serving:
    template:
      containers:
        - name: function
          imagePullPolicy: Always
    runtime: "knative"

在创立函数之前，须要先创立一个 secret 来存储 Docker Hub 的用户名和明码：

$ REGISTRY_SERVER=https://index.docker.io/v1/ REGISTRY_USER=<your_registry_user> REGISTRY_PASSWORD=<your_registry_password>
$ kubectl create secret docker-registry push-secret \
    --docker-server=$REGISTRY_SERVER \
    --docker-username=$REGISTRY_USER \
    --docker-password=$REGISTRY_PASSWORD

上面通过 kubectl 创立这个 Function：

$ kubectl apply -f function-sample.yaml

查看 Function 运行状况：

$ kubectl get function
NAME              BUILDSTATE   SERVINGSTATE   BUILDER         SERVING   URL   AGE
function-sample   Building                    builder-6ht76                   5s

目前正处于 Build 阶段，builder 的名称是 builder-6ht76。查看 builder 的运行状态：

$ kubectl get builder
NAME            PHASE   STATE      REASON   AGE
builder-6ht76   Build   Building            50s

这个 builder 会启动一个 Pod 来构建镜像：

$ kubectl get pod
NAME                                     READY   STATUS     RESTARTS   AGE
builder-6ht76-buildrun-jvtwk-vjlgt-pod   2/4     NotReady   0          2m11s

这个 Pod 中蕴含了 4 个容器：

• step-source-default : 拉取源代码；

• step-prepare : 设置环境变量；

• step-create : 构建镜像；

• step-results : 输入镜像的 digest。

再次查看函数状态：

$ kubectl get function
NAME              BUILDSTATE   SERVINGSTATE   BUILDER         SERVING         URL                                              AGE
function-sample   Succeeded    Running        builder-6ht76   serving-6w4rn   http://openfunction.io/default/function-sample   6m

曾经由之前的 Building 状态变成了 Runing 状态。

这里的 URL 咱们无奈间接拜访，因为没有部署 Ingress Controller。不过咱们能够通过其余形式来拜访，Kourier 把每个拜访入口形象为一个 CR 叫 ksvc，每一个 ksvc 对应一个函数的拜访入口，能够看下目前有没有创立 ksvc：

$ kubectl get ksvc
NAME                       URL                                                        LATESTCREATED                   LATESTREADY                     READY   REASON
serving-6w4rn-ksvc-k4x29   http://serving-6w4rn-ksvc-k4x29.default.openfunction.dev   serving-6w4rn-ksvc-k4x29-v200   serving-6w4rn-ksvc-k4x29-v200   True

函数的拜访入口就是 http://serving-6w4rn-ksvc-k4x…。因为在后面的章节中曾经配置好了域名解析，这里能够启动一个 Pod 来间接拜访该域名：

$ kubectl run curl --image=radial/busyboxplus:curl -i --tty
If you don't see a command prompt, try pressing enter.
[root@curl:/]$
[root@curl:/]$ curl http://serving-6w4rn-ksvc-k4x29.default.openfunction.dev/default/function-sample/World
Hello, default/function-sample/World!
[root@curl:/]$ curl http://serving-6w4rn-ksvc-k4x29.default.openfunction.dev/default/function-sample/OpenFunction
Hello, default/function-sample/OpenFunction!

拜访这个函数时会主动触发运行一个 Pod：

$ kubectl get pod
NAME                                                       READY   STATUS    RESTARTS   AGE
serving-6w4rn-ksvc-k4x29-v200-deployment-688d58bfb-6fvcg   2/2     Running   0          7s

这个 Pod 应用的镜像就是之前 build 阶段构建的镜像。事实上这个 Pod 是由 Deployment 管制的，在没有流量时，这个 Deployment 的正本数是 0。当有新的流量进入时，会先进入 Knative 的 Activator，Activator 接管到流量后会告诉 Autoscaler（主动伸缩控制器），而后 Autoscaler 将 Deployment 的正本数扩大到 1，最初 Activator 会将流量转发到理论的 Pod 中，从而实现服务调用。这个过程也叫 冷启动。

如果你不再拜访这个入口，过一段时间之后，Deployment 的正本数就会被膨胀为 0：

$ kubectl get deploy
NAME                                       READY   UP-TO-DATE   AVAILABLE   AGE
serving-6w4rn-ksvc-k4x29-v200-deployment   0/0     0            0           22m

总结

通过本文的示例，置信大家应该可能领会到一些函数计算的劣势，它为咱们带来了咱们所冀望的对业务场景疾速拆解重构的能力。作为用户，只须要专一于他们的开发用意，编写函数代码，并上传到代码仓库，其余的货色不须要关怀，不须要理解基础设施，甚至不须要晓得容器和 Kubernetes 的存在。函数计算平台会主动为您调配好计算资源，并弹性地运行工作，只有当您须要拜访的时候，才会通过扩容来运行工作，其余工夫并不会耗费计算资源。

本文由博客一文多发平台 OpenWrite 公布！