Knative 健康检查机制分析

从头开发一个 Serverless 引擎并不是一件容易的事情，今天咱们就从 Knative 的健康检查说起。通过健康检查这一个点来看看 Serverless 模式和传统的模式都有哪些不同以及 Knative 针对 Serverless 场景都做了什么思考。
Knative Serving 模块的核心原理如下图所示。下图中的 Route 可以理解成是 Istio Gateway 的角色。

• 当缩容到零时进来的流量就会指到 Activator 上面
• 当 Pod 数不为零时流量就会指到对应的 Pod 上面，此时流量不经过 Activator
• 其中 Autoscaler 模块根据请求的 Metrics 信息实时动态的扩缩容

Knative 的 Pod 是由两个 Container 组成的: Queue-Proxy 和业务 Container。架构如下：

咱们以 http1 为例进行说明。业务流量首先进入 Istio Gateway，然后会转发到 Queue-Proxy 的 8012 端口，Queue-Proxy 8012 再把请求转发到业务容器的监听端口，至此一个业务请求的服务就算完成了。

粗略的介绍原理基本就是上面这样，现在咱们对几个细节进行深入的剖析看看其内部机制：

• 为什么要引入 Queue-Proxy？
• Pod 缩容到零的时候流量会转发到 Activator 上面，那么 Activator 是怎么处理这些请求的？
• Knative 中的业务 Pod 有 Queue-Proxy 和 业务 Container，那么 Pod 的 readinessProber 和 LivenessProber 分别是怎么做的？Pod 的 readinessProber、 LivenessProber 和 业务的健康状态是什么样的关系？
• Istio Gateway 向 Pod 转发流量的时候是怎么选择 Pod 进行转发的？

为什么要引入 Queue-Proxy

Serverless 的一个核心诉求就是把业务的复杂度下沉到基础平台，让业务代码快速的迭代并且按需使用资源。不过现