k3s服务自愈与弹性伸缩需构建探针、重启策略、hpa及karpenter四层闭环：liveness/readiness探针精准判定异常，配合restartpolicy实现pod级自愈；prestop与terminationgraceperiodseconds保障优雅上下线；hpa基于cpu/内存指标稳定扩缩容；karpenter则按pod资源请求秒级调度节点并支持 consolidation 与 spot fallback。
Linux 环境下部署 K3s，要让服务真正具备自愈能力和弹性伸缩能力，不能只靠默认配置。关键在于把探针、重启策略、HPA 和节点级伸缩机制串起来，形成闭环。下面从四个实操性强的环节展开。
服务自愈：靠探针 + 重启策略兜底
自愈不是“出错后自动恢复”，而是提前识别异常并触发可控动作。K3s 原生支持 liveness 和 readiness 探针，但必须配得准才有效。
- livenessProbe 决定 Pod 是否该被杀掉重建——比如应用卡死、线程阻塞时，/actuator/health/liveness 返回 500 就该重启
- readinessProbe 控制流量是否接入——Pod 启动后先检查数据库连接、缓存初始化等业务就绪条件，没通过就不进 Service endpoints
- 避免探针配置过激：initialDelaySeconds 至少留出 JVM 启动或 Spring Boot 初始化时间；failureThreshold 建议设为 3～5，防止偶发抖动误判
- 配合 restartPolicy: Always（Deployment 默认），Kubelet 才会在容器退出后拉起新实例
优雅上下线：避免重启时丢请求
服务滚动更新或节点维护时出现 503，往往不是扩容慢，而是流量切走得太急。K3s 虽轻量，但 lifecycle 和 terminationGracePeriodSeconds 配置缺一不可。
- preStop 阶段执行 sleep 或调用 shutdown API，给应用留出处理完长连接、刷盘、释放锁的时间
- terminationGracePeriodSeconds 应 ≥ preStop + 应用清理耗时（建议设为 60～120 秒）
- 确保 Service 的 topologyMode 设为 "Auto" 或显式配置 endpointSlices，避免 kube-proxy 缓存延迟导致旧 Pod 还收流量
- 搭配 readinessProbe 的 periodSeconds（如 5 秒）和 failureThreshold（如 3 次），可控制“不健康”状态传播速度
Pod 级弹性伸缩：HPA 实战调优要点
K3s 自带 Metrics Server，但边缘环境资源紧张，HPA 容易“反应迟钝”或“反复震荡”。重点不在加副本，而在指标可信、响应稳定。
- 优先使用 CPU 利用率（averageUtilization=70%）作为主指标，内存利用率作辅助（80%），避免单指标突刺误扩
- behavior.scaleDown.stabilizationWindowSeconds 设为 300 秒以上，给系统留出观察窗口，防止负载短暂回落就缩容
- scaleDown.policies 中限制每分钟最多缩 10%，避免突发低峰直接干到 minReplicas 导致雪崩
- 若业务有明显波峰波谷（如定时任务、日结批处理），可结合 CronHPA 或 KEDA 做预伸缩，HPA 负责微调
节点级弹性伸缩：Karpenter 替代 Cluster Autoscaler
K3s 单节点常见，但生产多节点集群必须考虑节点层弹性。Cluster Autoscaler 在 K3s 上适配差、启动慢；Karpenter 更匹配轻量场景。
- 安装前确认 K3s 版本 ≥ v1.26，且云厂商权限已配置（如 AWS IAM Role、阿里云 RAM Policy）
- Karpenter 不依赖节点组，能根据 Pending Pod 的 requests 字段（如 cpu: 1, memory: 2Gi）实时选型、秒级拉起最匹配的节点
- 启用 consolidation 后，Karpenter 会主动驱逐低负载 Pod、腾空节点并销毁，节省成本
- 搭配 Spot 实例策略时，Karpenter 可自动 fallback 到按量实例，保障 SLA 不中断
