标签频道
云原生
该标签下的文章、提问与讨论帖。
K8s CronJob 自动刷新 InnoDB 统计信息：零代码侵入的运维方案与量化判据 一、现象或背景 在云原生架构下，MySQL 8.0 的 InnoDB 统计信息自动刷新机制（"innodb_stats_auto_recalc"）常导
Kubernetes liveness探针实践：浅探活、深探活与中间派的抉择 背景：从嵌入式看门狗到容器探针 做了10年嵌入式，早期写MCU固件时"健康"这件事是被看门狗强制定义的：主循环喂狗成功=活着，喂不上=复位。边界极其干净——只看"
现象或背景 我们一条 24 节点（16C64G，Kubernetes 1.28.9 + containerd 1.7.13，cgroup v2）的核心交易集群，Java 17 + Spring Boot 3.1，Pod 副本数 12，QPS
背景 我在一个 12 节点（16C64G，K8s 1.28.9，containerd 1.7.13，cgroup v2，内核 5.15.0-112，Calico 路由模式）的生产集群里混跑 Java 17 微服务（约 18 个 Pod，re
背景 我在一个 12 节点（16C64G，K8s 1.28.9，containerd 1.7.13，cgroup v2，内核 5.15.0-112，Calico 路由模式）的生产集群里混跑 Java 17 微服务（约 18 个 Pod，re
【背景】 我负责一个中小规模的云原生服务团队，服务数量在 30~60 个之间，运行在 Kubernetes 集群中，混合了多种语言栈（Go、Python、Java）。团队在架构评审中反复被一个问题卡住：是否应该引入服务网格（如 Istio
一、现象：凌晨 03:12，一台 32G 节点 40 秒内 evict 了 3 个 Pod，死的不是"最重"的那个 上个月凌晨 03:00，我们电商集群一台 8C32G 的 worker 节点（K8s 1.28.9，containerd 1
【背景】 我负责一个中小规模的云原生服务团队，服务数量在 30~60 个之间，运行在 Kubernetes 集群中，混合了多种语言栈（Go、Python、Java）。团队在架构评审中反复被一个问题卡住：是否应该引入服务网格（如 Istio
«结论先行："PodDisruptionBudget"（PDB）只约束「自愿驱逐」这条路径（"kubectl drain"、集群升级、cordon、云厂商维护事件），对「非自愿驱逐」（节点失联、内核 panic、硬件故障、Spot 实例回收
【背景】 做了 8 年 K8s 运维，今年带团队把一套 30+ 服务的线上平台从「单集群 18 节点」迁到了「同城双集群 + 跨域只读副本」，跑了半年，复盘下来一句话：多集群解决的是容量和故障域问题，但它把 80% 的复杂度从「节点层」转移
«结论先行：多数团队以为的"超卖比例"（allocatable ÷ Σrequests）和"真实超卖比例"（allocatable ÷ 实际用量 P99）能差 2 倍以上——前者常常只有 1.1x 看着像"不敢加服务"，后者其实是 2x 甚
背景 我维护一套 K8s 集群上的 Java + Go 混合微服务，CPU 是 Burstable（requests=2，limits=4）为主。今年两次 P99 抖动复盘，根因都指向 CFS 节流：一个批处理型服务在 limit 边缘跑，
【背景】 我在云原生这边做了 3 年，带过的服务规模从 20 个到 100+ 微服务不等，Java/Go/Python 混布在 K8s 上。服务网格（Istio / Linkerd / Cilium Mesh / Istio ambient
【背景】 做了 5 年云原生，前三年主力推的是 Istio 服务网格，最近一年在几个新项目里开始往「应用内 SDK（Envoy Go SDK / gRPC interceptors / otel SDK）+ 少量 CNI（Cilium）+
背景 我维护一个 20 节点（16C64G，K8s 1.28.9，containerd 1.7.13，cgroup v2）生产集群，其中 60% 节点是 Spot 抢占式实例（阿里云，按量+抢占混合池），核心服务是 Java 17 无状态
背景 我维护一套 30+ 微服务的 K8s 1.28 生产集群（自建，cgroup v2，节点 16C64G）。最近做容量复盘时发现一个长期被"默认化"却从没被认真讨论过的选择：绝大多数服务的 container 都同时设了 request
背景 在 K8s 集群里，"requests" / "limits" 怎么填，直接决定了调度器的 bin-packing 效率和 Pod 运行时的 QoS 等级。我见过太多团队在这件事上"一刀切"： - 有些团队（尤其金融、电商中台）直接
背景 社区里几乎所有「高可用」方案都默认服务是无状态的：随便杀、随便迁、随便扩缩，K8s 调度器才能放心工作。但实际跑起来，你会发现「无状态」的服务其实带着一大坨隐式状态： - JVM 侧：JIT 编译缓存、类加载完成度——冷启动头 30
背景 我管过一个 200+ 节点的 K8s 集群（1.28，EKS），去年做成本治理，把无状态服务的 NodePool 改成 70% spot + 30% on-demand 混部，配合 Karpenter 做节点替换。账面上每月省了约 4
背景 我管过一个 600+ Pod 的 K8s 1.28 集群（云厂商 + 自建混合），服务间通信走 mTLS + 全链路 trace，方案是 istio 1.21 + Envoy sidecar 注入。去年 Q4 做容量审计时发现一个扎心
已经到底了
文
标题
摘要