https://ruijingan.pages.dev/tags/%E8%BF%90%E7%BB%B4/ Recent content in 运维 on 山行小记 Hugo zh-cn @2025 Thu, 16 Nov 2023 00:00:00 +0000 https://ruijingan.pages.dev/posts/2023/k8s-first-lessons/ Thu, 16 Nov 2023 00:00:00 +0000 https://ruijingan.pages.dev/posts/2023/k8s-first-lessons/ <p>今年公司的基础设施从自建机房迁到了云上的 K8s，运维的活儿有相当一部分落到我们组头上。作为一个写了十年代码没怎么管过机器的人，这半年补了很多课，挑几个印象深的记下来。</p> <p><strong>资源 requests/limits 别乱填。</strong> 上线前凭感觉给服务配了 limits：内存 4G、CPU 2 核。结果高峰期 CPU 被 throttle，接口 P99 从 80ms 涨到 400ms，监控上还看不到任何异常——throttle 不报错，就是慢。后来用 Grafana 盯着 CPU throttling 指标重新校准了所有服务的配额。教训：<strong>limits 配小了比不配还危险，因为故障形态是&quot;变慢&quot;而不是&quot;报错&quot;</strong>，最难排查。</p> <p><strong>滚动更新的 maxSurge 和 readiness 探针是一对。</strong> 我们有个服务启动时要预热本地缓存，要 40 秒。没配 readiness 的时候，新 pod 起来就被接入流量，一堆请求打到没预热完的实例上。配上探针之后，又发现 terminationGracePeriodSeconds 太短，滚动更新时旧 pod 还没处理完存量请求就被杀了。这两个参数要配对一起看，单看哪个都不对。</p> <p><strong>HPA 不能只看 CPU。</strong> 推送网关那种长连接服务，CPU 很低但连接数高，按 CPU 扩缩容等于没有。最后接了自定义指标（连接数）做 HPA，才算了结。</p> <p><strong>最花时间的一次事故</strong>：某个周四凌晨所有 pod 同时重启。查下来是节点镜像_gc 策略配置问题，kubelet 把正在用的镜像清了，拉镜像又赶上镜像仓库限流。运维同学说这叫&quot;基础组件的雪崩&quot;，我理解了为什么老运维对&quot;全部 egg 放一个篮子&quot;这么警惕。</p> <p>总的来说，K8s 把&quot;部署&quot;这个动作的门槛降低了，但把&quot;理解系统为什么这样运行&quot;的门槛提高了。前者是工具问题，后者是知识问题，知识没法速成。我的学习路径就一条：出了事故就去把对应的原理文档读了，比先读完文档再上手记得牢。</p>