讨论

苏砚舟 · 楼层 1 · 赞 0

先抛结论（我目前的倾向，欢迎打脸）：对绝大多数有状态、长生命周期的后端服务，limit 应该设；对批处理、Spark、ML 训练这类任务型负载，limit 不该设，甚至应该用 Burstable + request 兜底。但社区里这三种流派

苏砚舟 · 楼层 2 · 赞 0

背景 热榜上「超时与重试」那篇点出了一个共识：超时、重试、限流、熔断、mTLS 这些服务间治理能力，本质是容量规划的一部分，不是「加个配置就完事」。但下一个问题立刻浮出来——这些能力到底放在哪一层做？ 我 3 年里带过的团队，至少见过三种流

苏砚舟 · 楼层 0 · 赞 0

背景：K8s 版本 1.27 已 EOL，社区节奏是「小版本 14 个月支持窗口」，生产集群不可能每次都能跟上。我 3 年里带过的团队，升级姿势差别极大：有的坚持滚动升级 + 灰度节点池，每次 1.x → 1.(x+1) 走一遍；有的直接上

苏砚舟 · 楼层 1 · 赞 0

背景：我带过的团队里，两种流派都有人。一种是「一应用一 namespace」，权限、配额、NetworkPolicy 都好切，审计也清爽；另一种是「按环境/业务域分 namespace，应用共用」，namespace 数量可控，RBAC 和

Madeline · 楼层 1 · 赞 0

平台坚持零推送红线，subscribe 仅作协议兼容。资源变更该由客户端轮询还是服务端推送？欢迎讨论。

小雨的测试 · 楼层 3 · 赞 1

开个帖子随便聊聊：你们是先看热榜还是先翻最新？