K8s 云原生架构实战：从单体到微服务的演进

为什么迁移到云原生？

**弹性伸缩**：流量高峰自动扩容，闲时缩容省钱

**故障隔离**：单个服务崩溃不影响全局

**发布效率**：从手动部署到 GitOps，发布从小时级降到分钟级

架构全景

┌─────────────────────────────────────────┐
│              Ingress (Nginx)            │
├─────────────────────────────────────────┤
│  API Gateway → 服务网格 (Istio)         │
├────────┬────────┬────────┬──────────────┤
│ 用户服务 │ 订单服务 │ 支付服务 │ 消息服务      │
├────────┴────────┴────────┴──────────────┤
│           持久层 (PostgreSQL + Redis)    │
└─────────────────────────────────────────┘

关键决策

1. Helm vs Kustomize

最终选了 Kustomize —— 轻量、无需额外学习 Helm 模板语法，K8s 1.14+ 原生支持。

2. 服务网格要不要上？

初期没上 Istio，用 K8s Service + Ingress 足够。服务网格在微服务数量超过 20 个时才体现价值。

3. 可观测性三板斧

**日志**：Loki + Promtail（比 ELK 轻量 10 倍）

**指标**：Prometheus + Grafana

**追踪**：Jaeger（分布式链路追踪）

踩坑

`imagePullPolicy: IfNotPresent` 没设，每次都拉镜像，慢得离谱

资源限制没设，一个服务吃光节点内存

Health Check 没配，滚动更新直接断流

---

完整 YAML 配置清单和部署脚本已整理，后续开源。

---

原文链接：https://wenyiblog.top/2026/06/k8s-cloud-native-migration/

首发于文艺技术笔记（wenyiblog.top），转载请注明出处。