共计 2800 个字符，预计需要花费 7 分钟才能阅读完成。
简介：Knative 是基于 Kubernetes 的开源 Serverless 利用编排框架。阿里云 Knative 在社区 Knative 根底之上，与阿里云产品进行了深度的交融，给你带来最纯正的容器化 Serverless 体验。
Knative 是基于 Kubernetes 的开源 Serverless 利用编排框架。阿里云 Knative 在社区 Knative 根底之上，与阿里云产品进行了深度的交融，给你带来最纯正的容器化 Serverless 体验。
章程
• 对于 Knative
• Serverless 服务引擎 – Serving
• Serverless 事件驱动 – Eventing
• 阿里云 Knative
• 阿里云产品交融
• 阿里云 K8s 生态集成
• 一个例子
对于 Knative
Knative 是基于 Kubernetes 的开源 Serverless 利用编排框架。实际上 Knative 蕴含的不单单是 Workload，它还有 Kubernetes 原生的流程编排引擎和齐备的事件零碎。Knative 指标是基于 Kubernetes 提供利用 Serverless 工作负载编排的标准化。Knative 外围模块次要包含事件驱动框架 Eventing 和部署工作负载的 Serving。
Serverless 服务引擎 – Serving
Knative Serving 外围能力就是其简洁、高效的利用托管服务，这也是其撑持 Serverless 能力的根底。当然作为 SeverlesssFramework 就离不开按需分配资源的能力，Knative 能够依据您利用的申请量在顶峰期间主动扩容实例数，当申请量减少当前主动缩容实例数，能够十分自动化的帮忙您节省成本。Serving 还提供了的流量治理能力和灵便的灰度公布能力。流量治理能力能够依据百分比切分流量，灰度公布能力能够依据流量百分比进行灰度
简略的利用模型
提供了极简的利用模型 – Knative Service，同时满足服务部署、服务拜访以及灰度公布的能力。能够用上面的公式表述：Knative Service = 工作负载（Deployment）+ 服务拜访 (service)+ 灰度流量(Ingress)。利用模型如图：
• Service: 对 Serverless 利用模型的形象，通过 Service 治理利用的生命 周期
• configuration: 用于配置利用冀望的信息。每次更新 Service 就会更新 Configuration
• revision: configuration 的每次更新都会创立一个快照，用来做版本治理
• route: 将申请路由到 Revision，并能够向不同的 Revision 转发不同比例的 流量
• 利用托管
• Kubernetes 是面向 IaaS 治理的形象，通过 Kubernetes 间接部署利用须要保护的资源比拟多
• 通过 Knative Service 一个资源就能定义利用的托管
• 流量治理
• Knative 通过 Gateway 后果利用流量，而后能够对流量按百分比进行宰割，这为弹性、灰度等根底能力做好了根底
• 灰度公布
• 反对多版本治理，利用同时有多个版本在线提供服务很容易实现
• 不同版本能够设置不同的流量百分比，对灰度公布等性能实现起来很容易
• 弹性
• Knative 帮忙利用节省成本的外围能力是弹性，在流量减少的时候主动扩容，流量降落的时候主动缩容
• 每一个灰度的版本都有本人的弹性策略，并且弹性策略和调配到以后版本的流量是相关联的。Knative 会依据调配过去的流量多少进行扩容或者缩容的决策
丰盛的弹性策略
作为 Serverless 框架，其外围能力就是主动弹性，Knative 中提供了丰盛的弹性策略：
• 基于流量申请的主动扩缩容 -KPA
• 基于 CPU、Memory 的主动扩缩容 -HPA
• 反对定时 + HPA 的主动扩缩容策略
• 事件网关，提供申请与 Pod 1 对 1 解决能力
Serverless 事件驱动框架 – Eventing
事件驱动是 Serverless 的标配，在 Knative 同样提供了事件驱动框架 -Eventing。
Knative 的 Eventing 提供了残缺的事件模型，能够很容易地接入各个内部零碎的事件。事件接入当前通过 CloudEvent 规范在外部流转。
在 Knative Eventing 提供两种事件转发形式：
• 事件源间接转发到服务
• 事件源转发到 Broker/Trigger，而后通过过滤转发到服务
对于在应用过程中到底应该应用哪种形式进行转发呢？其实很简略，broker/trigger 模型是基于底层音讯零碎实现的，对于像 github、gitlab、k8s apiserver 这样的事件源来说，须要对音讯事件进行缓冲解决、保障音讯传输可靠性，那么咱们倡议通过事件源转发到 Broker/Trigger 进行事件流转。
对于事件源自身就是音讯零碎来说，像 mns、kafka、rocketmq 来说，应用事件源间接转发到服务更为高效。
讲到这里，就不得不提 Knative 的事件源。我把它比喻成事件驱动引擎，Knative Eventing 正是通过这些事件源驱动事件流转。
Knative 社区提供了丰盛的事件源，如 Kafka、GitHub 等。此外还接入音讯云产品事件源，如 MNS、RocketMQ 等。
阿里云 Knative
阿里云 Knative 在社区原生的 Knative 之上，与阿里云资源体系进行了全方位的整合，提供了更为丰盛的能力以及云产品级别的反对。
与阿里云产品交融
• 丰盛的音讯云产品事件源：Kafka、MNS、RocketMQ
• 服务拜访：SLB
• 存储：NAS、云盘等
• 可观测性：日志服务、ARMS
• IaaS 资源：ECS、ECI
人造集成阿里云 k8s 生态
• 反对阿里云标准版 Kubernentes，专有版 Kubernentes
• 反对阿里云 Serverless Kubernetes（ASK），并且在 ASK 中将 Knative 管控组件全托管, 为用户节俭了资源以及运维老本。
一个例子
接下来以一个发送弹幕的示例来介绍一下如何玩转阿里云 Knative。先看一下成果：
架构示意图
流程阐明：
• 用户通过弹幕 web 服务发送弹幕到阿里云 kafka
• Kafka Source 事件源监听到弹幕音讯，而后发送到弹幕音讯解决服务
• 弹幕音讯解决服务接管到音讯，而后主动弹性扩容实例进行音讯解决，并将解决实现的音讯发送给弹幕服务
• 最初弹幕通过 web 服务界面展现给用户
具体实际流动（密透：实现有机会拿 Cherry 机械键盘）：https://developer.aliyun.com/…
总结
最初咱们总结一下阿里云 Knative 能给咱们带来哪些能力：
• 服务部署低门槛、易上手
• Serverless 按需应用资源
• 事件驱动与音讯云产品无缝对接
• 人造集成阿里云 K8s 生态
• 与阿里云产品买通
心愿这些能力能给你带来真正的按需应用，升高运维、资源应用老本的诉求，这也是 serverless 思维理念所谋求的指标。
原文链接
本文为阿里云原创内容，未经容许不得转载。
