解读 Knative Serving v0.15.0 版本特性-阿里云开发者社区

开发者社区> 阿里云容器服务 ACK> 正文

解读 Knative Serving v0.15.0 版本特性

简介: Knative 0.15.0 版本已于近期发布,针对 Knative Serving v0.15.0 版本对这些新功能特性进行解读,让你快速对新版本特性有所深入了解。

前言

Knative 0.15.0 版本已于近期发布,针对 Knative Serving v0.15.0 版本对这些新功能特性进行解读,让你快速对新版本特性有所深入了解。

Meta

支持包管理 go mod

go mod,类似maven, Knative 从 0.15.0 开始支持go mod,方便进行包管理。

k8s 版本支持

从Knative 0.15.0开始,k8s 最小支持版本为:1.16

Autoscaling-自动扩缩容

直接通过 pod ip 进行 metric 指标采集

之前是根据 cluster ip 去采集 metric 指标,但是不得不去除重复的采集pod ip. 另外 IPTables的负载均衡策略是随机策略, 极端情况很可能导致只采集到其中一个pod,针对这样的问题,在0.15.0中优先会根据pod ip进行采集指标,只有在pod ip采集失败的情况下,才会继续按照原有的 cluster ip 方式采集。

支持最后一个 pod 的保留时间(last-pod-retention-time)设置

这个特性还比较有故事,准确的说是被用户逼出来的。当前已有的一个参数scale-to-zero-grace-period,这个参数的初衷是用来避免在网络模式切换到 activator 之前 pod 立即缩容为 0,通过这个参数可以延迟pod缩容为0,但也意味着增加了pod运行成本开销,为此社区做了很多工作希望将scale-to-zero-grace-period的值设置更小,甚至为0。
但不少用户将这个参数用来长时间 hang 住 pod(实际确实能做到),因为有些情况下pod 冷启动的耗时还是很高的。
综合用户的建议,最后社区干脆新增一个参数:last-pod-retention-time,用于最后一个pod的保留时间,那么最后pod预留时长计算方式也就成了这样的:max(scale-to-zero-grace-period, last-pod-retention-time)

对无限制并发数的限制

当前如果设置containerConcurrency=0,对容器并发数是没有限制的。但对于FaaS-style 的场景,需要限制并发请求数,在0.15.0的版本中提供了这样的限制能力:通过全局配置 allow-container-concurrency-zero = false,强制限制并发数设置。

Pod Ready 超时控制

当前在部署Ksvc之后,如果pod启动异常,一段时间(2 min 左右)之后会自动缩容为0。这会导致一些情况下pod没有重试的机会,另外对于排查异常原因也无从下手。针对这样的情况,0.15.0版本在config-deployment中新增了ProgressDeadline参数,用于设置 pod ready 时限,通过这个参数可以控制pod启动失败之后多久缩容为0.

核心 API

支持 Dry run

引用 K8s( 从1.13开始支持) dry-run 机制,可以快速验证当前的Revision Template是否配置正确。在Template中可通过如下参数开启此特性:

  • features.knative.dev/podspec-dryrun: enabled
  • features.knative.dev/podspec-dryrun: strict

其中strict表示如果不支持dry-run会返回failure

尽快删除依赖资源

当前是根据reference 资源不存在时,然后删除该资源,这个会造成一定的删除延迟。通过引入 tracker 机制,可以及时的删除相关的资源。
## Networking-网络
### domainTemplate 支持 Label
当前在 domainTemplate 中支持通过Annotations配置自定义域名,在0.15.0中除了Annotations,还支持Label。

KIngress(VirtualService) 去掉Retry机制

当前默认的Retry是3次,如果Knative Service 返回状态码5xx,Istio 会尝试重试3次。
社区基于如下考虑选择去掉Retry:
(1)重试的工作在很大程度上取决于“可重试”的状态码。如果不定义可恢复的内容,那么Retry并没有真正的意义。
(2)如果“重试”仅用于TCP错误,则可以将其留给具体的实现来选择处理(是否重试),而不是在“Knative”级别上进行处理。
(3)Knative API没有Retry。

总结

乍看社区此次 Knative 0.15.0 的 Release Note,感觉淡如水,但深入分析每一个特性之后,才发现美如酒。如:最后一个 pod 的保留时间支持,提供 Dry run 能力,Pod Ready 超时控制等,或许结合实际的场景才能对这些新特性有更多体感。欢迎有兴趣的同学一起交流。

欢迎加入 Knative 交流群

image

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
阿里云容器服务 ACK
使用钉钉扫一扫加入圈子
+ 订阅

云端最佳容器应用运行环境,安全、稳定、极致弹性

官方博客
官网链接