knative 核心概念和原理、应用场景和思考

2018-10-3109:10:36服务器及运维Comments14,118 views2字数 7834阅读模式

什么是 Knative?

knative 是谷歌开源的 serverless 架构方案,旨在提供一套简单易用的 serverless 方案,把 serverless 标准化。目前参与的公司主要是 Google、Pivotal、IBM、Red Hat,2018年7月24日才刚刚对外发布,当前还处于快速发展的阶段。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

这是 Google Cloud Platform 宣布 knative 时给出的介绍:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

Developed in close partnership with Pivotal, IBM, Red Hat, and SAP, Knative pushes Kubernetes-based computing forward by providing the building blocks you need to build and deploy modern, container-based serverless applications.文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

可以看出,knative 是为了解决容器为核心的 serverless 应用的构建、部署和运行的问题。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

serverless 的概念已经出现蛮久了,为了理解 serverless 可以从应用开发者的角度来看,使用 serverless 框架之后,应用开发者的整个操作流程就变成了:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

~ # 编写 code 和 configuration 文件

~ # faascli build
~ # faascli deploy
~ # curl http://myapp.com/hello
hello, world from Awesome FaaS App!复制代码

可以看到用户只需要编写代码(或者函数),以及配置文件(如何 build、运行以及访问等声明式信息),然后运行 build 和 deploy 就能把应用自动部署到集群(可以是公有云,也可以是私有的集群)。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

其他事情都是 serverless 平台(比如这里的 knative)自动处理的,这些事情包括:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

  • 自动完成代码到容器的构建
  • 把应用(或者函数)和特定的事件进行绑定:当事件发生时,自动触发应用(或者函数)
  • 网络的路由和流量控制
  • 应用的自动伸缩

和标准化的 FaaS 不同,knative 期望能够运行所有的 workload : traditional application、function、container。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

knative 是建立在 kubernetes 和 istio 平台之上的,使用 kubernetes 提供的容器管理能力(deployment、replicaset、和 pods等),以及 istio 提供的网络管理功能(ingress、LB、dynamic route等)。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

knative 核心概念和原理、应用场景和思考

knative 核心概念和原理

为了实现 serverless 应用的管理,knative 把整个系统分成了三个部分:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

  • Build:构建系统,把用户定义的函数和应用 build 成容器镜像
  • Serving:服务系统,用来配置应用的路由、升级策略、自动扩缩容等功能
  • Eventing:事件系统,用来自动完成事件的绑定和触发

Build 构建系统

build 的功能是把用户的代码自动化构建成容器镜像,初次听起来很奇怪,有了 docker 之后有一个 Dockerfile 不就能构建容器了吗?为什么还需要一个新的 Build 系统?文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

Knative 的特别之处在于两点:一是它的构建完成是在 kubernetes 中进行的,和整个 kubernetes 生态结合更紧密;另外,它旨在提供一个通用的标准化的构建组件,可以作为其他更大系统中的一部分。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

正如官方文档中的说的那样,更多是为了定义标准化、可移植、可重用、性能高效的构建方法:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

The goal of a Knative build is to provide a standard, portable, reusable, and performance optimized method for defining and running on-cluster container image builds.文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

Knative 提供了 Build CRD 对象,让用户可以通过 yaml 文件定义构建过程。一个典型的 Build 配置文件如下:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

apiVersion: build.knative.dev/v1alpha1
kind: Build
metadata:
  name: example-build
spec:
  serviceAccountName: build-auth-example
  source:
    git:
      url: https://github.com/example/build-example.git
      revision: master
  steps:
  - name: ubuntu-example
    image: ubuntu
    args: ["ubuntu-build-example", "SECRETS-example.md"]
  steps:
  - image: gcr.io/example-builders/build-example
    args: ['echo', 'hello-example', 'build']
复制代码

其中,serviceAccountName 是构建过程中需要用到的密码和认证信息(比如连接到 git repo 的 SSH keys、push 镜像到 registry 的用户名和密码等);source 是代码信息,比如这里的 git 地址和分支;steps 是真正运行过程中的各个步骤,这个示例中的步骤只是作为 demo,真正的构建过程一般是 pull 代码、 build 镜像和 push镜像到 registry 等逻辑。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

因为大部分的构建过程都是一致的,因此 knative 还提供了 Build template 的概念,Build template 封装了预先定义好的构建过程(就是封装了上面的 steps 过程),并提供了非常简单的配置参数来使用。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

使用 build template 构建容器镜像就更简单了,只需要提供代码的地址和镜像名字即可,比如下面是使用 Google kaniko 模板构建 github 源码的 yaml 文件(需要在代码根目录存在 Dockerfile 文件):文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

apiVersion: build.knative.dev/v1alpha1
kind: Build
metadata:
  name: kaniko-build
spec:
  serviceAccountName: build-bot
  source:
    git:
      url: https://github.com/my-user/my-repo
      revision: master
  template:
    name: kaniko
    arguments:
    - name: IMAGE
      value: us.gcr.io/my-project/my-app复制代码

Serving:服务系统

serving 的核心功能是让应用运行起来提供服务。虽然听起来很简单,但这里包括了很多的事情:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

  • 自动化启动和销毁容器
  • 根据名字生成网络访问相关的 service、ingress 等对象
  • 监控应用的请求,并自动扩缩容
  • 支持蓝绿发布、回滚功能,方便应用方法流程

knative serving 功能是基于 kubernetes 和 istio 开发的,它使用 kubernetes 来管理容器(deployment、pod),istio 来管理网络路由(VirtualService、DestinationRule)。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

因为 kubernetes 和 istio 本身的概念非常多,理解和管理起来比较困难,knative 在此之上提供了更高一层的抽象(这些对应是基于 kubernetes 的 CRD 实现的)。这些抽象出来的概念对应的关系如下图:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

knative 核心概念和原理、应用场景和思考
  • Configuration:应用的最新配置,也就是应用目前期望的状态,对应了 kubernetes 的容器管理(deployment)。每次应用升级都会更新 configuration,而 knative 也会保留历史版本的记录(图中的 revision),结合流量管理,knative 可以让多个不同的版本共同提供服务,方便蓝绿发布和滚动升级
  • Route:应用的路由规则,也就是进来的流量如何访问应用,对应了 istio 的流量管理(VirtualService)
  • Service:注意这里不是 kubernetes 中提供服务发现的那个 service,而是 knative 自定义的 CRD,它的全称目前是 services.serving.knative.dev 。单独控制 route 和 configuration 就能实现 serving 的所有功能,但knative 更推荐使用 Service 来管理,因为它会自动帮你管理 route 和 configuration

一个 hello world 的 serving 配置如下所示:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: helloworld-go
  namespace: default
spec:
  runLatest:
    configuration:
      revisionTemplate:
        spec:
          container:
            image: docker.io/{username}/helloworld-go
            env:
            - name: TARGET
              value: "Go Sample v1"
复制代码

看起来和 kubernetes 的 pod 定义非常类似,但是它会帮你管理 deployment、ingress、service discovery、auto scaling……从这个角度来看,可以认为 knative 提供了更高的抽象,自动帮你封装掉了 kubernetes 和 istio 的实现细节。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

下面这张图介绍了 knative serving 各组件之间的关系:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

knative 核心概念和原理、应用场景和思考
  • 可以看到,每个 revision 对应了一组 deployment 管理的 pod
  • pod 会自动汇报 metrics 数据到 autoscaler,autoscaler 会根据请求量和资源使用情况修改 deployment 的 replicas 数量,从而实现自动扩缩容。serverless 一个重要的特定是它会 scale to 0 的,也就是当应用没有流量访问时,它会自动销毁所有的 pod
  • activator 比较有趣,它是为了处理 scale to 0 而出现的。当某个 revision 后面的 pod 缩容到 0 时,route 的流量会指向 activator,activator 接收到请求之后会自动拉起 pod,然后把流量转发过去
  • route 对象对应了 istio 的 DestinationRoute 和 VirtualService,决定了访问应用的流量如何路由

Eventing:事件系统

serving 系统实现的功能是让应用/函数能够运行起来,并且自动伸缩,那什么时候才会调用应用呢?除了我们熟悉的正常应用调用之外,serverless 最重要的是基于事件的触发机制,也就是说当某件事发生时,就触发某个特定的函数。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

事件概念的出现,让函数和具体的调用方能够解耦。函数部署出来不用关心谁会调用它,而事件源触发也不用关心谁会处理它。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

Note:目前 serverless 的产品和平台很多,每个地方支持的事件来源以及对事件的定义都是不同的(比如 AWS Lambda 支持很多自己产品的事件源)。Knative 自然也会定义自己的事件类型,除此之外,knative 还联合 CNCF 在做事件标准化的工作,目前的产出是 CloudEvents 这个项目。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

为了让整个事件系统更有扩展性和通用性,knative 定义了很多事件相关的概念。我们先来介绍一下:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

  • EventSource:事件源,能够产生事件的外部系统
  • Feed:把某种类型的 EventType 和 EventSource 和对应的 Channel 绑定到一起
  • Channel:对消息实现的一层抽象,后端可以使用 kafka、RabbitMQ、Google PubSub 作为具体的实现。channel name 类似于消息集群中的 topic,可以用来解耦事件源和函数。事件发生后 sink 到某个 channel 中,然后 channel 中的数据会被后端的函数消费
  • Subscription:把 channel 和后端的函数绑定的一起,一个 channel 可以绑定到多个knative service

它们之间的关系流程图如下:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

knative 核心概念和原理、应用场景和思考

Bus 是 knative 内部的事件存储层,用户可以选择自己感兴趣的实现,目前支持的方式有:Stub(在内存中实现的简单消息系统)、Kafka、Google PubSub。如果想要事件能够正常运行,必须在 knative 集群中安装其中一个 bus 实现方式。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

有了 bus 之后,我们就可以监听外部的事件了。目前支持的事件源有三个:github(比如 merge 事件,push 事件等),kubernetes(events),Google PubSub(消息系统),后面还会不断接入更多的事件源。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

如果要想监听对应的事件源,需要在 knative 中部署一个 source adaptor 的 pod,它负责从外部的系统中读取事件。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

读取后的事件,会根据用户配置的 Feed 对象(里面包括了事件源和 channel 的对应关系),找到对应的 channel,然后把消息发送到这个 channel 中(channel 的消息最终是存储在后端的 bus 系统里的)。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

然后,knative 会根据 subscription 的配置,不断从 channel 中读取事件,然后把事件作为参数调用对应的函数,从而完成了整个事件的流程。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

Knative 目前的状态

knative 是 2018 年 7月才刚刚对外开放,虽然内部已经开发一段时间,但是目前还处于非常早前的阶段(从支持的事件源和 bus就能看出来)。目前代码还不稳定,很多实现都是 hard-coded。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

knative 也是脱产于 google 和 CNCF,因此整个社区运行方式和目标与之前的 kubernetes 以及 istio 非常相似。社区根据组件分成多个 Working Group,每个 Group 独立负责自己的功能,所有的开源活动(文档、视频、代码)都是开放的。另外,CloudEvents 作为 knative 依赖的标准,目标也是成为 CRI、CNI、CSI 这种类似的标准。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

knative 社区目前非常活跃,已 github.com/knative/serving 项目为例,一个月已经有 600+ star,目前有 60+ contributor,900+ commits,而且入门的文档和教程都已经非常全面。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

knative 核心概念和原理、应用场景和思考

Knative 应用场景和思考

knative 基于 kubernetes 和 istio 的 serverless 开源实现,目标是为了提供更高层次的抽象,让开发者无需关注基础设施(虚拟机或者容器,网络配置,容量规划),而专注于业务代码即可。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

目前 serverless 以及 knative 的几个问题:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

1. 性能问题

性能问题一直是 serverless 被人诟病的一点,也是目前它不能广泛用于应用服务上的决定性原因。互联网的应用大多数有高并发、高性能的要求,serverless 整个网络链路很长,容器启停需要额外的时间,还无法满足互联网应用的要求。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

针对这一点,很多 serverless 框架也在不断地做改进,比如不断精简容器的启动时间、容器启动之后会做缓存等,比如 nuclio 就宣称自己的平台比 AWS Lambda 要快 10 倍以上。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

相信随着 serverless 的不断演进,性能问题会不断优化,至于能不能达到互联网应用的要求,还要时间给我们答案。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

2. 是否需要 istio 这一层?

基于 kubernetes 的 serverless 组件非常多,比如 kubeless。但是基于同时又基于 istio,目前 knative 还是第一个这么做的。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

有些人的疑问在于,knative 真的有必要基于 istio 来做吗?对于这个问题,我个人的看法是必要的。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

虽然 istio 才刚刚release 1.0 版本,但是它作为集群基础设施通用网络层的地位已经开始显露,相信在未来的发展中接受度会越来越大,并逐渐巩固自己的地位。虽然现阶段来说,很多人并不非常熟悉 istio 的情况,但是从长远角度来看,这一点将是 knative 的一个优势所在。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

另外,基于 istio 构建自己的 serverless 服务,也符合目前软件行业不要重复造轮子的工作。istio 在集群的网络管理方面非常优秀(智能路由、负载均衡、蓝绿发布等),基于 istio 来做可以让 knative 不用重复工作就能直接使用 istio 提供的网络通用功能。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

3. 系统复杂度

这一点和上面类似,knative 下面已经有两个非常复杂的平台:kubernetes 和 istio。这两个平台的理解、构建、运维本身就很复杂,如今又加上 knative 整个平台,需要了解的概念都要几十个,更不要提落地过程中会遇到的各种问题。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

对于公有云来说,kubernetes 和 istio 这些底层平台可以交给云供应商来维护(比如 google Function),但是对于内部构建来说,这无疑提高了整个技术门槛,对系统管理人来的要求更高。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

如何安装部署整个集群?如何对集群做升级?出现问题怎么调试和追踪?怎么更好地和内部的系统对接?这些系统的最佳实践是什么?怎么做性能优化?所有这些问题都需要集群管理人员思考并落实。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

4. 函数的可运维性?

相对于编写微服务来说,单个函数的复杂度已经非常低,但是当非常多的函数需要共同工作的时候,如何管理这些函数就成了一个必须解决的问题。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

  • 如何快速找到某个函数?
  • 如何知道一个函数的功能是什么?接受的参数是什么?
  • 怎么保证函数的升级不会破坏原有的功能?升级之后如何回滚?怎么记录函数的历史版本一方面追溯?
  • 当有多个函数需要同时工作的时候,怎么定义它们之间的关系?
  • 函数出现问题的时候如何调试?

对于函数的运维,一般的 serverless 平台(包括 knative)都提供了 logging、metrics、tracing 三个方面的功能。默认情况下,knative 使用 EFK(Elasticsearch、Fluent、Kibana)来收集、查找和分析日志;使用 prometheus + grafana 来收集和索引、展示 metrics 数据;使用 jaeger 来进行调用关系的 tracing。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

针对 serverless 衍生出来的运维工具和平台还不够多,如何调试线上问题还没有看到非常好的解决方案。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

5. knative 成熟度

最后一点是关于 knative 成熟度的,前面已经提到,knative 目前刚出现不久。虽然整个框架和设计都已经搭好了,但是很多实现都比较初级。这里提几点来说:文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

  • 为了实现 autoscaling,knative 在每个 pod 中添加一个叫做 queue proxy 的代理,它会自动把请求的 metrics 发送给 autoscaler 组件作为参考。这样一来,整个网络链路上又多了一层,对整个性能势必会有影响,未来的打算是直接使用 envoy sidecar 来替换掉 queue proxy
  • 支持的事件源和消息系统还还优先,外部事件只支持 github、kubernetes 和 Google PubSub。 这个问题可以慢慢扩展,knative 本身会实现很常用的事件类型,自定义的事件源用户可以自己实现
  • 目前还没有函数的 pipeline 管理(类似 AWS Lambda Step Functions),多个函数如何协作并没有自己处理。虽然没有在官方文档中看到这方面的 roadmap,但是以后一定会有这方面的功能(不管是 knative 本身来做,还是社区作为工具补充来实现)

这方面的问题都不是大事情,随着 knative 版本的迭代,在很快的时间都能够解决。文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

作者:金融级分布式架构
来源:掘金文章源自菜鸟学院-https://www.cainiaoxueyuan.com/yunwei/7585.html

  • 本站内容整理自互联网,仅提供信息存储空间服务,以方便学习之用。如对文章、图片、字体等版权有疑问,请在下方留言,管理员看到后,将第一时间进行处理。
  • 转载请务必保留本文链接:https://www.cainiaoxueyuan.com/yunwei/7585.html

Comment

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定