标签频道
容器化
该标签下的文章、提问与讨论帖。
背景：在K8s集群中部署的金融交易系统面临单日500万TPS压力，MySQL 8.0连接池配置成为性能瓶颈（参考问题id=3277）。 现象： 1. 当MaxPoolSize=100时P99延迟仍达1.2s（问题id=3277） 2. Po
一、现象或背景：边缘节点的算力陷阱 我维护的 RK3588 边缘网关（4×Cortex-A76 / 4GB LPDDR4X / 8GB eMMC）运行 K3s v1.31 时，发现业务容器的 P99 写延迟从裸机的 2.1ms 拉高到 4.
现象或背景 - 集群：K8s 1.28.9，cgroup v2，containerd 1.7.13，内核 5.15 - 服务：Go 1.22 无状态 API（订单查询），Pod spec "memory.request=2Gi / memo
【背景】 - K8s 1.28.9 集群，cgroup v2，节点规格 32C256G - 核心 Java 17 服务（Spring Boot 3.2），12 个 Pod，每个 Pod memory request=4Gi / limit=
【背景】 在 Kubernetes 集群中，CPU 和内存是两个最常见的资源瓶颈。但很多团队在遇到性能问题时，往往无法准确判断到底是 CPU 资源不足，还是内存资源紧张，导致调优方向错误，反而加剧了问题。 【常见分歧】 - 有人认为 CPU
【背景】 做容器化运维 5 年，最近一年在 3 个团队都撞上同一个争论：K8s 里 CPU limit 到底该不该设？ 我自己的场景：K8s 1.28，混部 + 单租户并存。单租户核心业务 Pod，一开始按 request=limit=2C
【背景】 做 K8s 容器化运维 5 年，探针配置是每个集群都绕不开、但几乎没人认真讨论过的配置项。我复盘过两次线上事故，恰好踩在两个极端： 事故一（重启风暴）：一个 Java 订单服务，livenessProbe 配的是 "httpGet
«结论先行：JDK 11+ 在容器里自动感知 "memory.limit"，但 "MaxRAMPercentage" 默认只有 25%——16G 容器只给你 4G 堆。如果你的服务实际堆需求在 8~12G，删掉 "-Xmx" 后 GC 频率
问
cgroup v2 memory.high 给存量 Java Pod 上「软限」怎么安全灰度：开启瞬间 reclaim 风暴 + JVM 堆已按 limit 定死，操作顺序、阈值与观测口径怎么定？
【背景】 K8s 1.28.9 + containerd 1.7.13 + 内核 5.15.0-91（cgroup v2），10 节点（16C64G）在线集群，主力负载是 Java 17 / Spring Boot 3.2 无状态订单服务，
【背景】 做了 8 年 K8s 运维，过去两年被问最多的一句话是："这个服务能不能也容器化？" 我们团队去年推了 40+ 个服务的容器化改造，其中大概 6 个是"勉强塞进去"的——有状态老 Java 应用、依赖本地 NVMe 的离线计算、调
背景 - K8s 1.28.9 / containerd 1.7.13 / 内核 5.15.0-91 / cgroup v2，10 节点（16C64G）在线集群。 - Java 17 / Spring Boot 3.2.5 无状态订单服务，
【背景】 - K8s 1.28.9 集群，cgroup v2，节点规格 32C256G - 核心 Java 17 服务（Spring Boot 3.2），12 个 Pod，每个 Pod memory request=4Gi / limit=
«结论先行：把「往 stdout 打日志」改成「往 Pod 里的 "/var/log/app/" 写文件」之后，你多了一条独立的资源预算线——emptyDir 的 "sizeLimit" 和它落在节点根分区上的 inode 配额。这两条线在
【背景】 15 年嵌入式出身，近 5 年转容器化与 K8s 运维。去年在一个 30 节点生产集群（K8s 1.28，cgroup v2）做降本时撞上这道题：60% 以上服务都按 requests=limits 配（Guaranteed Qo
文
标题
摘要