写点什么

Knative Serving 健康检查机制分析

  • 2019-11-12
  • 本文字数:3587 字

    阅读完需:约 12 分钟

Knative Serving 健康检查机制分析

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


Knative Serving 模块的核心原理如下图所示,图中的 Route 可以理解成是 Istio Gateway 的角色。


  • 当缩容到零时进来的流量就会指到 Activator 上面;

  • 当 Pod 数不为零时流量就会指到对应的 Pod 上面,此时流量不经过 Activator;

  • 其中 Autoscaler 模块根据请求的 Metrics 信息实时动态的扩缩容。



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



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


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


  • 为什么要引入 Queue-Proxy?

  • Pod 缩容到零的时候流量会转发到 Activator 上面,那么 Activator 是怎么处理这些请求的?

  • Knative 中的业务 Pod 有 Queue-Proxy 和 user-container,那么 Pod 的 readinessProber 和 LivenessProber 分别是怎么做的?Pod 的 readinessProber、 LivenessProber 和业务的健康状态是什么样的关系?

  • Istio Gateway 向 Pod 转发流量的时候是怎么选择 Pod 进行转发的?

为什么要引入 Queue-Proxy

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


如果想要按需使用资源我们就需要收集相关的 Metrics,并根据这些 Metrics 信息来指导资源的伸缩。Knative 首先实现的就是 KPA 策略,这个策略是根据请求数来判断是否需要扩容的。所以 Knative 需要有一个机制收集业务请求数量。除了业务请求数还有如下信息也是需要统一处理:


  • 访问日志的管理;

  • Tracing;

  • Pod 健康检查机制;

  • 需要实现 Pod 和 Activator 的交互,当 Pod 缩容到零的时候如何接收 Activator 转发过来的流量;

  • 其他诸如判断 Ingress 是否 Ready 的逻辑也是基于 Queue-Proxy 实现的。


为了保持和业务的低耦合关系,还需要实现上述这些功能,所以就引入了 Queue-Proxy 负责这些事情。这样可以在业务无感知的情况下把 Serverless 的功能实现。

从零到一的过程

当 Pod 缩容到零的时候流量会指到 Activator 上面,Activator 接收到流量以后会主动“通知”Autoscaler 做一个扩容的操作。扩容完成以后 Activator 会探测 Pod 的健康状态,需要等待第一个 Pod ready 之后才能把流量转发过来。所以这里就出现了第一个健康检查的逻辑:Activator 检查第一个 Pod 是否 ready。


**


这个健康检查是调用的 Pod 8012 端口完成的,Activator 会发起 HTTP 的健康检查,并且设置  K-Network-Probe=queue Header,所以 Queue Container 中会根据 K-Network-Probe=queue 来判断这是来自 Activator 的检查,然后执行相应的逻辑。

参考阅读

VirtualService 的健康检查

Knative Revision 部署完成后会自动创建一个 Ingress(以前叫做 ClusterIngress), 这个 Ingress 最终会被 Ingress Controller 解析成 Istio 的 VirtualService 配置,然后 Istio  Gateway 才能把相应的流量转发给相关的 Revision。


所以每添加一个新的 Revision 都需要同步创建 Ingress 和 Istio 的 VirtualService ,而 VirtualService 是没有状态表示 Istio 的管理的 Envoy 是否配置生效能力。所以 Ingress Controller 需要发起一个 http 请求来监测 VirtualService 是否 ready。这个 http 的检查最终也会打到 Pod 的 8012 端口上。标识 Header 是 K-Network-Probe=probe 。Queue-Proxy 需要基于此来判断,然后执行相应的逻辑。


相关代码如下所示:



参考阅读

Gateway 通过这个健康检查来判断 Pod 是否可以提供服务。


Kubelet 的健康检查

Knative 最终生成的 Pod 是需要落实到 Kubernetes 集群的,Kubernetes 中 Pod 有两个健康检查的机制:ReadinessProber 和 LivenessProber。


  • 其中 LivenessProber 是判断 Pod 是否活着,如果检查失败 Kubelet 就会尝试重启 Container;

  • ReadinessProber 是来判断业务是否 Ready,只有业务 Ready 的情况下才会把 Pod 挂载到 Kubernetes Service 的 EndPoint 中,这样可以保证 Pod 故障时对业务无损。


那么问题来了,Knative 的 Pod 中默认会有两个 Container:Queue-Proxy 和 user-container 。


前面两个健康检查机制你应该也发现了,流量的“前半路径”需要通过 Queue-Proxy 来判断是否可以转发流量到当前 Pod,而在 Kubernetes 的机制中,Pod 是否加入 Kubernetes Service EndPoint 完全是由 ReadinessProber 的结果决定的。而这两个机制是独立的,所以我们需要有一种方案来把这两个机制协调一致。这也是 Knative 作为一个 Serverless 编排引擎时需要对流量做更精细的控制要解决的问题。所以 Knative 最终是把 user-container 的 ReadinessProber 收敛到 Queue-Proxy 中,通过 Queue-Proxy 的结果来决定 Pod 的状态。


另外这个 Issue 中也提到在启动 istio 的情况下,kubelet 发起的 tcp 检查可能会被 Envoy 拦截,所以给 user-container 配置 TCP 探测器判断 user-container 是否 ready 也是不准的。这也是需要把 Readiness 收敛到 Queue-Proxy 的一个动机。


Knative 收敛 user-container 健康检查能力的方法是:


  • 置空 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 状态。

参考阅读

使用方法

如下所示可以在 Knative Service 中定义 Readiness。


apiVersion: serving.knative.dev/v1alpha1kind: Servicemetadata:  name: readiness-proberspec:  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
复制代码


从这个使用方式上来看,其实 Knative 是在逐渐收敛 user-container 配置,因为在 Serverless 模式中需要系统自动化处理很多逻辑,这些“系统行为”就不需要麻烦用户了。

小结

前面提到的三种健康检查机制的对比关系:



本文转载自阿里巴巴云原生微信公众号(ID:Alicloudnative),关注微服务、Serverless、容器、Service Mesh 等技术领域。


2019-11-12 10:512722

评论

发布
暂无评论
发现更多内容

聊聊「低代码」的实践之路

Java 架构 低代码

如何在微服务下保证事务的一致性 | 京东云技术团队

京东科技开发者

架构 微服务 事务 一致性 企业号 4 月 PK 榜

分布式存储技术(上):HDFS 与 Ceph的架构原理、特性、优缺点解析

星环科技

hdfs 分布式存储 Ceph

这一秒,困扰了程序员 50 年!

Java你猿哥

Java 程序员 ssm 计算机

从入门到精通,超详细的程序员Java学习路线指南

Java你猿哥

Java 数据库 Web ssm 死磕 Java 基础

阿里十年资深码农共享SpringCloud微服务架构实战文档

Java你猿哥

微服务架构 Spring Cloud ssm 架构设计 架构师

统一、飞鹤等快消龙头企业,如何抓住未来10年数智化的机遇?

用友BIP

用友iuap 用友技术大会 快消行业

MySQL8.0.32的安装与配置

Java你猿哥

Java MySQL ssm Java工程师

SysCare:为您的操作系统保驾护航

openEuler

Linux 操作系统 openEuler 内核 热补丁

企业数据平台建设的基石:构建统一的数据存算能力

星环科技

存算能力

请查收!一份2023年程序员不得不看的自救提升指南(彩色终极版)

Java你猿哥

Java 面试 JVM 面经

校企共建|阿里云与西安电子科技大学人才培养交流会顺利举行

云布道师

校企合作

如何创造数据资产价值?如何对内赋能业务运营,对外创造市场价值?

星环科技

数据资产 数据要素流通

分布式存储技术(下):宽表存储与全文搜索引擎的架构原理、特性、优缺点解析

星环科技

分布式 全文搜索

基于公共信箱的全量消息实现

百度Geek说

大数据 即时通讯 企业号 4 月 PK 榜 公共信箱

数栈V6.0全新产品矩阵发布,数据底座 EasyMR 焕新升级

袋鼠云数栈

大数据 基础软件 数字化转型

关于聚合根,领域事件的那点事---深入浅出理解DDD | 京东云技术团队

京东科技开发者

DDD 企业号 4 月 PK 榜 聚合根 领域事件

Rust-Shyper:基于 Rust 语言的高可靠、开源嵌入式 Hypervisor

openEuler

Linux rust 操作系统 虚拟机 嵌入式

度量分析开源社区健康度,助力企业开源生态健康发展——华为开源管理中心王晔晖

开源雨林

开源治理 OSPO OSS Compass CHAOSS

硬核!阿里P8耗时6月打造的架构师速成手册,颠覆你对架构师的认知

Java你猿哥

架构 分布式 ssm 软件架构 架构师

用友iuap 让企业数智化能力深入、让业务价值浅出

用友BIP

用友 用友iuap 用友技术大会 数智底座

分布式技术剖析

星环科技

分布式

权威学者、企业CFO荟聚上海国家会计学院,共探「智能会计 价值财务」

用友BIP

智能会计 价值财务 用友智能财务 业财融合

企业如何两步实现数据资产化?

星环科技

数据资产化

大语言模型的本质:会思考的狗、聪明的马和随机鹦鹉

FN0

AIGC 大语言模型

浅谈测试用例设计 | 京东云技术团队

京东科技开发者

测试 测试用例 测试用例设计 企业号 4 月 PK 榜

电信及互联网行业数据安全内控审计建设实践 | 盾见

极盾科技

数据安全

竞争焦点转向数智底座 用友能否再引领

用友BIP

用友iuap 用友技术大会 升级企业数智化底座

自动化回归测试平台 AREX 0.2.8 版本正式发布!

AREX 中文社区

自动化测试 接口测试 回归测试

字节二面:HashMap线程不安全体现在哪里?

Java你猿哥

Java 线程 ssm 架构师 HashMap底层原理

戴尔科技园动力计划,携手中南高科赋能中小企业数字化转型

科技热闻

Knative Serving 健康检查机制分析_服务革新_冬岛_InfoQ精选文章