Knative Serving 健康检查机制分析

导读：从头开发一个Serverless引擎并不是一件容易的事情，今天咱们就从Knative的健康检查说起。通过健康检查这一个点来看看Serverless模式和传统的模式都有哪些不同，以及Knative针对Serverless场景都做了什么思考。

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

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

为什么要引入 Queue-Proxy

• 访问日志的管理；
• Tracing；
• Pod 健康检查机制；
• 需要实现 Pod 和 Activator 的交互，当 Pod 缩容到零的时候如何接收 Activator 转发过来的流量；
• 其他诸如判断 Ingress 是否 Ready 的逻辑也是基于 Queue-Proxy 实现的。

从零到一的过程

参考阅读

• Activator to perform health checks before forwarding real requests
• Activator: Retry on Get Revision error
• Retry on Get Revision error?
• Always pass Healthy dests to the throttler
• Consolidate queue-proxy probe handlers
• Queue proxy logging, metrics and end to end traces
• End to end traces from queue proxy

VirtualService 的健康检查

参考阅读

• New probe handling in Queue-Proxy & Activator
• Extend VirtualService/Gateway probing to HTTPS
• Probe Envoy pods to determine when a ClusterIngress is actually deployed
• ClusterIngress Status
• Consolidate queue-proxy probe handlers

Kubelet 的健康检查

• 其中 LivenessProber 是判断 Pod 是否活着，如果检查失败 Kubelet 就会尝试重启 Container；
• ReadinessProber 是来判断业务是否 Ready，只有业务 Ready 的情况下才会把 Pod 挂载到 Kubernetes Service 的 EndPoint 中，这样可以保证 Pod 故障时对业务无损。

• 置空 user-container 的 ReadinessProber；
• 把 user-container 的 ReadinessProber 配置的 json String 配置到 Queue-Proxy 的 env 中；
• Queue-Proxy 的 Readinessprober 命令里面解析 user-container 的 ReadinessProber 的 json String 然后实现健康检查逻辑，且这个检查的机制和前面提到的 Activator 的健康检查机制合并到了一起。这样做也保证了 Activator 向 Pod 转发流量时 user-container 一定是 Ready 状态。

参考阅读

• Consolidate queue-proxy probe handlers
• Use user-defined readinessProbe in queue-proxy
• Apply default livenessProbe and readinessProbe to the user container
• Good gRPC deployment pods frequently fail at least one health check
• Fix invalid helloworld example 这里面有比较详细的方案讨论，最终社区选择的方案也是在这里介绍的。
• Allow probes to run on a more granular timer.
• Merge 8022/health to 8012/8013
• TCP probe the user-container from the queue-proxy before marking the pod ready.
• Use user-defined readiness probes through queue-proxy
• queue-proxy /heatlth to perform TCP connect to user container

使用方法

apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: readiness-prober
spec:
  template:
    metadata:
      labels:
        app: helloworld-go
    spec:
      containers:
        - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/helloworld-go:160e4db7
          readinessProbe:
            httpGet:
              path: /
            initialDelaySeconds: 3

1. 和原生的 Kubernetes Pod Readiness 配置相比，Knative 中 timeoutSeconds、failureThreshold、periodSeconds 和 successThreshold 如果要配置就要一起配置，并且不能为零，否则 Knative webhook 校验无法通过。并且如果设置了 periodSeconds，那么一旦出现一次 Success，就再也不会去探测 user-container（不建议设置 periodSeconds，应该让系统自动处理）。
2. 如果 periodSeconds 没有配置那么就会使用默认的探测策略，默认配置如下：

timeoutSeconds: 60
            failureThreshold: 3
            periodSeconds: 10
            successThreshold: 1

小结