乐趣区

关于云原生:Knative-基于流量的灰度发布和自动弹性实践

作者 | 李鹏(元毅)
起源 | 阿里巴巴云原生公众号

Knative

Knative 提供了基于流量的 主动扩缩容能力 ,能够依据利用的申请量,在顶峰时主动扩容实例数;当申请量减少当前,主动缩容实例,做到自动化地节俭资源老本。此外,Knative 还提供了基于流量的 灰度公布能力,能够将流量的百分比进行灰度公布。

在介绍 Knative 灰度公布和主动弹性之前,先带大家理解一下 ASK Knative 中的 流量申请机制

如上图所示,整体的流量申请机制分为以下局部:

  • 左侧是 Knative Service 的版本信息,能够对流量设置百分比;上面是路由策略,在路由策略里,通过 Ingress controller 将相应的路由规定设置到阿里云 SLB;
  • 右侧是对应创立的服务版本 Revision,在版本里对应有 Deployment 的资源,当流量通过 SLB 进来之后,间接依据相应的转发规定,转到后端服务器 Pod 上。

除了流量申请机制外,上图还展现了相应的弹性策略,如 KPA、HPA 等。

Service 生命周期

Service 是间接面向开发者操作的资源对象,蕴含两局部的资源:Route 和 Configuration。

如上图所示,用户能够通过配置 Configuration 外面的信息,设置相应的镜像、内容以及环境变量信息。

1. Configuration

Configuration 是:

  • 治理容器冀望的状态;
  • 相似版本控制器,每次更新 Configuration 都会创立新的版本(Revision)。

如上图所示,与 Knative Service 相比拟,Configuration 和它的配置很靠近,Configuration 里配置的就是容器冀望的资源信息。

2. Route

Route 能够:

  • 管制流量散发到不同的版本(Revision);
  • 反对依照百分比进行流量散发。

如上图所示,一个 Route 资源,上面包含一个 traffic 信息,traffic 外面能够设置对应的版本和每个版本对应的流量比例。

3. Revision

  • 一个 Configuration 的快照;
  • 版本追踪、回滚。

Knative Service 中版本治理的资源:Revision,它是 Configuration 的快照,每次更新 Configuration 就会创立一个新的 Revision,能够通过 Revision 实现版本追踪、灰度公布以及回滚。在 Revision 资源外面,能够间接地看到配置的镜像信息。

基于流量的灰度公布

如上图所示,如果一开始咱们创立了 V1 版本的 Revision,这时如果有新的版本变更,那么咱们只须要更新 Service 中的 Configuration,就会相应的创立出 V2 版本。而后通过 Route 对 V1 和 V2 设置不同的流量比例,上图中 V1 是 70%,V2 是 30%,流量会依照 7:3 的比例别离散发到两个版本上。一旦 V2 版本验证没有问题,接下来就能够通过调整流量比例的形式进行持续灰度,直到新的版本 V2 达到 100%。

在灰度的过程中,一旦发现新版本有异样,随时能够调整流量比例进行回滚。假如灰度到 30% 的时候,发现 V2 版本有问题,咱们就能够把比例调回去,在原来的 V1 版本上设置流量 100%,实现回滚操作。

除此之外,咱们还能够在 Route 中通过 traffic 对 Revision 打上一个 Tag,打完 Tag 之后,在 Knative 中会主动对以后的 Revision 生成一个可间接拜访的 URL,通过这个 URL 咱们能够间接把相应的流量打到以后的某一个版本下来,这样能够实现对某个版本的调试。

主动弹性

在 Knative 中提供了 丰盛的弹性策略,除此之外,ASK Knative 中还扩大了一些相应的弹性机制,接下来别离介绍以下几个弹性策略:

  • Knative Pod 主动扩缩容(KPA);
  • Pod 程度主动扩缩容(HPA);
  • 反对定时 + HPA 的主动扩缩容策略;
  • 事件网关(基于流量申请的精准弹性);
  • 扩大自定义扩缩容插件。

1. 主动扩缩容 -KPA


▲Knative Pod 主动扩缩容(KPA)

如上图所示,Route 能够了解成流量网关;Activator 在 Knative 中承载着 0~1 的职责,当没有申请流量时,Knative 会把相应的服务挂到 Activator Pod 下面,一旦有第一个流量进来,首先会进入到 Activator,Activator 收到流量之后,会通过 Autoscaler 扩容 Pod,扩容实现之后 Activator 把申请转发到相应的 Pod 下来。一旦 Pod ready 之后,那么接下来相应的服务会通过 Route 间接打到 Pod 下面去,这时 Activator 曾经完结了它的使命。

在 1~N 的过程中,Pod 通过 kube-proxy 容器能够采集每个 Pod 外面的申请并发指数­,也就是申请指标。Autoscaler 依据这些申请指标进行汇聚,计算相应的须要的扩容数,实现基于流量的最终扩缩容。

2. 程度扩缩容 -HPA


▲Pod 程度主动扩缩容(HPA)

它其实是将 K8s 中原生的 HPA 做了封装,通过 Revision 配置相应的指标以及策略,应用 K8s 原生的 HPA,反对 CPU、Memory 的主动扩缩容。

3. 定时 +HPA 交融

  • 提前布局容量进行资源预热;
  • 与 CPU、Memory 进行联合。

在 Knative 之上,咱们将定时与 HPA 进行交融,实现提前布局容量进行资源预热。咱们在应用 K8s 时能够领会到,通过 HPA 进行扩容时,等指标阈值上来之后再进行扩容的话,有时满足不了理论的突发场景。对于一些有规律性的弹性工作,能够通过定时的形式,提前布局好某个时间段须要扩容的量。

咱们还与 CPU、Memory 进行联合。比方某个时间段定时设置为 10 个 Pod,然而以后 CPU 对阈值计算出来须要 20 个 Pod,这时会取二者的最大值,也就是 20 个 Pod 进行扩容,这是服务稳定性的最基本保障。

4. 事件网关

  • 基于申请数主动弹性;
  • 1 对 1 工作散发。

事件网关是基于流量申请的精准弹性。当事件进来之后,会先进入到事件网关外面,咱们会依据以后进来的申请数去扩容 Pod,扩容实现之后,会产生将工作和 Pod 一对一转发的诉求。因为有时某个 Pod 同一时间只能解决一个申请,这时候咱们就要对这种状况进行解决,也就是事件网关所解决的场景。

5. 自定义扩缩容插件

自定义扩缩容插件有 2 个关键点:

  • 采集指标;
  • 调整 Pod 实例数。

指标从哪来?像 Knative 社区提供的基于流量的 KPA,它的指标是通过一个定时的工作去每个 Pod 的 queue-proxy 容器中拉取 Metric 指标。通过 controller 对获取这些指标进行解决,做汇聚并计算须要扩容多少 Pod。

怎么执行扩缩容?其实通过调整相应的 Deployment 外面的 Pod 数即可。

调整采集指标和调整 Pod 实例数,实现这两局部后就能够很容易地实现自定义扩缩容插件。

实操演示

上面进行示例演示,演示内容次要有:

  • 基于流量的灰度公布;
  • 基于流量的主动扩缩容。

演示过程观看形式:_https://developer.aliyun.com/…

作者简介

李鹏,花名:元毅,阿里云容器平台高级开发工程师,2016 年退出阿里,深度参加了阿里巴巴全面容器化、间断多年反对双十一容器化链路。专一于容器、Kubernetes、Service Mesh 和 Serverless 等云原生畛域,致力于构建新一代 Serverless 平台。以后负责阿里云容器服务 Knative 相干工作。

Serverless 电子书下载

本书亮点

  • 从架构演进开始,介绍 Serverless 架构及技术选型构建 Serverless 思维;
  • 理解业界风行的 Serverless 架构运行原理;
  • 把握 10 大 Serverless 实在落地案例,活学活用。

下载链接:https://developer.aliyun.com/topic/download?id=1128

退出移动版