标签频道
K8s
该标签下的文章、提问与讨论帖。
现象或背景 某次生产环境Pod频繁崩溃，导致服务不可用，影响用户量达到5万，单次故障持续2小时。监控数据显示，Pod在崩溃前CPU使用率长期处于95%以上，内存使用率接近阈值。通过日志分析发现，崩溃前存在大量OOM Killer日志，且系统
现象或背景 我们一条 24 节点（16C64G，Kubernetes 1.28.9 + containerd 1.7.13，cgroup v2）的核心交易集群，Java 17 + Spring Boot 3.1，Pod 副本数 12，QPS
【背景】 Kubernetes 在资源管理中引入了 kube-reserved 和 system-reserved 的机制，用来确保节点上系统和 kubelet 的运行不会被驱逐。但在实际操作中，如何精准计算业务 Pod 的资源请求和限制，
【背景】 在 Kubernetes 中，kube-reserved 和 system-reserved 是用于保障节点上系统组件和 kubelet 本身正常运行的资源预留机制。然而，在实际生产中，我们经常遇到业务 Pod 被 kube-re
«结论先行："-XX:MaxDirectMemorySize" 不设置时，JVM 默认把它等同于 "-Xmx"，但 Netty 4.1 的 PooledByteBufAllocator 走的是 "sun.nio.ch.DirectByteB
背景 在生产 K8s 集群里，Pod 启动慢是最常见的运维痛点之一。虽然排查路径散落在各团队的经验里，但缺乏一份系统化的排查手册和可复现的诊断脚本，导致同类问题反复花 1–2 小时才能定位到根因。 现象 1. 镜像拉取慢：大镜像（>2GB）
先给结论：容器内存故障分两种——「OOMKilled」是响的那种，「内存消失」是不响的那种。不响的更常见也更恶心：监控全绿、dmesg 干净、只有延迟在涨。八成「内存消失」的根因是「你看的那本账，和内核杀你时用的那本账，不是同一本」。本文给
结论先行 CPU 不饱和（55%~65%）+ 下游 P99 < 80ms + ZGC pause < 2ms + HikariCP pending ≈ 0，但本服务 P99 从 120ms 间歇性飙到 900ms——大概率是 carrier
结论先行 "CompletableFuture.supplyAsync(supplier)" 不传 executor 时默认走 "ForkJoinPool.commonPool"，而 commonPool 默认 worker 数 = "Ru
背景 我负责一套约 120 个微服务（Java/Go 混合，K8s 1.27 自建集群）的安全加固。过去半年把一批"长期高权限账号"往最小权限收敛：cluster-admin SA 拆成 per-service 的窄 RoleBinding
文
标题
摘要