Knative Serving 0.11.0 版本变更

  • 时间:
  • 浏览:2

这次改动后,每次请求先判断这个 pod的容量算是 满了,并且没满会先发送给它处置,原来会让请求优先塞满第有有好几个 pod,才会到第好几个 pod。作者认为原来中间缩容时,都都可否针对空闲的进行缩容。

点我查看设计文档(google docs)

回顾上有有好几个 版本的变更,为了让activator把请求更均匀发送到pod上,引入了two random choices算法,并且 为了处置多个activator的场景,把pod分配给特定的activator来处置。举个例子,我希望有有有好几个 activator,好几个 pod,每个activator会分配到有有好几个 pod,最后剩下的按顺序分配,也并且第有有好几个 activator负责好几个 pod,第好几个 负责有有好几个 pod。原来实现后,发现并且并发数是1的并且效果不错,但并发数是10的并且效果不好。

文章来自于对knative release note的翻译和解读

目前的大问题是怎么都可否处置剩下的pod怎么都可否平均分配流量。作者新的方案是再加了two random choices算法,改用knative中间的breaker来实现,通过设置容量达到平分的目的。具体算法如下,假设有有有好几个 activator,好几个 pod,并发数是10,则每个activator的容量为 5 * 10 / 2 = 25。另外每个pod的podIPTracker中间有个breaker,根据并且的分配策略,每个activator独自向有有好几个 pod发送,podIPTracker中间的breaker容量就有10,但还剩下有有好几个 pod,把这个 pod的容量设置为10/2=5,也并且说对于这个 pod,每个activator最多同去给它好几个 并发。

Knative Serving v0.11.0 版本并且于 12 月 11 号正式发布。本次版本继续优化activator负载均衡能力,这次处置了并发数为10的场景,测试结果显示大主次请求在0.14秒完成,具体细节见以下内容。

Kourier是第有有好几个 Knative原生的入口实现,直接调和knative网络层CRD到Envoy中间。它作为istio的替换品之一,更轻量的提供入口流量路由服务,目前在0.11版本中把Kourier作为Knative e2e集成测试的有有好几个 选项。