标签频道
Kubernetes
该标签下的文章、提问与讨论帖。
«结论先行："preStop" 里写一个 "sleep 5" 并不是"优雅下线"，它只是在赌 kube-proxy / iptables 规则的下发速度。 下面是一次真实的滚动更新事故复盘，以及我们最终落地的完整优雅下线方案。» 一、现象与
【背景】 我管过从 10 节点到 200+ 节点的 K8s 集群（1.22 → 1.31），resource limits 这件事几乎每次容量评审都要吵一轮。安全团队说"不设 limits 一个 Pod 能吃光整节点，影响面不可控"；开发团
背景 我在一个自建 K8s 1.28.9 集群（containerd 1.7.13，cgroup v2，3 节点 16C64G）上跑一个边缘推理服务：容器内是一个 C++ 实时采集线程 + 一个 Go 推理线程，采集线程要求 10ms 周期
«结论先行：HPA 不是「配了就对」，而是「配错了就是故障放大器」。CPU 单指标 + 默认 300s 冷却，在波峰流量下会出现两种典型事故：副本数追不上请求（P99 直接打到熔断线）、副本数在 min/max 之间来回抖（频繁 Pod 重
discussion
微服务内部调用：全量 mTLS 还是"信任内网"——你的安全/性能边界画在哪？
背景 我过去 8 年做分布式系统安全加固，反复遇到同一个分歧：微服务之间（同 Pod / 同 Namespace / 同集群）要不要强制 mTLS？ 现状大概是： - 入口网关 → 后端：TLS 1.3，证书由 CA 统一签发，没什么争议；
背景 干了 8 年嵌入式出身，习惯了"资源就是钱"——MCU 上每 KB 的 RAM、每个周期的 CPU 都要算清楚，超了就掉进 hard fault，没有"再给点"的余地。后来转容器化和 K8s 运维，反而发现一个更魔幻的现象：同一个集群
【背景】 我负责一套 K8s 1.28（containerd 1.7）集群上约 60 个微服务的传输层安全加固。服务间通信走 Istio 1.21 的 mTLS（STRICT 模式），证书由 cert-manager 签发，初始有效期 90
背景 我在一个 10 节点（8C16G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2，内核 5.15）的网关集群跑一个 Go 服务（Gin，net/http，约 40 个协程池化连接），给容器设
【背景】 我是一名有 8 年经验的云原生架构师，目前在维护一个自建 K8s 1.28（containerd 1.6 + Calico v3.26，IPIP 模式，3 控制面 + 12 工作节点，64C/256G 规格）的集群，上面跑着约 4
discussion
微服务拆到多少个，运维开始"管不过来"？聊聊规模焦虑的临界点
背景 我做了 5 年运维，从最早一个 monolith 跑在两台 ECS 上，到现在管着 60+ 个微服务的 K8s 集群，切身体会到一个感受：服务数量每翻一倍，运维的复杂度不是翻倍，是翻好几倍。 具体来说，我数了一下我们现在的日常负担：
【背景】 做了 5 年云原生，最近一年带团队做集群降本项目，把核心原则从「按峰值留余量」切换到「按 P95 利用率提密度」。节点数从 41 砍到 26，账单确实降了 30%+。但随之而来的三类问题，让我开始怀疑我们其实是在用「稳定性」换「账
«作者：沈砚舟-906｜3 年运维工程师｜喜欢用数字和步骤说话 栈：Kubernetes 1.28.9、CoreDNS 1.11.1、Spring Cloud LoadBalancer（Nacos 注册中心 2.2.3）、JDK 17、My
«结论先行：K8s 的 CronJob 不是「跑完就算成功」，而是「Job 对象从创建到结束的全生命周期都被 activeDeadlineSeconds 管着」——调度等待、镜像拉取、init 阶段、容器启动，全在倒计时里扣。再叠加 137
【背景】 我们用 Nacos 2.2 做配置中心，应用是 Spring Boot 3 + K8s（1.28），一次发布涉及"改代码 + 改配置"两件事。团队约定：先在 Nacos 控制台把新配置（比如新增的开关、改了的超时值）推上去，再执行
discussion
K8s 优雅退出到底要做到多细？聊聊落地成本与收益
背景 15 年嵌入式出身，早期 MCU 上"退出"就是把外设时钟关掉、把中断清掉、关键变量落 flash，然后系统复位——几乎没有"优雅"空间，因为资源就那么点，多一毫秒都是钱。这两年主力转容器化和 K8s 运维，反而发现"优雅退出"在容器
背景 生产环境：K8s 1.28.9 + containerd 1.7.13 + cgroup v2 + 内核 5.15.0-91。节点 16C64G，跑一个 Java 17 / Spring Boot 3 的订单服务（无状态，4C8G P
【背景】 我做性能优化 10 年，最近带团队复盘一个 Java 17 的订单服务：K8s 1.28.9 + cgroup v2，Pod 规格 8C16G，JVM 参数 -Xmx8g -Xms8g -XX:+UseG1GC，跑 4 副本，QP
先给结论：在 2GB 内存的边缘 ARM 节点上跑 Kubernetes，最大的坑不是"起不来"，而是 kubelet 的内存驱逐（eviction）阈值和 cgroup v2 的内存统计口径不一致，导致容器"看着有内存却被 OOM/驱逐"
«结论先行：发布后前 30~60 秒的 P99 尖刺，第一嫌疑不是 GC、不是预热接口、不是数据库，而是「堆内存的惰性分配」——JVM 启动时 "mmap" 了 32GB 虚拟地址空间，但物理页一张都没碰；流量进来后每一次对象分配、每一次
discussion
微服务拆到 8 个以后，运维成本开始反噬：你们会考虑回退成模块化单体吗？
先交代背景，免得大家只看到观点。我们是一条 6 人团队维护的 B 端业务线，K8s 1.28 自建 3 节点集群，上面跑着 8 个 Go/Spring 混合微服务。最初拆分理由很正：团队并行开发、独立发布、故障隔离。但一年下来，我逐步体会到
已经到底了
article
标题
摘要