knative serving 0.10.0 版本变更

本文涉及的产品
网络型负载均衡 NLB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
简介: 前言Knative Serving v0.10.0 版本已经于 10 月 29 号正式发布。本次版本主要优化了activator负载均衡等能力,具体细节见以下内容。主要变更Activator半理想的负载均衡优化这部分的设计文档见  Better Load Balancing in Activator (google doc)在对activator负载均衡的优化中,设置 containerConcurrency: 1 后因为排队导致的错误已经解决。

前言

Knative Serving v0.10.0 版本已经于 10 月 29 号正式发布。本次版本主要优化了activator负载均衡等能力,具体细节见以下内容。

主要变更

Activator半理想的负载均衡优化

这部分的设计文档见  Better Load Balancing in Activator (google doc)
在对activator负载均衡的优化中,设置 containerConcurrency: 1 后因为排队导致的错误已经解决。在有容器并发数(CC,Container Concurrency)感知负载均衡的activator中,实际看到通过activator比直接访问用户容器有更低的延迟(一般来说增加额外一跳会增加延迟)。当前只实现了CC=1的场景,CC=10的还没完成。

之前版本做过一次优化,由于iptable刷新时间间隔的问题,通过service clusterip发现pod ip会有延迟,如果clusterIP没准备好,会向pod ip直接发送请求。这次的负载均衡优化只是针对向pod ip发送请求的场景,如何均衡的向每个pod发送请求。

作者想到的方案有两个,一个是把请求分配到当前负载最低的那个,第二个是two random choices 算法。有文章建议第一种方案可能更糟糕,第二种方案的实现方式是随机选择两个节点,然后从中选择一个低负载的。测试下来后,当只有一个activator的时候,效果很明显,但是包含多个activator的时候,还是有比较大的延时。作者认为的原因是:1,不同的activator会分配请求到相同的pod,导致排队 2,activator自己的流量不均匀。我理解第一个原因是各个activator没有共享当前pod负载情况,所以导致算法失效,有可能某个pod的请求相对多一些。

解决方案是把pod列表分片,每个activator只向部分pod发送请求。

Kubernetes最低支持版本为1.14

这样可以同时支持多个CRD版本以及试验其他Kubernetes CRD新功能。如果检测到低版本,安装会失败。

使用Go1.13

Serving已经切换到 Go 1.13,在同步上有更好的性能,错误包装(error wrapping)和其他功能,比如 Duration.Milliseconds

其他变更

扩缩容

  • Service名称不再使用GenerateName,我们在创建metrics和private K8s Service名称使用GenerateName,导致在测试和可靠性上很多问题,所以放弃使用。
  • Activator重构和负载均衡,在 @greghaynes 的几个变更后,允许探测和路由请求到独立的pod,可以显著的简化代码,移除重复和不高效的部分。
  • 显著提升集成测试,减少偶尔的报错

核心API

  • 切换到 K8s 1.15.3 客户端库 #5570 ,这个客户端版本可以让Knative使用K8s的新特性,选择这个版本的原因是它兼容1.14,并且因为兼容K8s 1.16,可以使用更长时间。
  • 切换回原来单一的安装方式,同时支持所有API版本,因为支持的K8s最低版本为1.14,这个版本已经解决了CRD多版本共存的问题,所以切换回之前的安装方式。
  • 跳过复制last-applied-configuration注解到 Route
  • ConfigMaps现在可以并行的校验了
  • 分别为编辑和查看添加ClusterRole
  • 在Configuration和Route里添加注解 /creator and /lastModifier
  • Service和Route加上duck.knative.dev/addressable=true标签,给eventing使用 #5874

网络

  • Activator优雅退出 #5542,activator在退出的时候,健康检查还返回成功,导致请求依然路由到退出中的activator,我们让SIGTERM信号触发健康检查失败,允许退出中的activator可以处理完剩余的请求。
  • 在AutoTLS关闭的时候,避免创建通配符证书 #5636,在v0.9.0,我们尝试创建通配符证书甚至cert-manager没有部署,导致在创建新namespace时证书创建错误。
  • 结束ClusterIngress迁移 #5689 
  • 改进健康检查支持HTTPS重定向,HTTPS,HTTP2和自定义端口   #5223,之前的健康检查依赖写入VirtualService特定的域名,现在可以探测实际的数据链路,允许使用真正服务的域名探测。
  • 修复cluster-local的可见性问题 #5734
  • 避免给cluster-local service创建错误的证书 #5611

监控

  • 添加容器和pod标签到revision和activator的指标里

参考

本文内容大部分来自于 Knative Serving release note 的解读

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
Kubernetes 监控 测试技术
knative serving 组件分析
knative serving 组件分析。
381 0
|
应用服务中间件 nginx 容器
Kubernetes集群中基于 CRD 实现分批发布
分批发布是一种通用的发布方式,但是在Kubernetes集群中,要实现分批发布,需要控制各种状态,维护service流量,以及各种label配置,十分麻烦。阿里云容器服务提供一种基于 CRD 的分批发布方式,大大方便发布流程。
4973 0
|
存储 API
Knative Eventing 0.15.0 版本变更
前言 Knative Eventing 0.1.15 版本在5月27日已经发布,来看看它的变化。 注意 需要使用迁移工具把存储版本由v1alpha1 更新为 v1beta1,如果使用了Broker.Spec.ChannelTemplateSpec,需要在升级前先更新为兼容的配置。
1215 0
|
Kubernetes 负载均衡 网络协议
解读 Knative Serving v0.15.0 版本特性
Knative 0.15.0 版本已于近期发布,针对 Knative Serving v0.15.0 版本对这些新功能特性进行解读,让你快速对新版本特性有所深入了解。
1686 0
|
存储 监控 Kubernetes
|
消息中间件 Kafka API
解读 Knative Eventing v0.14.0 版本特性
Knative Eventing v0.14.0 版本已于近期发布,新版本带来了哪些特性呢?本文会进行相关的解读
1503 0
|
存储 Kubernetes API
|
Kubernetes 网络协议 Java
|
负载均衡 Kubernetes 算法
解读 Knative Eventing v0.10.0 最新版本特性
Knative Eventing v0.10.0 版本已经于 10 月 29 号正式发布。本次发布继续围绕完善 Eventing 中相关功能展开。本篇文章通过解读这些功能特性,让你快速对 v0.10.0 版本有所了解。
2734 0