[Kubeflow系列]KNative介绍

发表于 2019-08-24 更新于 2024-03-06 分类于技术文章阅读次数：本文字数： 2.7k 阅读时长 ≈ 2 分钟

KNative目前的一些介绍文章:

官网

ServiceMesher介绍

蚂蚁金服的布道师

华为云介绍系列

缘起

第一次关注到KNative这个项目是在Info上Kubernetes 上领先的开源 Serverless 解决方案有哪些的文章上, 文章里面对比了常见的Serverless框架, KNative是其中的一个, 又由于这个项目是Google推出的, 因此当时觉得这个项目应该是最有希望的.

参考Service Mesh之争, 2018年年中的时候, 还有一些框架例如Istio和Linkred再竞争, 但是到2019年中基础上Istio已经变成事实标准了. 具体可以看这盘文章

目前KNative已经迭代到0.8版本, 按照google对版本命名的方式, 应该离正式版本近了.

这次随着KFServing依赖KNative组件, 因此安装了一下KNative体验了一下, 就顺便记录一下吧.

KNative介绍

KNative是Google在2018年7月份发布的, 定位为基于 Kubernetes 的 Serverless 解决方案，旨在标准化 Serverless，简化其学习成本.

Serverless 大体上可以分为两种类型：“Backend as a Service” 和 “Functions as a Service”

BaaS(Backend as a Service) 后端即服务，服务商为客户 (开发者) 提供整合云后端的服务，如提供文件存储、数据存储、推送服务、身份验证服务等功能，以帮助开发者快速开发应用。

FaaS(Function as a Service) 函数即服务，服务商提供一个平台，允许客户开发、运行和管理应用程序功能，而无需构建和维护基础架构。按照此模型构建应用程序是实现“无服务器”体系结构的一种方式，通常在构建微服务应用程序时使用。

而现在看KNative算是FAAS的一员, FAAS必须要解决的三个问题以及KNative对应方案为:

函数程序如何编译, 因此KNative有对应的Builder模块, 解决代码转化为镜像的问题
任务如何触发, 对应KNative的Event模块, 使用一些消息中间件来缓存/发送请求, 例如Kafka
函数如何服务化, 对应的是KNative的Serving模块, 将用户的代码服务化, 并有服务该有的能力, 例如流量控制,自动伸缩等

这个三组件是KNative的核心, 整个流程都按照三个模块来构建, 下面就看一下每个模块之中的架构概念.

目前是0.8版本, 现在Build模块已经被移除, 链接到了另外一个开源库.

就整个架构而言, Build应该算是整个框架的接口, 如果这个Build不在自己做的话, 无法完成平台的闭环

KNative架构

首先看一下KNative的顶层架构:

KNative依赖于Kubernetes, 三大组件的物理实现都是Kubernetes的CRD
而对外接口又依赖于Istio, 将一些服务治理网关路由的工作交由Istio完成
而KNative自己致力于完成开发者服务开发的工作

分工很明确, 比较看好这种方式

KNative Serving模块

Serving主要是服务管理的能力, KNative创造了这几个概念:

Service: 工作负载的底层概念, 管理整个生命周期
Route: 用于流量控制, 将不同的请求转发到不同的Revision
Configuration: 用于维护Service的配置
Revision: 每次代码或者配置修改, 都会生成一个Revision, 一个Revision会对应一个K8s的Deployment

KNative的Serving的概念,与Istio有部分的重复, 但是比Istio更好理解.

下面看一个真实的例子:

代码和docker的构建略过, 只看如何部署Service

apiVersion: serving.knative.dev/v1alpha1
kind: Service # KNative的Serving定义
metadata:
  name: helloworld-go
  namespace: default
spec:
  template:
    spec:
      containers:
        - image: docker.io/{username}/helloworld-go
          env:
            - name: TARGET
              value: "Go Sample v1"

创建完成这个步骤, 会依次创建Service/Route/Configuration/Revision以及真实的Deployment.

该Deployment会注入Istio-proxy, 最后访问由Istio路由来决定, 最后访问该Service也是通过Istio的网关

[root@gpu-01-client ~]#kubectl get svc istio-ingressgateway --namespace istio-system
NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                      AGE
istio-ingressgateway   LoadBalancer   10.247.103.192   100.95.144.30   80:31651/TCP,443:30856/TCP   9d

获取KNative的serviceURL


[root@gpu-01-client ~]#kubectl get ksvc helloworld-go  --output=custom-columns=NAME:.metadata.name,URL:.status.url
NAME            URL
helloworld-go   http://helloworld-go.default.example.com

测试

1 2	[root@gpu-01-client ~]# curl -H "Host:helloworld-go.default.example.com" http://100.95.144.30 Hello Go Sample v1!

KNative能够Scala-to-Zero, 这样也有一个坏处, 当一个新请求到来的时候, 第一次启动会相对较长的时间(需要启动一个工作的容器)

KNative Event模块

这部分待续, 还没有看完

KNative总结

目前KNative的版本还在0.8版本, 还不算正式release, 后续可能会有不少变动.

而且Build模块的去除, 感觉已经缺少了一个对于开发者的Interface, 不知道他们未来打算拿什么来弥补.

而对于Serverless框架来说, 我感觉近2年之内应该无法决出真正的事实标准框架, 所以对KNative来说, 还有时间.

对我们来说, 在1.0版本release之前, 不要将KNative纳入到系统的构架之中, 后续在持续关注社区后期的动向.