解读 Knative Serving v0.15.0 版本特性

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 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

目录
相关文章
|
新零售 人工智能
阿里巴巴联合汉仪重磅推出五款人工智能字体:汉仪天真体、英雄体等
众所周知传统做字的人力成本非常之高,如果全靠人类设计师来完成,一套标准字库从设计到完成需要一年多的时间。
13422 0
|
4月前
|
存储 缓存 资源调度
# Qwen3-8B 的 TTFT 性能分析:16K 与 32K 输入 Prompt 的推算公式与底层原理详解
Qwen3-8B 是通义实验室推出的 80 亿参数大模型,支持最长 32,768 token 上下文,适用于长文本处理场景。通过 FP8 量化、CUDA Kernel 优化及 RoPE 位置编码技术,提升推理效率与稳定性。模型在 16K 输入下 TTFT 约 150-200ms,32K 输入下约 250-300ms,适用于文档摘要与长对话交互。
1137 8
|
9月前
|
人工智能 自然语言处理 算法
DeepSeek vs ChatGPT:AI对决中的赢家是……人类吗?
DeepSeek VS ChatGPT:DeepSeek以开源黑马姿态崛起,凭借低成本、高性能的「DeepSeek-V3」和专为深度推理设计的「DeepSeek-R1」,成为中小开发者的首选。而ChatGPT则较贵。 然而,AI依赖也带来隐忧,长期使用可能导致记忆衰退和“脑雾”现象。为此,推荐Neuriva解决方案,专注力提升30%,记忆留存率提升2.1倍,助力人类在AI时代保持脑力巅峰。 DeepSeek赢在技术普惠,ChatGPT胜于生态构建,人类的关键在于平衡AI与脑力健康,实现“双核驱动”突破极限!
854 7
|
人工智能 API 决策智能
swarm Agent框架入门指南:构建与编排多智能体系统的利器 | AI应用开发
Swarm是OpenAI在2024年10月12日宣布开源的一个实验性质的多智能体编排框架。其核心目标是让智能体之间的协调和执行变得更轻量级、更容易控制和测试。Swarm框架的主要特性包括轻量化、易于使用和高度可定制性,非常适合处理大量独立的功能和指令。【10月更文挑战第15天】
2177 6
|
缓存 安全 Linux
docker镜像管理问题
【10月更文挑战第3天】
240 1
|
机器学习/深度学习 人工智能 NoSQL
生成式AI赋能金融信贷:减少信用评分偏差
替代数据、人工智能和生成式 AI 的融合正在重塑信用评分的基础,标志着金融业进入了一个关键时刻
4567 3
|
机器学习/深度学习 算法
Anaconda——添加清华源
Anaconda——添加清华源
631 0
|
存储 Python
Defaultdict:Python中的高效字典类
Defaultdict:Python中的高效字典类
246 0