做过电商大促运维的人都知道,大促当晚最怕的不是流量来了,而是流量来了你不知道瓶颈在哪。2024 年双 11 是我接手这家公司交易链路 SRE 的第三个年头,前两次大促我们都"扛过去了",但扛得很狼狈——2022 年双 11 零点抢购,支付网关 CPU 飙到 95%,靠紧急扩容 200 个 Pod 才稳住;2023 年因为缓存集群打满,商品详情页大面积超时,事后排查发现是某个秒杀活动的热点 Key

2024年我在一家电商公司做 K8s 集群迁移，原来的日志方案是 ELK—— 3 台 16C64G 的 Elasticsearch 节点，每月存储成本 8000+。日志量大时 ES 频繁 OOM，Kibana 查询慢得让人想砸键盘。业务方天天投诉"日志查不出来"。后来我们切到 Loki + Promtail，同样的日志量，存储成本降到原来的 1/5，查询速度反而更快。这篇文章就是把那次迁移的完整经

手写一堆YAML维护很痛苦，Helm 就是 Kubernetes 的包管理器。本文从零开发一个完整 Helm Chart，掌握后可以直接用在生产。

Git 是唯一事实来源，所有变更都通过 Git PR 触发。本文实现一套完整的 GitOps 流水线。

刚上手 K8s 的同学,大多是从开始的。命令一敲,Pod 就起来了,看起来像魔法。但生产环境从来不给你"魔法"的余地——apiserver 响应变慢、etcd 磁盘打满、scheduler 卡住、kubelet 报 “PLEG is not healthy”,这些故障没有一件能用解决。我这几年带过不少从传统运维转 K8s 的兄弟,发现一个共同问题:大家能把组件名字背下来,但说不清"一个 Pod 从

K8s 网络是新手最容易"知其然不知其所以然"的领域。大家都会装个 Flannel 跑起来,Pod 能互通就完事。但一旦上生产,问题就来了:为什么 Pod 间延迟比物理机高?为什么跨节点抓包抓不到?为什么 NetworkPolicy 写了不生效?为什么节点上 iptables 规则几千条、kube-proxy CPU 占满?这些问题不搞懂 CNI 原理,排查就只能瞎猜。

K8s 存储是很多人又爱又恨的部分。爱的是 PVC 一行声明,卷就出来了,看起来简单;恨的是生产上一出事就是大事——PVC 卡在 Pending、Pod 起不来、扩容失败、快照恢复数据丢失、节点磁盘满整个节点雪崩。我见过太多团队把有状态服务(MySQL、Kafka、ES)贸然上 K8s,出事才发现存储选型完全不对,数据差点没了。存储的本质问题是:K8s 的存储抽象(PV/PVC)是声明式的,但底层

Ansible 是基于 SSH 的自动化运维工具，无需在目标机器安装客户端。特性说明无 Agent通过 SSH 管理目标机器幂等性多次执行结果一致YAML 语法易读易写模块化丰富的内置模块。

Prometheus 是云原生监控的事实标准。本文从安装到查询，完整走一遍 Prometheus 的核心链路。