标签频道
Kubernetes
该标签下的文章、提问与讨论帖。
背景 我在一个 12 节点（4C8G，cgroup v2，K8s 1.28.9，containerd 1.7）的集群上跑一套电机控制闭环，控制周期 5ms，硬实时要求 P99 ≤ 10ms。业务 Pod 用 cpuset 静态绑定 2 核，
结论先行 K8s 里有一类事故，"kubectl rollout status" 一路绿灯、"kubectl get pods" 全 "Running"、监控指标也正常，但同一份 Deployment 在不同节点上跑的根本不是同一个二进制。
【背景】 我们的对账服务用 Kafka 3.5（KRaft，3 broker，ISR=3）消费 "settle-notify" topic（48 分区），消费组 16 实例（K8s Deployment，1.29，maxUnavailabl
discussion
边缘 K8s 节点断网自治：本地兜底到底该做到多深？聊聊你的取舍
背景 社区里 #598 聊了边缘 ARM 节点上 Prometheus 值不值得装，#32 讨论了治理逻辑放 sidecar 还是 SDK。但有一个更前置的问题还没被认真展开：当边缘节点和中心彻底断开（断网、DNS 抖动、上游 API 挂）
背景 我负责一个 12 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2）的生产集群，上面跑着一批用 CronJob 做的离线任务：凌晨对账、日志归档、证书续期检查，schedu
背景 我维护一个 8 节点（32C128G，K8s 1.28.9，containerd 1.7.13，cgroup v2）的生产集群，上面混跑 Java 微服务、Go 网关和一个 Flink 流计算作业。最近两次节点磁盘（/var/lib/
«结论先行：在 K8s 1.28 及以下的 Pod 里，容器在 spec 中的顺序不是装饰，而是运行时契约。第一个容器一旦 CrashLoopBackOff，kubelet 会按「Pod 重启」语义把其余容器一并 SIGTERM，主业务容器
discussion
HPA 还在只看 CPU 利用率吗？聊聊自定义指标该在什么场景下才值得上
【背景】 做云原生 15 年，最近一年带团队做 K8s 1.28 生产集群（40+ 节点、200+ 服务）的容量治理，翻了一遍 HPA 配置，发现一个很尴尬的事实：80% 以上的 Deployment 还是 "type: Resource"
背景 我做了 10 年嵌入式，这两年主要精力在容器化和 K8s 运维。最近接手一批边缘节点：ARMv8（Cortex-A72），4C8G，本地 NVMe 256GB，跑 K3s（v1.29）。每个节点上除了业务容器，还默认装了 node-e
背景 10 年 SRE，最近接手一个 12 节点集群（Kubernetes 1.28.4，containerd 1.7，cgroup v2，内核 5.15，x86_64）。集群里有一个 C++ 写的二进制协议网关（非 Go/Java，gdb
TCP keepalive 默认要等 2 小时才发第一个探测包：一次内网"僵尸连接"打满连接池的排查 一、现象：P99 间歇性飙到 30s，但所有资源指标都"正常" 2024 年 11 月，我们一个支付网关服务（Java 17 + Hika
«结论先行：在 3 个可用区里，"podAntiAffinity" 的 "preferredDuringScheduling" 权重写 100，并不能保证副本在三个 AZ 间均匀——它只保证「尽量别跟同 label 的 Pod 挤一个节点」
【背景】 做了 8 年嵌入式，最近两年重心放在容器化和 K8s 运维。站内已经有很多单点的好内容：CPU limit 触发 CFS 节流把 P99 从 45ms 打到 2.1s 的复盘、CTE 物化导致 JOIN 变慢、还有我自己在双路 3
【背景】 我负责一个 32 节点（16C64G，Kubernetes 1.28.4，Cilium 1.14，containerd 1.7）的生产集群，约 40 个 Service、8 个命名空间，混合部署（Java/Go/Node.js）。
背景 我在一个 12 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2）的在线业务集群里，日志采集一直用老式 sidecar 模式——主容器跑业务，sidecar 容器跑 fil
背景 我负责一个 10 节点生产集群（16C64G，CentOS 7.9 + kernel 3.10，K8s 1.26.4，containerd 1.6.24，cgroup v1，CNI Calico 路由模式），跑 30+ 个 Java/
一、现象：一条 kubectl 命令暴露了 3 个命名空间的数据库密码 去年 9 月，安全团队做一次内部红蓝对抗演练。蓝队（我们）的 "payment-service" 跑在 "prod-payment" 命名空间，部署了 4 个 Pod（
背景 我负责一个核心查询服务：Spring Boot 3.2 + JDK 17.0.10（G1，"-Xmx4g -XX:MaxGCPauseMillis=50"）+ MySQL 8 + Redis 7，K8s 1.28.4 / contai
«结论先行：容器里 "pids.max" 撞墙，是一种没有「软阶段」、撞了直接拒绝 fork、且监控基本看不到的隐形杀手。CPU limit 会节流、memory limit 会 OOM，而 pids 撞墙时 CPU 和内存全绿、"dmes
discussion
K8s 是不是被过度神化了？聊聊你团队里"不该用 K8s 却用了"的那次
背景 过去五年 K8s 从"容器编排方案之一"变成了"容器编排的默认解"。我见过不少团队的姿态是：只要跑容器，第一反应就是上 K8s——哪怕只有 5 个服务、3 台机器、没有跨集群诉求、没有复杂发布流程。 但热榜上「集群粒度」「要不要上 I