knative serving 0.6 版本变更

翻译了一下0.6的版本变更

概要

新API模型

我们已经通过了knative serving “v1beta1” API模型提议,这些改变会使得kubernetes用户更容易使用Serving资源,解锁了在knative Service中使用Route,并且可以自己指定Revision名称,开启了GitOps场景。我们争取在接下来几个发布中完成。

在这次发布中,我们移植新的API定义到v1alpha1 API,作为转换到v1beta1(又称lemonade)的第一步。以下不兼容的变更会在0.7+版本实施:

  • Service和Configuration不再支持内嵌Build。
  • Service不支持 manual 模式。

你可以通过knative/docs的例子来了解新API接口,我们会继续支持大多数v1alpha1的接口直到我们停用它。

彻底改变缩容到零

我们从根本上改变了缩容到零的机制,新的架构通过Serving资源模型较少的改动,获得职责上更好的分离,并且解决了一些长期存在的问题(一些在这次版本发布,一些将来发布)。看下面内容了解更多。

自动证书(alpha,可选)

我们添加了自动证书集成!默认的实现基于 cert-manager 来提供证书(例如通过Let’s Encrypt),但和Istio插件化类似,你也可以替换cert-manager为其他证书提供系统。当前证书针对每个路由提供,但泛域名将在未来版本支持。这个功能依赖Istio 1.1,并且需要显式的开启。

控制器解耦

我们已经开始将Knative中的“可插拔”控制器拆分为它们自己的控制器进程,以便希望替换Knative子系统的人能够更容易地删除绑定的默认实现。例如,要安装Knative Serving但不包含Istio:

kubectl apply -f serving.yaml \
  -l networking.knative.dev/ingress-provider!=istio

注意,由于kubectl不能理解Istio对象的yaml(尽管他们已经被label选择器过滤掉了),我们会看到一些错误。可以安全的忽略找不到 “networking.istio.io/v1alpha3” 的 “Gateway” 资源。

你也可以用以下命令忽略基于cert-manager实现的自动证书(Auto-TLS)控制器:

kubectl apply -f serving.yaml \
  -l networking.knative.dev/certificate-provider!=cert-manager

扩缩容

把Knative PodAutoscaler(又称KPA) /scale 子资源移出来,变成一个PodScalable 通用类型(“duck type”)。这样可以利用informer缓存,并且扩展的字段可以让ServerlessService(又称SKS)利用PodSpec在未来版本优化。

(具体修改见#3889 ,题外话,之前每次调解都需要使用scale client连接API server读取/scale子资源,用不上缓存)

 

我们现在确保在Revision缩容到零前,“activator”组件已经接管流量(又称正向切换[positive hand-off], #2949)。这个改动开启了Revision能够管理激活。

(实现这个是为了解决缩容到0之前,要等待30秒,这个值是个经验值,主要是等待istio切换路由。但我们也不清楚30秒是否足够,还是说可以缩短。目前这个实现是在activator和queue proxy都加一个响应探测的接口,当需要缩容到零时,由pa发起请求探测检查确认是否路由到activator了。但目前的实现还不是完美的,由于istio有很多sidecar,更新路由需要时间,我们只能确定某个sidecar配置更新了)

 

新的注解 autoscaling.knative.dev/windowautoscaling.knative.dev/panicWindowPercentage, and autoscaling.knative.dev/panicThresholdPercentage 允许用户自定义 KPA 类型的扩缩容敏感性。(#3103)

(译者注:增加配置时间窗口、panic的一些参数)

添加activator的链路耗时(tracing)获取更详细的数据,并且可以持续的测量性能数据(#2726)。这个解决了#1276 并且允许我们去定位性能问题,例如冷启动。

缩短默认transports的空闲超时时间,解决了使用Istio 1.1 lean安装,缩容到零的问题(#3987)。原因是当endpoints变更时,通过k8s的service没有断开连接。

解决一个阻止缩容到零的问题 (#3688),解决方法,把enable-scale-to-zero配置加入KPA调解计算中。如果minScaler注解没有设或者设为0,并且enable-scale-to-zero设为false,保留最少一个pod。

修复autoscaler重启时,做出轻率的决定(#3771)(在没有指标时不扩缩容)。

核心API

我们已经批准了v1beta的API定义!如上所述,我们要开始在接下来的几个里程碑实现v1beta1.这次里程碑把v1beta1 API接口作为v1alpha1的子集。

我们改变了执行校验的方式,基于在支持的字段使用“fieldmask”。我们现在会给每个Kubernetes对象创建一个副本(仅限于我们需要的字段),并和原来的对象比较,这样确保我们在Kubernetes API发展中仔细考虑使用哪些资源字段(#3424#3779) 在这基础上,清理了内部API的校验 (#3789#3911)。

status.domain已经过时,使用status.url 来替换 (#3970) 。使用 apis.URL 类型作为URL status 字段,解决issue “无法获取服务 URL” (#1590)。

添加可以通过configmap设置默认的cpu、内存request和limit值。并且删除了之前默认的CPU limit,这样可以回退到k8s的默认值,除了由operator特别指定的。(#3550#3912)

去掉configurationMetadataGeneration label的使用 (#4012) ,并完成了我们转向CRD 子资源的最后一个改动(#643)。

网络

彻底改变了我们缩容到零的方式!这个开启了Revision管理自己启动的语义。需要缩容到零时实现了正向切换,并且增加了autoscaling控制器的同步周期,保持和其他控制器一致。

添加自动配置TLS证书。

停止发布Istio yaml文件。重新分发istio不是我们的本意,并且之前的版本暴露我们的改动-优化了Istio yamls。用户应该请教Istio或者厂商指定的文档来如何获得一个支持knative的Istio版本。

我们已经开始在Service或者Route的子路由中采取扁平命名方案。老的URL目前还可以使用,但新的URL会出现在 status.traffic[*].url 字段里。

支持安装Istio 1.1 (#3515#3353)

解决在开启Istio mTLS时,readiness 探测的问题(#4017)

监控

Activator也把请求日志记录下来(#3781)

测试和发布

  • label serving.knative.dev/release: devel需要有发布名字或者数字来替代devel,暴露TAG来填充
  • 总是用istio的HEAD版本来做升级测试,解决在升级降级knative测试遇到的错误
  • 添加额外一致性测试(9个新增的测试),改进现有的一致性测试和v1beta1的覆盖率。

参考内容

内容翻译自knative/serving release node https://github.com/knative/serving/releases/tag/v0.6.0




fatkun

折腾一下又不会死~

没有评论


You can leave the first : )



发表评论

电子邮件地址不会被公开。