基于 Go 语言开发 Serverless 云原生应用(2)-木庄网络博客

当前第2页返回上一页

Knative Service 对应一个叫做 Configuration 的资源，每次 Service 变化如果需要创建新的 Workload 就更新 Configuration，然后每次 Configuration 更更新都会创建一个唯一的 Revision。Revision 可以认为是 Configuration 的版本管理机制。理论上Revision 创建完以后就不会修改的。不同的 Revision 一般用于灰度发布

Route 是 Knative 管理流量的核心逻辑，Knative 是建立在 Istio 之后的，Knative Route Controller 通过 Route 的配置自动生成 Istio 的 VirtualService 资源，从而实现了流量的管理。

Knative Serving 对应用 Workload 的 Serverless 编排是从流量开始的。
流量首先达到 Knative 的 Gateway，Gateway 根据 Route 的配置自动把流量根据百分比拆分到不同的 Revision 上，然后每一个 Revision 都有一个自己独立的弹性策略。当过来的流量请求变多的时候当前 Revision 就开始自动扩容。每一个 Revision 的扩容策略都是独立的，相互不影响。

基于流量百分对对不同的 Revision 进行灰度，每一个 Revision 都有一个自己独立的弹性策略。Knative Serving 通过对流量的控制实现了流量管理、弹性和灰度三者的完美结合。

Demo 演示

问答环节

提问：你好，首先自我介绍一下，我是目前在网易云这边做CICD 平台的，所以我可能对这块比较感兴趣。其实刚才看的时候也有几个疑问：

Knative 是如何实现的按百分比的流量切分，并且把切分的流量转到不同的 Revision 上去的？以及这个流量切分和 Kubernetes 的 Ingress 有什么异同吗？
Knative 和 OAM 大概是怎样的一个关系？
冬岛：
Knative 0.10 及之前的版本 Gateway 使用的是 Istio Gateway 实现的，计划从 0.11 版本开始支持基于 Envoy 的原生实现。不过无论是 Istio Gateway 还是基于 Envoy 原生的实现其实都是使用的 Envoy 的能力。Envoy 做 HTTP 流量的百分比切分。Knative 中每一个 Revision 都有一个唯一的 Kubernetes Service， Envoy 负责转发把匹配条件的请求转发到 Revision 的 Kubernetes Service 上，从而实现了 Ingress 流量的百分比切分。和 Kubernetes 原生的 Ingress 相比，原生的 Ingress 只能根据 Domain、path 或者 Header 这种维度进行切分，而 Knative 基于 Envoy 可以进行更细力度的控制，可以精确到 1% 的流量比例。
OAM 是一套开放的应用模型，OAM 可以有 Kubernetes 的实现也可以有 Knative 的实现。OAM 的价值在于跨不同的底层编排系统统一应用模型。

提问：

Knative 是符合解决冷启动速度的问题的
刚才你的演讲中也提到了团队角色分工的问题，那么如果企业上云运维团队或者 SRE 团队应该在如何在上云的模式下定位自己的角色？
冬岛：
Serverless 其实是要分成两层的。第一层是 IaaS 资源的按需使用和按量分配。第二层是对应用的 Serverless 编排。云原生技术栈中对 IaaS 资源的管理主要是 Kubernetes 这一层的能力，比如前面志敏分享的 ASK 其实已经解决了 IaaS 按量分配的问题，Knative 这一层更多的是聚焦在应用的 Serverless 编排上面。应用的 Serverless 编排主要体现在：流量的接入和流量分配、不同 Revision 的管理以及弹性。这三者完美的结合在一起形成一个闭环才能给应用提供 Serverless 编排。应用 Serverless 编排在扩容或者缩容的时候自动申请或者释放 IaaS 资源
如果企业上云并不代表企业就不需要 SRE 团队。相反在企业上云的过程中 SRE 团队的价值也会被放大。企业在上云之前其实 SRE 团队本身是企业的成本部门，SRE 本身不带来业务价值，但是需要公司支出成本。但是在企业上云之后 SRE 其实是帮助企业节省成本的部门。SRE 需要判断哪个云厂商的什么产品合适本公司的业务、需要判断使用产品的什么规格、是包年包月还是按量付费的方式使用。以及上云的过程中使用什么方案实现多云、混合云的能力，等等这些都是 SRE 发挥巨大价值的地方。

提问：关于 OAM 这一块，在你这边有一些实现吗？
冬岛：OAM 是有清晰的分层关系的，Knative 可以实现一个 OAM 的 Controller 从而实现通过 Knative 部署 OAM 应用的能力。

提问：你介绍的Knative 这套 Serverless 编排引擎 和志敏介绍的 Serverless Kubernetes 有什么关联或者区别？
冬岛：如前面所述，Serverless 至少要分成应用的编排和资源编排两层，IaaS 的编排其实就是 ASK 着重要解决的问题。而 Knative 更多的是建立在 ASK 之上的应用编排。应用编排更多的是关注流量的管理、灰度的管理和弹性的管理。Knative 和 ASK 在一起其实是比较完美的组合。

提问：我刚才看你演示的时候讲流量管理里面是通过 HTTP Header 的方式去改变流量控制，如果我是一个 RPC 服务的话，你这里如何控制我的流量？
冬岛：因为Knative 底层的流量管理机制是基于Istio ，Istio 下一层就是 Envoy ，比如说你用 Double 这种非 HTTP 请求， Knative 是不支持的。

提问：Tekton 的这套 Pipeline 引擎能不能跨 Kubernetes 集群进行 CICD 流程的控制或者服务的部署？假设我们有测试、预发和线上三个环境，怎样控制 Pipeline 在这三套环境中的流转呢？   
冬岛：Tekton 的 Pipeline 里面可以包含多个 Task，每一个T ask 有多个 step，step 里面就是一个具体的 container 去执行一系列的命令。Step 的执行者和具体的 Kubernetes 集群没有直接绑定的关系。Step 中可以通过 Secret 挂载其他集群的 kubeconfig 文件，然后在 Step 中通过 kubectl 命令就可以跨集群进行操作了。所以如果实在构建测试到生产环境的 CICD Pipeline  流程的话可以在测试环境的最后一步通过生产环境的 kubeconfig 把服务发布到生产环境。

提问：阿里云的产品好多，看起来眼花缭乱，并且有很多产品看起来还是相互重叠的。关于这个问题你怎么看待？
冬岛：我觉得这个体感其实非常直接，很多企业上云的用户都会有这样的感觉。关于这个问题咱们就以 Knative 的 Serverless 编排和 ASK 为例进行说明。乍一看都是 Serverless 系统，这不就是重复的功能吗？当我们深入了解 Serverless 技术之后会发现 Knative 和 ASK 不但不冲突而且还是相互补充相互合作的关系。ASK 解决了 IaaS 按需分配的问题，Knative 解决了应用 Serverless 编排的问题。所以很多云产品看起来是有很多重叠的功能，但是如果深入到那个领域就会发现在垂直划分上大家都是有不同的场景的。

提问：我看刚才的演示中可以根据 HTTP 实时的请求进行扩缩容，那么我有这样两个疑问

是否可以根据机器自身的状况进行扩缩容？比如 CPU？
非 HTTP 协议的服务是否可以基于 Knative 进行管理？
冬岛：Knative 除了默认的 KPA 弹性策略还支持 Kubernetes 的 HPA 弹性策略，所以可以把 CPU 作为弹性伸缩的条件。另外 Knative 0.10 及之前的版本是基于 Istio Gateway 实现的流量接入，而 Istio Gateway 只能识别 HTTP 的应用层协议，所以默认的 Gateway 是不支持非 HTTP 协议的。但是 Knative 的设计是非常灵活的，Knative Revision 的 Ingress 和 Autoscaler 都是可以通过 plugin 的方式扩展的，这和 Kubernetes 的设计是一脉相承的，可以通过 Annotation 的方式声明使用哪个 Controller。所以 Knative 本身是可以通过自定义 Ingress Controller 实现非 HTTP 协议的流量管理的。

本文来自：51CTO博客

感谢作者：mob604756f0bbf4

查看原文：基于 Go 语言开发 Serverless 云原生应用

返回前面的内容