作者|阿里云智能事业群技术专家牛秋霖(冬岛)
<>强导读:从头开发一个服务器引擎并不是一件容易的事情,今天咱们就从Knative的健康检查说起。通过健康检查这一个点来看看Serverless模式和传统的模式都有哪些不同,以及Knative针对Serverless场景都做了什么思考。
Knative服务模块的核心原理如下图所示,图中的路线可以理解成是Istio网关的角色。
<李>当缩容到零时进来的流量就会指到催化剂上面;李 <李>当荚数不为零时流量就会指到对应的吊舱上面,此时流量不经过活化剂;李 <李>其中自动定量模块根据请求的度量信息实时动态的扩缩容。
Knative的圆荚体是由两个容器组成的:Queue-Proxy和业务容器user-container。架构如下:
咱们以http1为例进行说明:业务流量首先进入Istio网关,然后会转发到Queue-Proxy的8012端口,Queue-Proxy 8012再把请求转发到user-container的监听端口,至此一个业务请求的服务就算完成了。
粗略的介绍原理基本就是上面这样,现在咱们对几个细节进行深入的剖析看看其内部机制:
<李>为什么要引入Queue-Proxy ?李 <李>荚缩容到零的时候流量会转发到催化剂上面,那么活化剂是怎么处理这些请求的?李 <李> Knative中的业务豆荚有Queue-Proxy和user-container,那么Pod的readinessProber和LivenessProber分别是怎么做的? Pod的readinessProber, LivenessProber和业务的健康状态是什么样的关系?李 <李> Istio网关向转仓发流量的时候是怎么选择Pod进行转发的?李
为什么要引入Queue-Proxy
Serverless的一个核心诉求就是把业务的复杂度下沉到基础平台,让业务代码快速迭代并且按需使用资源,不过现在更多的还是聚焦在按需使用资源层面。
如果想要按需使用资源我们就需要收集相关的度量,并根据这些指标信息来指导资源的伸缩.Knative首先实现的就是KPA策略,这个策略是根据请求数来判断是否需要扩容的,所以Knative需要有一个机制收集业务请求数量。除了业务请求数还有如下信息也是需要统一处理:
<李>访问日志的管理,李 <李>跟踪;李 <李>荚健康检查机制,李 <李>需要实现Pod和活化剂的交互,当圆荚体缩容到零的时候如何接收激活转发过来的流量;李 <李>其他诸如判断入口是否准备的逻辑也是基于Queue-Proxy实现的。
为了保持和业务的低耦合关系,还需要实现上述这些功能,所以就引入了Queue-Proxy负责这些事情。这样可以在业务无感知的情况下把Serverless的功能实现。
从零到一的过程
当Pod缩容到零的时候流量会指到催化剂上面,活化剂接收到流量以后会主动“通知“自动定量做一个扩容的操作。扩容完成以后激活会探测Pod的健康状态,需要等待第一个豆荚准备之后才能把流量转发过来,所以这里就出现了第一个健康检查的逻辑:<强>活化剂检查第一个豆荚是否准备。
这个健康检查是调用的圆荚体8012端口完成的,激活会发起HTTP的健康检查,并且设置K-Network-Probe=队列头,所以队列容器中会根据K-Network-Probe=队列来判断这是来自激活的检查,然后执行相应的逻辑。
参考阅读
<李>活化剂进行健康检查前真正转发请求李 <李>活化剂:重试alt=" Knative服务健康检查机制分析">
图片来源
图片来源
参考阅读
<强>门户通过这个健康检查来判断豆荚是否可以提供服务。
<李> Queue-Proxy新调查处理,李活化剂 <李>扩展VirtualService/网关探测HTTPS李 <李>探针特使吊舱,以确定当ClusterIngress实际上是部署李 <李> ClusterIngress地位李 <李>巩固queue-proxy调查处理程序李
Kubelet的健康检查
Knative服务健康检查机制分析
