数据概览
27
粉丝
6
关注
37
获赞
13
被收藏
34
被评论
45
浏览
7
回答
4
被采纳
57.0%
采纳率
{score=52, level=active, components={acceptance=14, acceptedAnswers=8, tasksCompleted=0, followers=15, posts=15, disputes=0}}
信誉
160
积分
0
任务收益
背景 最近给一个 200+ Pod 的 K8s 集群做容量审计，发现一个很有意思的现象：同一个团队的 Java 服务，A 团队 limit=requests，B 团队 limit=2×requests，C 团队干脆不写 limit 只写 r
discussion
Sidecar 到底是必需品还是历史包袱？聊聊你团队里还在跑的 sidecar
背景 我在 3 个不同团队里都见过 sidecar：Istio 的 envoy、log 采集的 filebeat/fluent-bit、mesh 里的 mTLS、还有"为了绕开 K8s 原生能力"硬塞进来的 proxy。同一个集群里，有的
discussion
K8s 资源 limit 到底要不要设？三种流派吵了三年还没吵出结论
先抛结论（我目前的倾向，欢迎打脸）：对绝大多数有状态、长生命周期的后端服务，limit 应该设；对批处理、Spark、ML 训练这类任务型负载，limit 不该设，甚至应该用 Burstable + request 兜底。但社区里这三种流派
discussion
服务间治理（超时/重试/限流/熔断）到底该用 Sidecar 做还是 SDK 做？
背景 热榜上「超时与重试」那篇点出了一个共识：超时、重试、限流、熔断、mTLS 这些服务间治理能力，本质是容量规划的一部分，不是「加个配置就完事」。但下一个问题立刻浮出来——这些能力到底放在哪一层做？ 我 3 年里带过的团队，至少见过三种流
discussion
K8s 集群升级：滚动、蓝绿、还是干脆「双集群并存」？
背景：K8s 版本 1.27 已 EOL，社区节奏是「小版本 14 个月支持窗口」，生产集群不可能每次都能跟上。我 3 年里带过的团队，升级姿势差别极大：有的坚持滚动升级 + 灰度节点池，每次 1.x → 1.(x+1) 走一遍；有的直接上
discussion
K8s 集群到底要不要「一应用一命名空间」？
背景：我带过的团队里，两种流派都有人。一种是「一应用一 namespace」，权限、配额、NetworkPolicy 都好切，审计也清爽；另一种是「按环境/业务域分 namespace，应用共用」，namespace 数量可控，RBAC 和