新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/window, autoscaling.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 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