knative serving 0.8 变更

简介: knative serving 0.8 变更 前言 knative serving在8月6日发布了0.8版本,这个版本是Serving v1的第一个候选版本。 0.8主要增加了以下功能: Target Burst Capacity (TBC) 支持,用于避免突发流量在queue-proxy里排队。

knative serving 0.8 变更

前言

knative serving在8月6日发布了0.8版本,这个版本是Serving v1的第一个候选版本。

0.8主要增加了以下功能:

  • Target Burst Capacity (TBC) 支持,用于避免突发流量在queue-proxy里排队
  • 减少Readiness 健康检查需要的时间
  • Route/Service的ready状态能代表可以访问了

本次的不兼容变更:

  • 取消支持Istio 1.0.x(Istio 1.0.x的生命周期也已经结束),要求最低版本为1.1.x
  • 把 github.com/knative/serving import paths 改成 knative.dev/serving

下面是每个模块具体的改进

扩缩容

Target Burst Capacity (TBC) 支持 #4443#4516#4580#4758

设计这个的原因是,如果有突发流量,需要避免所有流量都涌入某几个pod内,导致流量在queue-proxy中排队。之前已经在Activator实现了限速器,但只适合从0扩容的场景。这次改进了一些,不只是从0扩容的时候,在实例数不满足时也会介入。
这次引入了TBC参数,设定突发流量达到多少并发才触发,和它配合的还有一个目标容量比例(container-concurrency-target-percentage),默认值是70%,用于autoscaler决定达到容量多少比例后,需要扩容一个pod。
如果通过计算,当前的突发流量超过剩余空闲的容量,Activator将加入到数据链路来(通过把Activator Endpoint加入public service,此时同时包含Activator和用户容器的endpoint),Activator会缓存请求,直到有充足的容量。
TBC这个配置可以在集群或者revision配置,默认不开启。
设计文档:链接

Activator HPA 和性能改进 #4886#4772

因为加入了TBC功能,activator在数据面上使用的更频繁,有一些性能和扩容问题暴露出来。现在给activator加了基于CPU的水平扩容和改进了请求延迟。

快速缩容到0 #4883#4949#4938 

如果activator在请求路径中(例如使用了TBC),现在会忽略缩容到0的静默等待时间(grace period)。现在静默等待时间改为activator确认在数据路径上,之前是一个固定值。

新增Metrics CRD #4753#4894#4895#4913#4924 

扩缩容指标变为独立的CRD(之前是在内存中创建),这样允许新的autoscaler可以在程序外部使用。
基于这个变更,把HPA扩缩容放到了独立的进程。

稳定性和性能:

  • 改进测试偶然报错
  • 更好的校验annotation和configmap
  • 当Autoscaler重启后,会等待一个合理数量的指标采集,才决定缩容。

核心API

Readiness 健康检查冷启动时间改进 #4148#4649#4667#4668#4731

queue-proxy sidecar现在会同时执行用户配置的readiness健康检查和默认的TCP检查。这使得我们可以更激进的对用户提供的容器做检查(相对于K8s默认秒级的间隔)。
readiness健康检查的 periodSeconds 默认为0,表示开启系统定义的亚秒级健康检查。可以把 periodSeconds 改为大于0的值,这样就使用k8s默认的健康检查。
实现方式是读取用户的配置,把用户的httpGet readiness配置转为queue-proxy的代码实现,通过执行脚本的方式检查。

其他变更

网络

Route/Service 只有从Istio ingress可访问才汇报Ready (#1582#3312)

Route 只有从Istio ingress可访问才汇报Ready,这样用户就可以判断Service/Route的状态,开始使用。

移除集群级别的 ClusterIngress 资源(#4028)

networking.internal.knative.dev/ClusterIngress 已经被namespace级别的 networking.internal.knative.dev/Ingress 资源替换, ClusterIngress资源会在0.9移除。

修复未激活的Revision流量比例不对 (#882#4755)

当如果有超过一个未激活的Revision,不再只路由到最大的分片。为了支持这个,现在宣布去掉支持Istio 1.0

其他变更

  • 每个 sub-Route 可以有自己的可见性设置(#3419)
  • 集成 Gloo Ingress

监控

  • 自动冷启动时间收集 #2495 
  • 修复部分指标名称不正确 #4716

参考

knative serving 0.8 release note

目录
相关文章
|
存储 Kubernetes 中间件
【无服务器架构】Knative Serving 介绍
【无服务器架构】Knative Serving 介绍
|
Kubernetes Cloud Native Serverless
Knative Eventing
Knative Eventing
133 0
|
Kubernetes Serverless 容器
Knative Serving
Knative Serving
129 0
|
Kubernetes 监控 测试技术
knative serving 组件分析
knative serving 组件分析。
374 0
|
JSON Kubernetes 网络协议
Knative Serving 健康检查机制分析
从头开发一个 Serverless 引擎并不是一件容易的事情,今天咱们就从 Knative 的健康检查说起。通过健康检查这一个点来看看 Serverless 模式和传统的模式都有哪些不同以及 Knative 针对 Serverless 场景都做了什么思考。
Knative Serving 健康检查机制分析
|
算法 Perl 容器
Knative 基本功能深入剖析:Knative Serving 自动扩缩容 Autoscaler
Knative Serving 默认情况下,提供了开箱即用的快速、基于请求的自动扩缩容功能 - Knative Pod Autoscaler(KPA)。下面带你体验如何在 Knative 中玩转 Autoscaler。
|
应用服务中间件 nginx 容器
Kubernetes集群中基于 CRD 实现分批发布
分批发布是一种通用的发布方式,但是在Kubernetes集群中,要实现分批发布,需要控制各种状态,维护service流量,以及各种label配置,十分麻烦。阿里云容器服务提供一种基于 CRD 的分批发布方式,大大方便发布流程。
4965 0
|
存储 API
Knative Eventing 0.15.0 版本变更
前言 Knative Eventing 0.1.15 版本在5月27日已经发布,来看看它的变化。 注意 需要使用迁移工具把存储版本由v1alpha1 更新为 v1beta1,如果使用了Broker.Spec.ChannelTemplateSpec,需要在升级前先更新为兼容的配置。
1214 0
|
Kubernetes 负载均衡 网络协议
解读 Knative Serving v0.15.0 版本特性
Knative 0.15.0 版本已于近期发布,针对 Knative Serving v0.15.0 版本对这些新功能特性进行解读,让你快速对新版本特性有所深入了解。
1683 0
|
存储 监控 Kubernetes
下一篇
无影云桌面