11 | 弹性伸缩与 Serverless用 HPA 让 AI 服务「峰谷自适应」系列目录《基于华为云 FlexusX 四节点集群的云计算全栈实操》PaaS 篇 · 收尾篇本篇对应课程模块弹性伸缩 / 云原生 Serverless 理念引子前两篇我们把 K3s 集群建起来又把情感分析推理服务部署上去跑通了 4/4 正确分类。一切看起来很美——但有个问题没解决服务是按固定副本数跑的。固定 3 副本意味着流量小的时候2 个 Pod 在空转烧钱流量突增的时候3 个 Pod 被打满、请求排队超时。这正是传统「买定离手」式容量规划的痛点。云计算的终极承诺是按需付费、峰谷自适应——这就是 Serverless 的核心理念。本篇我们不讲抽象的 FaaS而是用 Kubernetes 原生的HPAHorizontal Pod Autoscaler水平 Pod 自动伸缩让上篇那个 AI 服务在压测时自动从 3 副本扩到 8 副本负载消失后自动缩回 2 副本。这是整个系列的技术收尾也是「云原生」四个字最直观的注脚。文末我还会用一段11 篇实战全景回顾把从裸机到 Serverless 的整条链路串起来。背景与理论HPA 的闭环控制《深入浅出云计算》把「弹性」列为云计算相对传统 IDC 的四大核心价值之一。在 K8s 里弹性分三种弹性类型对象说明HPA水平Pod 副本数加机器加副本本篇主角VPA垂直单 Pod 资源加 CPU/内存需重建 PodCluster Autoscaler节点数副本不够时加节点需对接云厂商HPA 是一个典型的负反馈闭环控制系统┌──────────────┐ 指标 ┌──────────────────┐ │ metrics-server│◀────────│ 各 Pod 实时 CPU │ └──────┬───────┘ └──────────────────┘ │ 暴露指标 ▼ ┌──────────────┐ 比对 ┌──────────────────┐ │ HPA Controller│─────────│ 目标利用率 50% │ └──────┬───────┘ └──────────────────┘ │ 调节 replicas ▼ ┌──────────────┐ │ Deployment │ 期望副本 3 → 8 │ (ReplicaSet) │ └──────────────┘工作原理一句话metrics-server 采集 Pod 的 CPU/内存指标 → HPA 控制器周期性默认 15s比对「当前利用率」与「目标利用率」→ 按公式算出期望副本数 → 修改 Deployment 的 replicas。副本变了调度器把新 Pod 排到各节点流量自然被分摊。HPA 副本数公式简化期望副本 ceil(当前指标 / 目标指标)。当 CPU 实际 188%、目标 50%即ceil(188/50)4倍于当前负载基准——但受maxReplicas封顶最终触顶到 8。稳定窗口stabilization window是 HPA 防止「抖动」的关键扩容快默认无延迟或很短缩容慢默认 5 分钟。否则流量一抖就缩缩完又被打满反复横跳。这 5 分钟是工程上「宁多勿少」的权衡。架构metrics-server (采集 Pod CPU) │ ▼ HPA: sentiment-ai target50% min2 max8 │ 调节 replicas ▼ Deployment 期望副本变化: 3 →(压测)→ 8 →(稳定窗口后)→ 2 │ ├── 新 Pod 调度到 node1/node3/node4topologySpread 均衡 │ NodePort 30800 ── kube-proxy ──▶ 全部可用 Pod 分担流量 压测器: node1 后台 20 路并发 POST /predict 持续 90s环境与准备节点弹性公网IP私有IP规格系统K8s角色node1113.47.6.41192.168.0.2528vCPU/16GiBUbuntu 24.04.4control-planenode31.94.220.182192.168.0.2418vCPU/16GiBUbuntu 24.04.4workernode4124.70.102.139192.168.0.1508vCPU/16GiBUbuntu 24.04.4worker沿用前两篇集群。本篇新增依赖metrics-server——K3s 默认未安装metrics-server它内置的是轻量指标但 HPA 需要标准 metrics.k8s.io API。需先部署# 部署 metrics-server国内可用阿里云镜像kubectl apply-fhttps://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml# 若因证书问题无法采集可临时加 --kubelet-insecure-tls生产不建议长期开启验证指标可用kubectltopnodes kubectltoppods注意HPA 用的是 metrics-server 提供的metrics.k8s.io/v1beta1资源指标。CPU 利用率 Pod 实际 CPU / Pod 的requests.cpu。所以 Pod 必须配置resources.requests.cpu否则 HPA 无法计算利用率我们上篇已配requests.cpu: 100m。实操步骤1. 创建 HPA对sentiment-ai配置目标 CPU 50%最小 2 副本、最大 8 副本kubectl autoscale deploy/sentiment-ai--cpu50%--min2--max8等价于下面这段 YAML两种写法皆可apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:sentiment-aispec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:sentiment-aiminReplicas:2maxReplicas:8metrics:-type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:50behavior:scaleDown:stabilizationWindowSeconds:300# 默认 5 分钟稳定窗口2. 压测前基线先确认空闲状态——各节点 CPU 几乎为 0%副本为 3kubectltopnodes kubectl get hpa3. 施加负载在 node1 后台发起20 路并发循环 POST /predict持续 90 秒用curl循环或hey/ab/k6均可# 简易压测后台运行 90sforiin$(seq120);do(whiletrue;docurl-s-XPOST http://127.0.0.1:30800/predict\-HContent-Type: application/json\-d{text:this is absolutely wonderful, i love it}done)donesleep90;killallcurl4. 观察扩容压测约 90 秒后查看 HPA 状态。真实输出实测以下来自results/16_hpa_autoscale.txt。创建 HPA$ kubectl autoscale deploy/sentiment-ai --cpu50% --min2 --max8 horizontalpodautoscaler.autoscaling/sentiment-ai autoscaled压测前基线kubectl top nodes: ecs-71b9-0001 64m 0% ecs-71b9-0003 67m 0% ecs-71b9-0004 82m 1% REPLICAS: 3空闲时三节点 CPU 利用率 0%~1%副本 3——符合预期此时尚未触发缩容到 min2因为 HPA 只在有负载偏差时调节初始 3 副本在 [2,8] 区间内合法。压测中约 90s 后自动扩容到上限NAME TARGETS MINPODS MAXPODS REPLICAS sentiment-ai cpu: 188%/50% 2 8 8 Pod 数量8跨 3 节点分布 ecs-71b9-0001 x3 ecs-71b9-0003 x3 ecs-71b9-0004 x2CPU 利用率飙升到188%远超 50% 目标HPA 在约 1 分钟内把副本从 3 拉到8触顶 max。新副本自动跨 3 节点调度node1×3、node3×3、node4×2受 topologySpreadConstraints 约束大体均衡。结论实测原文要点1. HPA 依据实时 CPU 指标188% 50% 目标在 ~1 分钟内将副本 3 - 8触顶 max 2. 新副本自动跨节点调度承接突发流量 3. 负载消失后HPA 在默认 5 分钟稳定窗口后自动缩容回 min2 4. 这正是 Serverless「按需弹性、峰谷自适应」的核心能力在 K8s 上的体现 生产可进一步用 KEDA/Knative 实现请求驱动的 scale-to-zero深度解读这就是 Serverless 的精髓很多人把 Serverless 等同于「函数计算FaaS」那是狭义理解。Serverless 的本质是「开发者不关心服务器只关心代码/逻辑按实际用量付费」。HPA 让我们看到了它的前半段按需弹性流量来了副本自动涨走了自动降。你不用提前买好峰值容量。峰谷自适应白天高峰 8 副本扛半夜 2 副本歇着资源不空转。但与真正的 Serverless/FaaS还有一道鸿沟——scale-to-zero缩容到零能力K8s HPA真 ServerlessKnative/KEDA/OpenFaaS扩容触发CPU/内存等指标HTTP 请求、消息队列、定时等事件驱动缩容下限minReplicas: 1至少留 1可缩到0无流量不占资源冷启动无Pod 常驻有请求到来才拉起需应对冷启延迟计费粒度按节点/Pod 常驻按实际调用次数/时长HPA 的minReplicas最低是 1即使设为 0K8s 1.16 也支持 scaledown 到 0 但需特殊配置且少有人用。要真正做到「无流量零成本」需要 KEDA基于事件的驱动伸缩支持缩到 0或 Knative Serving基于请求数原生 scale-to-zero。一句话总结本篇HPA 是 K8s 上的「半 Serverless」——它解决了弹性伸缩但还留着 1 个常驻 Pod真正的Serverless 把那最后 1 个也省了代价是冷启动延迟。选型时延迟敏感选 HPA 常驻成本极致选 KEDA/Knative。踩坑与排障重点坑 1HPA 一直unknown/ 不生效现象kubectl get hpa显示TARGETS unknown/50%副本不变。根因90% 概率没装 metrics-server或 Pod 没配resources.requests.cpu。HPA 算不出「利用率 实际/请求」就无法决策。排查kubectltoppods# 若报错说明 metrics-server 没好kubectl get hpa-oyaml# 看 status.conditions 的 message解决装好 metrics-server并确保 Deployment 里有requests.cpu。坑 2扩容快、缩容慢误以为「卡住」压测一停副本没立刻降——这是正常行为。HPA 默认缩容稳定窗口 5 分钟目的是防止抖动。别手贱去手动scale让控制器自己收。坑 3副本触顶 max 仍不够本篇 CPU 188% 直接触顶 8说明单 Pod 算力已是瓶颈。此时再怎么加副本也受限于节点总 CPU3×8vCPU。该上 Cluster Autoscaler 加节点或优化模型/换更强实例规格HPA 不是万能药。生产建议与成本价值容量规划的新范式有了 HPA你不再需要「按峰值买定」。按平均负载配minReplicas把maxReplicas交给突发。以本集群为例平时 2~3 副本约占 2~3 个 vCPU大促/峰值自动顶到 8 副本吃满约 8 个 vCPU峰值过后 5 分钟自动回落。成本价值假设峰值每天只占 2 小时固定 8 副本一年白烧 22 小时/天的算力HPA 模式下这部分直接省掉——对长期运行的在线服务弹性伸缩省下的钱相当可观。生产加固清单同时配 CPU 内存 可选QPS 多指标 HPAmaxReplicas要卡住防止指标异常导致无限扩容把节点打爆配合PodDisruptionBudget防止缩容/驱逐时一次性干掉太多副本真正想 scale-to-zero引入KEDA接 Kafka/HTTP/RabbitMQ 等事件源超大规模再上Cluster Autoscaler / Karpenter做节点级弹性。11 篇实战全景回顾 云计算学习心得写到这里整个《基于华为云 FlexusX 四节点集群的云计算全栈实操》系列就完整了。回头看这 11 篇是一条清晰的「由底向上」的云原生能力栈篇章主题核心收获01~03云主机 / 网络 / 安全组四节点 FlexusX 基盘VPC/安全组打通04~05块存储 / 对象存储EVS 持久化、OBS 非结构化存储06~07数据库 / 负载均衡RDS 托管库、ELB 流量入口08监控告警CES 指标 阈值告警闭环09K3s 多节点 K8s 集群容器编排四大能力LB/自愈/伸缩/滚动更新10云上 AI 推理服务模型容器化、containerd 镜像交付、纯 CPU 推理11HPA 弹性伸缩Serverless 式峰谷自适应本篇几条贯穿始终的学习心得云不是「远程电脑」而是「能力的拼装」。计算、存储、网络、数据库、负载均衡、监控、编排——每个都是独立可替换的乐高块。真正的云工程师价值在于「按需拼装」而非「单点深挖」。能声明式就不要命令式。从安全组规则到 K8s YAML声明终态让系统具备自愈与可复现。本文 HPA 一句话配置抵过人工 7×24 盯盘。成本意识要长在骨子里。弹性伸缩、按需付费不是口号——它是 HPA 把 8 副本在低谷自动缩回 2 的真实账单节省是纯 CPU 跑中小模型而不必上 GPU 的理性取舍。踩坑即资产。regestries.yaml 镜像加速、containerd 镜像交付、metrics-server 缺失……这些真实踩过的坑比任何文档都记得牢。云原生是终点也是起点。K8s HPA 已摸到 Serverless 的门槛而 KEDA/Knative/OpenFaaS、Service Mesh、GitOps 才是下一程。技术没有终点只有不断把「人工运维」变成「系统自治」的过程。小结本篇我们用 HPA 给情感分析服务装上了「弹性引擎」压测前三节点 CPU 0%~1%副本 3压测中CPU 冲到 188%约 1 分钟内副本3 → 8触顶 max跨 3 节点承接流量压测后默认 5 分钟稳定窗口内自动缩回min2。这就是 Serverless「按需弹性、峰谷自适应」理念在 K8s 上的真实体现。HPA 是「半 Serverless」——它解决了弹性但留着常驻副本要彻底 scale-to-zero请上 KEDA/Knative。至此从一台裸云主机到能自愈、能伸缩、能跑 AI 的云原生集群全栈实操闭环完成。感谢你一路同行。配置与实测引用HPA 实测../results/16_hpa_autoscale.txtAI 服务部署../k8s/ai-service.yamlAI 服务代码../ai-service/app.py集群基础../results/14_k8s_cluster.txt、../results/15_ai_inference.txt
11 | 弹性伸缩与 Serverless：用 HPA 让 AI 服务「峰谷自适应」
发布时间：2026/7/28 16:03:06
11 | 弹性伸缩与 Serverless用 HPA 让 AI 服务「峰谷自适应」系列目录《基于华为云 FlexusX 四节点集群的云计算全栈实操》PaaS 篇 · 收尾篇本篇对应课程模块弹性伸缩 / 云原生 Serverless 理念引子前两篇我们把 K3s 集群建起来又把情感分析推理服务部署上去跑通了 4/4 正确分类。一切看起来很美——但有个问题没解决服务是按固定副本数跑的。固定 3 副本意味着流量小的时候2 个 Pod 在空转烧钱流量突增的时候3 个 Pod 被打满、请求排队超时。这正是传统「买定离手」式容量规划的痛点。云计算的终极承诺是按需付费、峰谷自适应——这就是 Serverless 的核心理念。本篇我们不讲抽象的 FaaS而是用 Kubernetes 原生的HPAHorizontal Pod Autoscaler水平 Pod 自动伸缩让上篇那个 AI 服务在压测时自动从 3 副本扩到 8 副本负载消失后自动缩回 2 副本。这是整个系列的技术收尾也是「云原生」四个字最直观的注脚。文末我还会用一段11 篇实战全景回顾把从裸机到 Serverless 的整条链路串起来。背景与理论HPA 的闭环控制《深入浅出云计算》把「弹性」列为云计算相对传统 IDC 的四大核心价值之一。在 K8s 里弹性分三种弹性类型对象说明HPA水平Pod 副本数加机器加副本本篇主角VPA垂直单 Pod 资源加 CPU/内存需重建 PodCluster Autoscaler节点数副本不够时加节点需对接云厂商HPA 是一个典型的负反馈闭环控制系统┌──────────────┐ 指标 ┌──────────────────┐ │ metrics-server│◀────────│ 各 Pod 实时 CPU │ └──────┬───────┘ └──────────────────┘ │ 暴露指标 ▼ ┌──────────────┐ 比对 ┌──────────────────┐ │ HPA Controller│─────────│ 目标利用率 50% │ └──────┬───────┘ └──────────────────┘ │ 调节 replicas ▼ ┌──────────────┐ │ Deployment │ 期望副本 3 → 8 │ (ReplicaSet) │ └──────────────┘工作原理一句话metrics-server 采集 Pod 的 CPU/内存指标 → HPA 控制器周期性默认 15s比对「当前利用率」与「目标利用率」→ 按公式算出期望副本数 → 修改 Deployment 的 replicas。副本变了调度器把新 Pod 排到各节点流量自然被分摊。HPA 副本数公式简化期望副本 ceil(当前指标 / 目标指标)。当 CPU 实际 188%、目标 50%即ceil(188/50)4倍于当前负载基准——但受maxReplicas封顶最终触顶到 8。稳定窗口stabilization window是 HPA 防止「抖动」的关键扩容快默认无延迟或很短缩容慢默认 5 分钟。否则流量一抖就缩缩完又被打满反复横跳。这 5 分钟是工程上「宁多勿少」的权衡。架构metrics-server (采集 Pod CPU) │ ▼ HPA: sentiment-ai target50% min2 max8 │ 调节 replicas ▼ Deployment 期望副本变化: 3 →(压测)→ 8 →(稳定窗口后)→ 2 │ ├── 新 Pod 调度到 node1/node3/node4topologySpread 均衡 │ NodePort 30800 ── kube-proxy ──▶ 全部可用 Pod 分担流量 压测器: node1 后台 20 路并发 POST /predict 持续 90s环境与准备节点弹性公网IP私有IP规格系统K8s角色node1113.47.6.41192.168.0.2528vCPU/16GiBUbuntu 24.04.4control-planenode31.94.220.182192.168.0.2418vCPU/16GiBUbuntu 24.04.4workernode4124.70.102.139192.168.0.1508vCPU/16GiBUbuntu 24.04.4worker沿用前两篇集群。本篇新增依赖metrics-server——K3s 默认未安装metrics-server它内置的是轻量指标但 HPA 需要标准 metrics.k8s.io API。需先部署# 部署 metrics-server国内可用阿里云镜像kubectl apply-fhttps://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml# 若因证书问题无法采集可临时加 --kubelet-insecure-tls生产不建议长期开启验证指标可用kubectltopnodes kubectltoppods注意HPA 用的是 metrics-server 提供的metrics.k8s.io/v1beta1资源指标。CPU 利用率 Pod 实际 CPU / Pod 的requests.cpu。所以 Pod 必须配置resources.requests.cpu否则 HPA 无法计算利用率我们上篇已配requests.cpu: 100m。实操步骤1. 创建 HPA对sentiment-ai配置目标 CPU 50%最小 2 副本、最大 8 副本kubectl autoscale deploy/sentiment-ai--cpu50%--min2--max8等价于下面这段 YAML两种写法皆可apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:sentiment-aispec:scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:sentiment-aiminReplicas:2maxReplicas:8metrics:-type:Resourceresource:name:cputarget:type:UtilizationaverageUtilization:50behavior:scaleDown:stabilizationWindowSeconds:300# 默认 5 分钟稳定窗口2. 压测前基线先确认空闲状态——各节点 CPU 几乎为 0%副本为 3kubectltopnodes kubectl get hpa3. 施加负载在 node1 后台发起20 路并发循环 POST /predict持续 90 秒用curl循环或hey/ab/k6均可# 简易压测后台运行 90sforiin$(seq120);do(whiletrue;docurl-s-XPOST http://127.0.0.1:30800/predict\-HContent-Type: application/json\-d{text:this is absolutely wonderful, i love it}done)donesleep90;killallcurl4. 观察扩容压测约 90 秒后查看 HPA 状态。真实输出实测以下来自results/16_hpa_autoscale.txt。创建 HPA$ kubectl autoscale deploy/sentiment-ai --cpu50% --min2 --max8 horizontalpodautoscaler.autoscaling/sentiment-ai autoscaled压测前基线kubectl top nodes: ecs-71b9-0001 64m 0% ecs-71b9-0003 67m 0% ecs-71b9-0004 82m 1% REPLICAS: 3空闲时三节点 CPU 利用率 0%~1%副本 3——符合预期此时尚未触发缩容到 min2因为 HPA 只在有负载偏差时调节初始 3 副本在 [2,8] 区间内合法。压测中约 90s 后自动扩容到上限NAME TARGETS MINPODS MAXPODS REPLICAS sentiment-ai cpu: 188%/50% 2 8 8 Pod 数量8跨 3 节点分布 ecs-71b9-0001 x3 ecs-71b9-0003 x3 ecs-71b9-0004 x2CPU 利用率飙升到188%远超 50% 目标HPA 在约 1 分钟内把副本从 3 拉到8触顶 max。新副本自动跨 3 节点调度node1×3、node3×3、node4×2受 topologySpreadConstraints 约束大体均衡。结论实测原文要点1. HPA 依据实时 CPU 指标188% 50% 目标在 ~1 分钟内将副本 3 - 8触顶 max 2. 新副本自动跨节点调度承接突发流量 3. 负载消失后HPA 在默认 5 分钟稳定窗口后自动缩容回 min2 4. 这正是 Serverless「按需弹性、峰谷自适应」的核心能力在 K8s 上的体现 生产可进一步用 KEDA/Knative 实现请求驱动的 scale-to-zero深度解读这就是 Serverless 的精髓很多人把 Serverless 等同于「函数计算FaaS」那是狭义理解。Serverless 的本质是「开发者不关心服务器只关心代码/逻辑按实际用量付费」。HPA 让我们看到了它的前半段按需弹性流量来了副本自动涨走了自动降。你不用提前买好峰值容量。峰谷自适应白天高峰 8 副本扛半夜 2 副本歇着资源不空转。但与真正的 Serverless/FaaS还有一道鸿沟——scale-to-zero缩容到零能力K8s HPA真 ServerlessKnative/KEDA/OpenFaaS扩容触发CPU/内存等指标HTTP 请求、消息队列、定时等事件驱动缩容下限minReplicas: 1至少留 1可缩到0无流量不占资源冷启动无Pod 常驻有请求到来才拉起需应对冷启延迟计费粒度按节点/Pod 常驻按实际调用次数/时长HPA 的minReplicas最低是 1即使设为 0K8s 1.16 也支持 scaledown 到 0 但需特殊配置且少有人用。要真正做到「无流量零成本」需要 KEDA基于事件的驱动伸缩支持缩到 0或 Knative Serving基于请求数原生 scale-to-zero。一句话总结本篇HPA 是 K8s 上的「半 Serverless」——它解决了弹性伸缩但还留着 1 个常驻 Pod真正的Serverless 把那最后 1 个也省了代价是冷启动延迟。选型时延迟敏感选 HPA 常驻成本极致选 KEDA/Knative。踩坑与排障重点坑 1HPA 一直unknown/ 不生效现象kubectl get hpa显示TARGETS unknown/50%副本不变。根因90% 概率没装 metrics-server或 Pod 没配resources.requests.cpu。HPA 算不出「利用率 实际/请求」就无法决策。排查kubectltoppods# 若报错说明 metrics-server 没好kubectl get hpa-oyaml# 看 status.conditions 的 message解决装好 metrics-server并确保 Deployment 里有requests.cpu。坑 2扩容快、缩容慢误以为「卡住」压测一停副本没立刻降——这是正常行为。HPA 默认缩容稳定窗口 5 分钟目的是防止抖动。别手贱去手动scale让控制器自己收。坑 3副本触顶 max 仍不够本篇 CPU 188% 直接触顶 8说明单 Pod 算力已是瓶颈。此时再怎么加副本也受限于节点总 CPU3×8vCPU。该上 Cluster Autoscaler 加节点或优化模型/换更强实例规格HPA 不是万能药。生产建议与成本价值容量规划的新范式有了 HPA你不再需要「按峰值买定」。按平均负载配minReplicas把maxReplicas交给突发。以本集群为例平时 2~3 副本约占 2~3 个 vCPU大促/峰值自动顶到 8 副本吃满约 8 个 vCPU峰值过后 5 分钟自动回落。成本价值假设峰值每天只占 2 小时固定 8 副本一年白烧 22 小时/天的算力HPA 模式下这部分直接省掉——对长期运行的在线服务弹性伸缩省下的钱相当可观。生产加固清单同时配 CPU 内存 可选QPS 多指标 HPAmaxReplicas要卡住防止指标异常导致无限扩容把节点打爆配合PodDisruptionBudget防止缩容/驱逐时一次性干掉太多副本真正想 scale-to-zero引入KEDA接 Kafka/HTTP/RabbitMQ 等事件源超大规模再上Cluster Autoscaler / Karpenter做节点级弹性。11 篇实战全景回顾 云计算学习心得写到这里整个《基于华为云 FlexusX 四节点集群的云计算全栈实操》系列就完整了。回头看这 11 篇是一条清晰的「由底向上」的云原生能力栈篇章主题核心收获01~03云主机 / 网络 / 安全组四节点 FlexusX 基盘VPC/安全组打通04~05块存储 / 对象存储EVS 持久化、OBS 非结构化存储06~07数据库 / 负载均衡RDS 托管库、ELB 流量入口08监控告警CES 指标 阈值告警闭环09K3s 多节点 K8s 集群容器编排四大能力LB/自愈/伸缩/滚动更新10云上 AI 推理服务模型容器化、containerd 镜像交付、纯 CPU 推理11HPA 弹性伸缩Serverless 式峰谷自适应本篇几条贯穿始终的学习心得云不是「远程电脑」而是「能力的拼装」。计算、存储、网络、数据库、负载均衡、监控、编排——每个都是独立可替换的乐高块。真正的云工程师价值在于「按需拼装」而非「单点深挖」。能声明式就不要命令式。从安全组规则到 K8s YAML声明终态让系统具备自愈与可复现。本文 HPA 一句话配置抵过人工 7×24 盯盘。成本意识要长在骨子里。弹性伸缩、按需付费不是口号——它是 HPA 把 8 副本在低谷自动缩回 2 的真实账单节省是纯 CPU 跑中小模型而不必上 GPU 的理性取舍。踩坑即资产。regestries.yaml 镜像加速、containerd 镜像交付、metrics-server 缺失……这些真实踩过的坑比任何文档都记得牢。云原生是终点也是起点。K8s HPA 已摸到 Serverless 的门槛而 KEDA/Knative/OpenFaaS、Service Mesh、GitOps 才是下一程。技术没有终点只有不断把「人工运维」变成「系统自治」的过程。小结本篇我们用 HPA 给情感分析服务装上了「弹性引擎」压测前三节点 CPU 0%~1%副本 3压测中CPU 冲到 188%约 1 分钟内副本3 → 8触顶 max跨 3 节点承接流量压测后默认 5 分钟稳定窗口内自动缩回min2。这就是 Serverless「按需弹性、峰谷自适应」理念在 K8s 上的真实体现。HPA 是「半 Serverless」——它解决了弹性但留着常驻副本要彻底 scale-to-zero请上 KEDA/Knative。至此从一台裸云主机到能自愈、能伸缩、能跑 AI 的云原生集群全栈实操闭环完成。感谢你一路同行。配置与实测引用HPA 实测../results/16_hpa_autoscale.txtAI 服务部署../k8s/ai-service.yamlAI 服务代码../ai-service/app.py集群基础../results/14_k8s_cluster.txt、../results/15_ai_inference.txt
