京公网安备11010502063487号发布一个新版本的时候,用户会不会看到错误?错误从哪来?readinessProbe、preStop、应用优雅退出各解决哪一段?这篇用 kind 集群上的 3 副本 Deployment 和集群里的压测客户端,把每一种配置的失败数、失败类型逐项量出来。
客户端请求 1173 个,失败 157 个(13.38%),其中 /slow 请求失败 2 个;失败类型 {'refused': 126, 'timeout': 31};第一个到最后一个失败相隔 4.0 s;最长一段没有任何成功响应的间隔 2.41 s;客户端第一次收到 v2 在 8.8 s,最后一次收到 v1 在 6.4 s(从客户端开始算);kubectl rollout 耗时 1 s没有 readinessProbe 时新 Pod 一启动就算 Ready,应用还没监听;旧 Pod 同时被杀,出现了 2.41 s 没有任何成功响应的窗口。
客户端请求 2229 个,失败 65 个(2.92%),其中 /slow 请求失败 16 个;失败类型 {'reset': 16, 'refused': 4, 'timeout': 45};第一个到最后一个失败相隔 9.6 s;最长一段没有任何成功响应的间隔 0.11 s;客户端第一次收到 v2 在 10.4 s,最后一次收到 v1 在 18.1 s(从客户端开始算);kubectl rollout 耗时 13 s新 Pod 没准备好不接流量,启动阶段的 refused 基本消失;终止阶段的 reset 和 timeout 还在。
客户端请求 2495 个,失败 0 个(0.00%),其中 /slow 请求失败 0 个;失败类型 {};没有失败;最长一段没有任何成功响应的间隔 1.02 s;客户端第一次收到 v2 在 9.4 s,最后一次收到 v1 在 18.3 s(从客户端开始算);kubectl rollout 耗时 12 s让旧 Pod 在被摘出 Service 的传播期间继续活着,这次测量终止阶段的失败是 0。
客户端请求 2464 个,失败 0 个(0.00%),其中 /slow 请求失败 0 个;失败类型 {};没有失败;最长一段没有任何成功响应的间隔 1.00 s;客户端第一次收到 v2 在 9.0 s,最后一次收到 v1 在 18.0 s(从客户端开始算);kubectl rollout 耗时 12 s收到 SIGTERM 后继续服务到空闲,不用 preStop 也是 0 失败;但这个启发式依赖流量模式。
客户端请求 2593 个,失败 0 个(0.00%),其中 /slow 请求失败 0 个;失败类型 {};没有失败;最长一段没有任何成功响应的间隔 1.00 s;客户端第一次收到 v2 在 9.4 s,最后一次收到 v1 在 19.3 s(从客户端开始算);kubectl rollout 耗时 13 s三种有保护的配置失败都是 0,差别在别的场景里才看得出来。
keep-alive、readinessProbe + preStop sleep 5、应用立刻退出:请求 2499 个,失败 53 个(2.12%),其中 /slow 失败 0 个;失败类型 {'reset': 53};第一个到最后一个失败相隔 8.5 s;最长无成功响应的间隔 1.00 s
keep-alive、readinessProbe + preStop sleep 5 + 应用优雅退出:请求 2498 个,失败 0 个(0.00%),其中 /slow 失败 0 个;失败类型 {};没有失败;最长无成功响应的间隔 1.00 s
说明(哪些是测到的,哪些是推测)
每种配置只跑了一次,没有重复,失败数每次运行会不一样(开发中的一次运行里,第一种配置失败 129 个,第二种读日志时客户端还没结束);「最长一段没有成功响应的间隔」在没有任何失败的几种配置里也有大约 1 s,我没有查清原因(可能是客户端自己的停顿),所以只有第一种配置里的 2 s 多的间隔能说明问题;timeout 失败的原因是推测(旧 Pod 已经删掉,往它的 IP 发的连接没有任何回应),没有抓包验证;第二种配置里 reset 的数量与 /slow 失败的数量相同,我认为是正在处理的慢请求被进程退出打断,没有逐条核对;应用的「优雅退出」是我手写的(SIGTERM 后继续服务到空闲 1 s),不代表框架自带的行为preStop 管不到已建立的长连接,进程退出时连接被重置;优雅退出时响应带 Connection: close 才能让客户端换连接。