开发者社区> fatkun> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

knative serving 0.7版本变更

简介: 本文主要解读knative serving 0.7版本的变更
+关注继续查看

前言

Knative serving 0.7版本在6月25日正式发布,本次版本发布主要是继续推进v1beta API的落地,HPA支持并发请求数进行扩缩容终于在这个版本实现了。注意这次去掉了一些过时的字段,详细见下面的不兼容变更。本文主要描述0.7版本的变更。

概览

serving.knative.dev/v1beta1 (因为 #4533 ,需要 K8s 1.14+)

在0.6扩展了 v1alpha1 API 包含 v1beta1 的字段,在这次发布中,将 v1alpha1 的字段限制在 v1beta1 的子集内,并且不允许出现v1beta1 不适合的字段,这样,我们可以利用kubernetes 1.11+ 支持的相同模式来发布 v1beta1
因为k8s处理多个版本时存在bug,导致无法在旧版本编辑资源,目前是准备发布两个yaml,一个是只支持 v1alpha1,可以兼容k8s 1.11+,另一个同时支持两个版本,需要k8s 1.14+。

HPA根据并发请求指标扩缩容

之前的版本HPA支持根据CPU扩容,在这次发布,HPA支持和默认扩缩容组件一样的"并发请求数"指标进行扩缩容。
HPA依然还不支持缩容到零,另外还要想办法暴露这些指标给任意的扩缩容插件。
当前的实现方式是通过autoscaler来抓取用户容器的并发请求数指标,把autoscaler注册成一个custom metrics api server,HPA通过这个方式来获取指标进行扩缩容。

非root用户容器

因为安全原因,使用非root用户来启动,包括queue-proxy。

不兼容变更

  • 去掉了之前过时的状态字段
  • Service里面的Build和Manual模式现在不支持了
  • Route tags默认生成的url生成方式改变

以下为各个组件的具体变更。

扩缩容

  • HPA支持根据自定义的并发请求数指标扩缩容
  • 根据pod的数量动态调整autoscaler抓取指标的样本数

Fixes:

  • 增加autoscaler的readiness健康检查
  • 根据activator的扩缩容调整activator限速器行为
  • Revision在达到最小副本数时才更改状态为ready

核心API

  • 暴露 v1beta1 API #4199
  • 容器中使用非root用户启动 #3237
  • 允许用户填写容器名称 #4289 
  • 支持projected volume #4079
  • 删除过时的状态字段 #4197 
  • Build不再支持 #4099
  • Manual模式不再支持 #4188
  • V1beta1 客户端和稳定性测试 #4369 
  • 旧的v1alpha1 schema 通过webhook转换 #4080 
  • queue-proxy 新增annotation用于限制资源占用 #4151 
  • Knative Sercice的annotation传递到Route和Configuration #4363#4367

Fixes:

  • 改进Ready/Generation的处理,如果底下资源还没有调和,更新状态非调和状态 #4185
  • 修复 Revision 回收 #4187#4245
  • 把pod调度失败的错误信息写入Revision状态中 #4191
  • 解决无法拉取scheme1版本的镜像 #4430

网络

  • 把route的annotation传递到ClusterIngress #4087 
  • 引入 tagTemplate 配置,支持定义版本的域名格式 #4292 
  • 支持自定义的子域名 #4210 
  • 允许定义最长请求超时时间 #4172 
  • 在请求中设置 Forwarded header #4376

Fixes:

  • 不依赖istio sidecar支持短域名 #3824
  • 改进ClusterIngress状态 #4288 #4144
  • SKS private service 使用随机名称避免长度过长 #4250 

监控

  • 设置zipkin pods的内存需求 #4353
  • 不需要fluentd sidecar收集 /var/log 日志 #4156 
  • Prometheus抓取 queue-proxy 指标 #4111

Fixes:

  • 修复一些Grafana dashboard
  • 移除内置的jaeger-operator,把它变成依赖来使用

参考

内容来自官方 release note https://github.com/knative/serving/releases

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

相关文章
knative serving 组件分析
knative serving 组件分析。
68 0
Knative Eventing 0.15.0 版本变更
前言 Knative Eventing 0.1.15 版本在5月27日已经发布,来看看它的变化。 注意 需要使用迁移工具把存储版本由v1alpha1 更新为 v1beta1,如果使用了Broker.Spec.ChannelTemplateSpec,需要在升级前先更新为兼容的配置。
1007 0
解读 Knative Serving v0.15.0 版本特性
Knative 0.15.0 版本已于近期发布,针对 Knative Serving v0.15.0 版本对这些新功能特性进行解读,让你快速对新版本特性有所深入了解。
1374 0
Knative Serverless 之道:如何 0 运维、低成本实现应用托管?
Serverless 无疑是当前最热的云原生话题,那么作为业务的开发人员或者运维人员咱们应该怎么看待这个事情?云原生和 Serverless 到底有什么关系?通过本次分享咱们将逐一揭开这些神秘的面纱。
2819 0
Knative 基本功能深入剖析:Knative Serving 之服务路由管理
导读:本文主要围绕 Knative Service 域名展开,介绍了 Knative Service 的路由管理。文章首先介绍了如何修改默认主域名,紧接着深入一层介绍了如何添加自定义域名以及如何根据 path 关联到不同的 Knative Service 。
2358 0
Knative 基本功能深入剖析:Knative Serving 的流量灰度和版本管理
本篇主要介绍 Knative Serving 的流量灰度,通过一个 rest-api 的例子演示如何创建不同的 Revision、如何在不同的 Revision 之间按照流量比例灰度。
5299 0
深入解读 Knative Eventing 0.7 版本新特性
Knative Eventing 0.7 版本已经于 6 月 26 号正式发布。本次发布主要围绕重构 Channel 特性展开。本篇文章重点解读了这些特性,并且以此展望一下 Knative Eventing 后续版本的发展。
2175 0
Knative 初体验:Serving Hello World
通过前面两章的学习你已经掌握了很多 Knative 的理论知识,基于这些知识你应该对 Knative 是谁、它来自哪里以及它要做什么有了一定的认识。可是即便如此你可能还是会有一种犹抱琵琶半遮面,看不清真容的感觉,这就好比红娘拿姑娘的 100 张生活照给你看也不如你亲自去见一面。
2110 0
从HelloWorld看Knative Serving代码实现
Knative Serving以Kubernetes和Istio为基础,支持无服务器应用程序和函数的部署并提供服务。我们从部署一个HelloWorld示例入手来分析Knative Serving的代码细节。
1711 0
+关注
fatkun
正在学习serverless相关
10
文章
0
问答
文章排行榜
最热
最新