背景
五一完成度 3/5, 有2天都在处理线上运维, 而且都和 k8s 有关, 正好上篇总结了操作部分的内容, 这篇总结下生产上运维的部分, 也给自己以后提个醒
round 1
用户反馈chat中聊天没有反馈 -> 业务同学发现自己的服务访问另外一个服务 404
整理服务链路
dns -> LB -> nginx(2台 ec2) -> k8s svc nodeport -> pod
最终定位到 nginx 配置: 需要添加 fallback 处理, 否则当出现 2025/05/06 04:00:08 [error] 214903#214903: *5482906 upstream prematurely closed connection while reading response header from upstream 时, nginx 会返回 404, 而非 5xx
upstream xxx_svc {
server prod_k8s:30012 weight=1; # k8s svc-nodeport
keepalive 20;
}
#路由转发
location / {
include /etc/nginx/proxy.conf;
proxy_set_header Connection "Upgrade";
proxy_pass http://xxx_svc; # nginx upstream
# 添加错误处理 -> 新增
proxy_intercept_errors on;
error_page 502 503 504 = @fallback;
}
# 添加 fallback 处理
location @fallback {
return 502;
}
location /test {
access_log off;
return 201;
}
error_page 404 /404.html;
location = /40x.html {
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
}
round2
继续聊 k8s 的 resource 配置
-
node的资源监控
node的资源监控 -
node下服务的资源情况
node下服务的资源情况
这里主要涉及到2个知识点
- cpu资源是可压缩的, mem资源是不可压缩的, 如果 OOM 了, 就GG了
- 实践中的 resource req 配置: 按照服务实际使用的资源来, 比如一个服务启动需要400m内存, 运行中内存在 400-1000m波动, 那么req最好给到 800, 不然很容易触发HPA扩容
- 实践中的 resource limit 配置: 生产要稳定优先, 通常只会给到
req*2, 如果服务有明显的突发资源使用(PS: 说明服务本身性能挺烂的), 测试可以给到req*4等较大值来降本, 不过超卖最大的问题是 mem limit 可能会超过 node mem 值,会把 node 打挂 - 实践中 HPA 的配置: 要看实际的资源情况, 但是也尽量不要超过
replicas*2, 更实际的情况是服务本身应该能接受一定范围的流量波动, 或者直白讲能线性增长
实践中 HPA 的配置
写在最后
- AI时代让大家获取知识的方式变得非常
短平快, 以前积累知识, 建设知识库的过程, 在AI时代迎来了巨变, 以前耗时耗力的点亮技能树, 在AI时代需要寻找新解法 - AI时代最大的成功或者说幻觉就是让人可以
从0到1, 伴随这个过程中的巨大满足感和愉悦感, 比如不会编程的人能编程做出点东西了, 很多局外人一下子变成了局内人, 先看自己是哪个身份(屁股在哪), 再看自己是在围城外还是内, 是想进去还是想出来, 想进去要清醒的认识到护城河在哪里, 想出来参考上一条 - 生产运维或者说SRE, 自有一套体系, 正常应该是过渡过去, 从原来的方式, 渐变式的过渡到新的方式, 过程中伴随着技能精进(说白了还是
唯手熟尔)以及效率提升(产生价值才能持续往好的方向前进), 如果是靠AI赋能遇山开山遇水架桥, 一定要铭记 稳定压倒一切
顺带一提, SRE中非常重要的一条: 监控告警
- 告警的及时性: 邮件 < IM < 短信 < 电话
- 告警有需要冗余: 使用告警组或者IM群, 保证事件有人能响应
