上一篇用 Gateway API 把请求送到 Ready 后端。本篇定义 Ready 到底意味着什么并用 Metrics Server、资源请求与 HPA 构成闭环指标上升触发扩容负载下降后再受控缩容。一、痛点活着、就绪和启动完成不是一回事livenessProbe 判断容器是否陷入需要重启的故障readinessProbe 判断它是否应进入 Service 端点startupProbe 为慢启动应用提供独立启动窗口成功后才启用另外两类探针。把三者都指向同一个浅层/health会丢失语义尤其 liveness 依赖数据库时数据库故障可能让所有实例同时重启并放大事故。readiness 可检查接流量所需的关键依赖但要快速、有界并避免瞬时抖动。liveness 应主要检查进程内部不可恢复状态。startup 允许应用完成迁移、缓存预热等操作不过数据库迁移更适合独立 Job以免多个副本争抢执行。HPA 控制器周期读取指标计算期望副本并更新 Deployment 的 scale 子资源。CPU 利用率是实际 CPU 使用量与容器 CPU request 的比值没有 request 时HPA 无法为该容器正确计算这一指标。HPA 不是资源配置的替代品它依赖合理 requests。二、原理两个控制循环必须协调Deployment 控制副本与发布HPA 动态控制 replicas。启用 HPA 后不要让 GitOps 工具持续把静态 replicas 改回固定值否则两个控制器会争夺字段。可以从工作负载清单移除 replicas或配置 GitOps 忽略该差异并在 HPA 中表达最小与最大副本。扩容速度受指标采样、HPA 同步、调度、镜像拉取和应用就绪共同影响。面对突发流量仅靠 HPA 可能来不及应保留容量、预热镜像、设置合理最小副本并在入口限流。缩容还会终止实例需结合终止宽限、连接排空和 PodDisruptionBudget。下面的清单使用可产生 CPU 负载的 PHP Apache 官方示例模式探针检查根路径HPA 以 50% CPU 为目标。它是独立实验不依赖前文 Nginx 文件。运行前确保集群已安装 Metrics Serverkind 环境可能需要按其文档调整 kubelet TLS 设置。apiVersion:apps/v1kind:Deploymentmetadata:name:web-scalespec:selector:matchLabels:app:web-scaletemplate:metadata:labels:app:web-scalespec:containers:-name:webimage:registry.k8s.io/hpa-example:latestports:-name:httpcontainerPort:80resources:requests:cpu:100mmemory:32Milimits:cpu:500mmemory:128MistartupProbe:httpGet:path:/port:httpperiodSeconds:2failureThreshold:30readinessProbe:httpGet:path:/port:httpperiodSeconds:5failureThreshold:2livenessProbe:httpGet:path:/port:httpperiodSeconds:10failureThreshold:3---apiVersion:v1kind:Servicemetadata:name:web-scalespec:selector:app:web-scaleports:-port:80targetPort:http---apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:web-scalespec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:web-scaleminReplicas:2maxReplicas:8behavior:scaleDown:stabilizationWindowSeconds:120metrics:-type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:50三、实现产生负载并观察控制器先用kubectl top验证指标管线若出现 unknown等待采样或排查 Metrics Server不能继续声称 HPA 有效。脚本创建负载 Pod循环请求 Service观察 HPA 与 Pod删除负载后由于稳定窗口缩容不会立刻发生。#!/usr/bin/env bashset-euopipefail kubectl apply-fautoscale.yaml kubectl rollout status deployment/web-scale--timeout180s kubectlwait--forconditionReady pod-lappweb-scale--timeout120s kubectltoppods-lappweb-scale kubectl delete pod load-generator --ignore-not-found kubectl run load-generator\--imagebusybox:1.36.1\--restartNever\--command--sh-c\while true; do wget -q -O- http://web-scale /dev/null; doneforattemptin$(seq118);dokubectl get hpa web-scalereplicas$(kubectl get deployment web-scale-ojsonpath{.status.replicas})echoattempt${attempt}replicas${replicas:-0}if[${replicas:-0}-gt2];thenbreakfisleep10donekubectl get pods-lappweb-scale-owide kubectl describe hpa web-scale kubectl delete pod load-generatorechoload stopped; scale-down follows the stabilization policy预期 CPU 指标升高后副本数大于 2且不超过 8。具体时刻和数值由机器性能决定不应写死。若始终不扩容检查请求是否真正消耗 CPU、metrics 是否有值、request 是否存在以及 HPA events 中的原因。内存通常不是理想的缩容信号因为运行时可能保留已分配内存。队列消费者更适合按积压长度伸缩可使用自定义/外部指标或 KEDA。任何指标都要与业务容量关系明确每个副本每秒能处理多少请求、目标延迟是多少、扩容需要多久。四、踩坑探针也能制造故障探针超时过短、频率过高会增加负载在 CPU 节流时liveness 超时可能反复重启形成雪崩。先观测启动时间与健康端点延迟再设置 initialDelay、timeout、period 和 failureThreshold。HTTP 探针默认从节点访问 Pod IP因此端点必须监听正确接口与端口。readiness 失败会摘除流量却不重启容器这通常是依赖短暂不可用时的正确行为。liveness 失败会丢失进程内状态应谨慎。应用主动退出也是有效恢复策略由 kubelet 按 restartPolicy 重启不要把所有错误都堆进复杂探针。HPA 达到 maxReplicas 仍高延迟时继续扩容可能被数据库、配额或节点容量限制。Cluster Autoscaler 负责节点层扩容但也有分钟级延迟。需要入口限流、背压、队列和降级共同构成过载保护。五、验证从资源指标走向业务目标验收包含探针失败行为、扩容延迟、最大副本、缩容稳定性和发布期间 HPA 行为。可临时把 readiness 路径改错确认 Pod 从端点移除但容器不因 readiness 单独重启故障实验结束立即恢复并等待 rollout。生产告警不应只看副本数而要关联请求率、错误率、延迟、CPU 节流、Pending Pod 和 HPA 条件。目标是业务 SLO 下的容量闭环不是让 CPU 曲线好看。压力测试也要设停止条件避免在共享环境无限制造流量。下一篇将把 Deployment、Service、HPA 和配置整理成 Helm Chart用 values 管理环境差异并通过 lint、template 和原子升级形成可发布制品。伸缩参数应来自阶梯压测。固定副本数逐级提高请求速率记录吞吐、错误率、延迟、处理器、内存和依赖饱和点找出单副本在目标延迟下的安全容量再据此计算最小副本和最大副本。最大值还需受数据库连接、节点配额和成本约束。若每增加一个 Pod 就建立大量连接扩容反而可能把数据库压垮应先限制连接池并建立全链路容量模型。验收伸缩时同时记录发现负载、提出副本、实例调度、镜像就绪、进入端点五个时间点端到端扩容时间才是用户真正承受的窗口。对可预测高峰可以定时预扩容对不可预测突发则依靠容量余量、限流与降级。缩容前确认连接排空和后台任务可中断避免指标恢复正常后因为过快终止又产生错误峰值。压测结束后要确认临时负载已停止、额外副本按策略回落并保存指标时间窗与伸缩事件。这样下次修改资源请求或目标阈值时可以用同一负载模型比较而不是凭主观感受判断更快或更省。完成容量基线后下一篇会把工作负载、服务、配置与伸缩规则整理为可版本化的 Helm 软件包减少环境间的清单漂移。HPA 的核心计算可以离线复现。下面程序根据各 Pod 当前 CPU、request 和目标利用率估算期望副本并施加最小、最大副本边界。它解释了为什么缺少 request 时 CPU 利用率型 HPA 无法可靠工作。importmath cpu_usage_millicores[82,76,92]cpu_request_millicores100target_utilization60current_replicaslen(cpu_usage_millicores)min_replicas2max_replicas8ifcpu_request_millicores0:raiseValueError(CPU request must be positive)average_usagesum(cpu_usage_millicores)/current_replicas current_utilizationaverage_usage/cpu_request_millicores*100raw_desiredmath.ceil(current_replicas*current_utilization/target_utilization)desiredmax(min_replicas,min(max_replicas,raw_desired))print(fcurrent_replicas{current_replicas})print(faverage_cpu{average_usage:.1f}m)print(futilization{current_utilization:.1f}%)print(fdesired_replicas{desired})运行输出current_replicas3 average_cpu83.3m utilization83.3% desired_replicas5探针验收不能只看单次成功。第二个程序实现连续成功/失败阈值启动完成后连续两次 readiness 成功才接流量连续三次失败才摘流避免短暂抖动造成端点频繁进出。samples[False,True,True,False,True,False,False,False]success_threshold2failure_threshold3readyFalsesuccesses0failures0forindex,healthyinenumerate(samples,start1):ifhealthy:successes1failures0else:failures1successes0ifnotreadyandsuccessessuccess_threshold:readyTrueifreadyandfailuresfailure_threshold:readyFalseprint(fsample{index}healthy{healthy}fsuccesses{successes}failures{failures}ready{ready})运行输出sample1 healthyFalse successes0 failures1 readyFalse sample2 healthyTrue successes1 failures0 readyFalse sample3 healthyTrue successes2 failures0 readyTrue sample4 healthyFalse successes0 failures1 readyTrue sample5 healthyTrue successes1 failures0 readyTrue sample6 healthyFalse successes0 failures1 readyTrue sample7 healthyFalse successes0 failures2 readyTrue sample8 healthyFalse successes0 failures3 readyFalse参考来源Configure Liveness, Readiness and Startup ProbesHorizontal Pod AutoscalingResource Metrics PipelineKEDA Documentation 觉得有用就点个赞 收藏方便回头查阅有疑问直接在评论区留言我看到都会回。 本文属于《Kubernetes 上手实战》系列持续更新关注不迷路。 文章里的代码都能直接跑。想要可直接 clone 的完整工程 配套部署脚本 / 踩坑清单评论一声或发邮件到cj2664qq.com我免费发你。如果你正好在做类似系统、或有工程化难题想找人做也欢迎邮件聊一句——我按实际情况评估能落地的就接单或出方案。评论和邮件都能直接找到我不用跳别的平台。
上一篇用 Gateway API 把请求送到 Ready 后端。本篇定义 Ready 到底意味着什么并用 Metrics Server、资源请求与 HPA 构成闭环指标上升触发扩容负载下降后再受控缩容。一、痛点活着、就绪和启动完成不是一回事livenessProbe 判断容器是否陷入需要重启的故障readinessProbe 判断它是否应进入 Service 端点startupProbe 为慢启动应用提供独立启动窗口成功后才启用另外两类探针。把三者都指向同一个浅层/health会丢失语义尤其 liveness 依赖数据库时数据库故障可能让所有实例同时重启并放大事故。readiness 可检查接流量所需的关键依赖但要快速、有界并避免瞬时抖动。liveness 应主要检查进程内部不可恢复状态。startup 允许应用完成迁移、缓存预热等操作不过数据库迁移更适合独立 Job以免多个副本争抢执行。HPA 控制器周期读取指标计算期望副本并更新 Deployment 的 scale 子资源。CPU 利用率是实际 CPU 使用量与容器 CPU request 的比值没有 request 时HPA 无法为该容器正确计算这一指标。HPA 不是资源配置的替代品它依赖合理 requests。二、原理两个控制循环必须协调Deployment 控制副本与发布HPA 动态控制 replicas。启用 HPA 后不要让 GitOps 工具持续把静态 replicas 改回固定值否则两个控制器会争夺字段。可以从工作负载清单移除 replicas或配置 GitOps 忽略该差异并在 HPA 中表达最小与最大副本。扩容速度受指标采样、HPA 同步、调度、镜像拉取和应用就绪共同影响。面对突发流量仅靠 HPA 可能来不及应保留容量、预热镜像、设置合理最小副本并在入口限流。缩容还会终止实例需结合终止宽限、连接排空和 PodDisruptionBudget。下面的清单使用可产生 CPU 负载的 PHP Apache 官方示例模式探针检查根路径HPA 以 50% CPU 为目标。它是独立实验不依赖前文 Nginx 文件。运行前确保集群已安装 Metrics Serverkind 环境可能需要按其文档调整 kubelet TLS 设置。apiVersion:apps/v1kind:Deploymentmetadata:name:web-scalespec:selector:matchLabels:app:web-scaletemplate:metadata:labels:app:web-scalespec:containers:-name:webimage:registry.k8s.io/hpa-example:latestports:-name:httpcontainerPort:80resources:requests:cpu:100mmemory:32Milimits:cpu:500mmemory:128MistartupProbe:httpGet:path:/port:httpperiodSeconds:2failureThreshold:30readinessProbe:httpGet:path:/port:httpperiodSeconds:5failureThreshold:2livenessProbe:httpGet:path:/port:httpperiodSeconds:10failureThreshold:3---apiVersion:v1kind:Servicemetadata:name:web-scalespec:selector:app:web-scaleports:-port:80targetPort:http---apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:web-scalespec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:web-scaleminReplicas:2maxReplicas:8behavior:scaleDown:stabilizationWindowSeconds:120metrics:-type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:50三、实现产生负载并观察控制器先用kubectl top验证指标管线若出现 unknown等待采样或排查 Metrics Server不能继续声称 HPA 有效。脚本创建负载 Pod循环请求 Service观察 HPA 与 Pod删除负载后由于稳定窗口缩容不会立刻发生。#!/usr/bin/env bashset-euopipefail kubectl apply-fautoscale.yaml kubectl rollout status deployment/web-scale--timeout180s kubectlwait--forconditionReady pod-lappweb-scale--timeout120s kubectltoppods-lappweb-scale kubectl delete pod load-generator --ignore-not-found kubectl run load-generator\--imagebusybox:1.36.1\--restartNever\--command--sh-c\while true; do wget -q -O- http://web-scale /dev/null; doneforattemptin$(seq118);dokubectl get hpa web-scalereplicas$(kubectl get deployment web-scale-ojsonpath{.status.replicas})echoattempt${attempt}replicas${replicas:-0}if[${replicas:-0}-gt2];thenbreakfisleep10donekubectl get pods-lappweb-scale-owide kubectl describe hpa web-scale kubectl delete pod load-generatorechoload stopped; scale-down follows the stabilization policy预期 CPU 指标升高后副本数大于 2且不超过 8。具体时刻和数值由机器性能决定不应写死。若始终不扩容检查请求是否真正消耗 CPU、metrics 是否有值、request 是否存在以及 HPA events 中的原因。内存通常不是理想的缩容信号因为运行时可能保留已分配内存。队列消费者更适合按积压长度伸缩可使用自定义/外部指标或 KEDA。任何指标都要与业务容量关系明确每个副本每秒能处理多少请求、目标延迟是多少、扩容需要多久。四、踩坑探针也能制造故障探针超时过短、频率过高会增加负载在 CPU 节流时liveness 超时可能反复重启形成雪崩。先观测启动时间与健康端点延迟再设置 initialDelay、timeout、period 和 failureThreshold。HTTP 探针默认从节点访问 Pod IP因此端点必须监听正确接口与端口。readiness 失败会摘除流量却不重启容器这通常是依赖短暂不可用时的正确行为。liveness 失败会丢失进程内状态应谨慎。应用主动退出也是有效恢复策略由 kubelet 按 restartPolicy 重启不要把所有错误都堆进复杂探针。HPA 达到 maxReplicas 仍高延迟时继续扩容可能被数据库、配额或节点容量限制。Cluster Autoscaler 负责节点层扩容但也有分钟级延迟。需要入口限流、背压、队列和降级共同构成过载保护。五、验证从资源指标走向业务目标验收包含探针失败行为、扩容延迟、最大副本、缩容稳定性和发布期间 HPA 行为。可临时把 readiness 路径改错确认 Pod 从端点移除但容器不因 readiness 单独重启故障实验结束立即恢复并等待 rollout。生产告警不应只看副本数而要关联请求率、错误率、延迟、CPU 节流、Pending Pod 和 HPA 条件。目标是业务 SLO 下的容量闭环不是让 CPU 曲线好看。压力测试也要设停止条件避免在共享环境无限制造流量。下一篇将把 Deployment、Service、HPA 和配置整理成 Helm Chart用 values 管理环境差异并通过 lint、template 和原子升级形成可发布制品。伸缩参数应来自阶梯压测。固定副本数逐级提高请求速率记录吞吐、错误率、延迟、处理器、内存和依赖饱和点找出单副本在目标延迟下的安全容量再据此计算最小副本和最大副本。最大值还需受数据库连接、节点配额和成本约束。若每增加一个 Pod 就建立大量连接扩容反而可能把数据库压垮应先限制连接池并建立全链路容量模型。验收伸缩时同时记录发现负载、提出副本、实例调度、镜像就绪、进入端点五个时间点端到端扩容时间才是用户真正承受的窗口。对可预测高峰可以定时预扩容对不可预测突发则依靠容量余量、限流与降级。缩容前确认连接排空和后台任务可中断避免指标恢复正常后因为过快终止又产生错误峰值。压测结束后要确认临时负载已停止、额外副本按策略回落并保存指标时间窗与伸缩事件。这样下次修改资源请求或目标阈值时可以用同一负载模型比较而不是凭主观感受判断更快或更省。完成容量基线后下一篇会把工作负载、服务、配置与伸缩规则整理为可版本化的 Helm 软件包减少环境间的清单漂移。HPA 的核心计算可以离线复现。下面程序根据各 Pod 当前 CPU、request 和目标利用率估算期望副本并施加最小、最大副本边界。它解释了为什么缺少 request 时 CPU 利用率型 HPA 无法可靠工作。importmath cpu_usage_millicores[82,76,92]cpu_request_millicores100target_utilization60current_replicaslen(cpu_usage_millicores)min_replicas2max_replicas8ifcpu_request_millicores0:raiseValueError(CPU request must be positive)average_usagesum(cpu_usage_millicores)/current_replicas current_utilizationaverage_usage/cpu_request_millicores*100raw_desiredmath.ceil(current_replicas*current_utilization/target_utilization)desiredmax(min_replicas,min(max_replicas,raw_desired))print(fcurrent_replicas{current_replicas})print(faverage_cpu{average_usage:.1f}m)print(futilization{current_utilization:.1f}%)print(fdesired_replicas{desired})运行输出current_replicas3 average_cpu83.3m utilization83.3% desired_replicas5探针验收不能只看单次成功。第二个程序实现连续成功/失败阈值启动完成后连续两次 readiness 成功才接流量连续三次失败才摘流避免短暂抖动造成端点频繁进出。samples[False,True,True,False,True,False,False,False]success_threshold2failure_threshold3readyFalsesuccesses0failures0forindex,healthyinenumerate(samples,start1):ifhealthy:successes1failures0else:failures1successes0ifnotreadyandsuccessessuccess_threshold:readyTrueifreadyandfailuresfailure_threshold:readyFalseprint(fsample{index}healthy{healthy}fsuccesses{successes}failures{failures}ready{ready})运行输出sample1 healthyFalse successes0 failures1 readyFalse sample2 healthyTrue successes1 failures0 readyFalse sample3 healthyTrue successes2 failures0 readyTrue sample4 healthyFalse successes0 failures1 readyTrue sample5 healthyTrue successes1 failures0 readyTrue sample6 healthyFalse successes0 failures1 readyTrue sample7 healthyFalse successes0 failures2 readyTrue sample8 healthyFalse successes0 failures3 readyFalse参考来源Configure Liveness, Readiness and Startup ProbesHorizontal Pod AutoscalingResource Metrics PipelineKEDA Documentation 觉得有用就点个赞 收藏方便回头查阅有疑问直接在评论区留言我看到都会回。 本文属于《Kubernetes 上手实战》系列持续更新关注不迷路。 文章里的代码都能直接跑。想要可直接 clone 的完整工程 配套部署脚本 / 踩坑清单评论一声或发邮件到cj2664qq.com我免费发你。如果你正好在做类似系统、或有工程化难题想找人做也欢迎邮件聊一句——我按实际情况评估能落地的就接单或出方案。评论和邮件都能直接找到我不用跳别的平台。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
