@IT·互联网程序员互联网科技

knative serving 0.8 变更

2019-08-12  本文已影响15人  阿里云技术

knative serving 0.8 变更

前言

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

0.8主要增加了以下功能:

本次的不兼容变更:

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

扩缩容

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扩缩容放到了独立的进程。

稳定性和性能:

核心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

其他变更

监控

参考

knative serving 0.8 release note

作者:fatkun
阅读原文
本文为云栖社区原创内容,未经允许不得转载。

上一篇下一篇

猜你喜欢

热点阅读