3. K8s 环境特点：Pod 生命周期、网络模型、存储卷对缓存的影响
在 Kubernetes 中部署缓存系统（如 Redis Cluster、Memcached、本地缓存 sidecar），必须理解 K8s 基础设施层对缓存一致性带来的三大扰动：Pod 生命周期不可预测、网络模型扁平但动态、存储卷语义与缓存持久化需求错配。本章逐一拆解这些影响，并给出治理对策。
3.1 Pod 生命周期：缓存节点的“生”与“死”
Pod 是 K8s 中最小的调度单元，其生命周期包含 Pending → Running → Succeeded/Failed 等阶段。对于有状态缓存组件，Pod 的重建、滚动更新、驱逐都会导致缓存拓扑突变。
| Pod 生命周期事件 | 对缓存的影响 | 一致性风险等级 |
|---|---|---|
| Pod 启动（Pending → Running） | 新节点加入集群，需同步全量或增量数据 | 中 |
| Pod 正常终止（PreStop + SIGTERM） | 优雅关闭，可触发数据迁移或持久化 | 低 |
| Pod 异常终止（OOMKilled / NodeLost） | 未完成 flush，丢失内存中未持久化的脏数据 | 高 |
| Pod 滚动更新（RollingUpdate） | 新旧 Pod 交替期间，分片归属短暂混乱 | 中～高 |
| Pod 被驱逐（Eviction / Preemption） | 强制删除，无优雅关闭机会 | 高 |
关键治理原则：缓存 Pod 必须配置
preStop 钩子，在 SIGTERM 到达前执行 SAVE（Redis）或 DUMP（Memcached）操作，并等待数据落盘后再退出。同时设置 terminationGracePeriodSeconds 为足够长的时间（如 60s），避免 Kubelet 强制杀死 Pod 导致数据丢失。
3.2 K8s 网络模型：扁平 IP 与动态 DNS 对缓存路由的影响
K8s 网络模型要求所有 Pod 之间可以直接通信（无需 NAT），每个 Pod 拥有独立的 IP 地址。但 Pod IP 是动态的：重启后 IP 会变化。这对缓存客户端的路由发现机制提出了挑战。
核心矛盾：缓存分片算法（如一致性哈希）通常基于 IP:Port 构建哈希环。Pod IP 变化后，哈希环需要重新平衡，导致大量缓存 miss 和迁移流量。
K8s 提供了两种服务发现机制来缓解此问题：
- Headless Service（无头服务）：DNS 返回所有 Pod IP 列表，客户端自行维护连接池。适合需要感知后端拓扑的缓存客户端（如 Redis Cluster 的
CLUSTER SLOTS）。 - ClusterIP Service：通过 VIP 负载均衡，客户端无需感知后端 IP 变化。但 VIP 会隐藏分片信息，不适合需要直接路由到特定分片的缓存协议。
下图展示了 Pod IP 变化如何影响一致性哈希环，以及 Headless Service 如何辅助客户端重新发现拓扑。
3.3 存储卷：持久化语义与缓存性能的权衡
K8s 存储卷（Volume）提供了多种持久化选项，但缓存系统对存储有特殊要求：低延迟、高 IOPS、支持 fsync。下表对比了常见存储卷类型与缓存持久化的适配性。
| 存储卷类型 | IOPS 典型范围 | fsync 延迟 | Pod 迁移后数据可用性 | 缓存场景推荐度 |
|---|---|---|---|---|
| emptyDir（内存） | 极高（内存速度） | 无（非持久化） | Pod 删除后数据丢失 | ❌ 仅用于临时缓存 |
| hostPath | 取决于宿主机磁盘 | 中等 | Pod 迁移到其他节点后不可用 | ⚠ 仅测试环境 |
| CSI 持久卷（SSD 后端） | 10k～100k | 低（1～5ms） | 支持跨节点挂载（ReadWriteOnce） | ✅ 生产推荐 |
| 分布式存储（Ceph RBD / NFS） | 1k～10k | 高（10～50ms） | 支持跨节点挂载 | ⚠ 仅用于 AOF 日志，不用于 RDB |
最佳实践：对于 Redis 持久化，推荐使用 本地 SSD 的 CSI 卷（如 AWS EBS gp3、GCP Persistent Disk SSD），并配置
fsync: everysec。避免将 RDB 或 AOF 文件放在 NFS 或 CephFS 上，因为网络延迟会严重拖慢写性能，并增加数据损坏风险。
3.4 综合影响：Pod 生命周期 + 网络 + 存储的联动效应
三个因素并非独立作用，而是相互叠加。例如：
- Pod 被驱逐 → 新 Pod 调度到不同节点 → IP 变化 + 存储卷重新挂载：缓存节点需要从持久卷恢复数据，同时客户端需要重新发现新 IP，期间所有请求都穿透到后端数据库。
- 滚动更新 → 旧 Pod 优雅关闭（preStop 执行 SAVE）→ 新 Pod 启动后加载 RDB：如果存储卷是 ReadWriteOnce，新 Pod 必须等待旧 Pod 完全释放卷挂载，导致启动延迟。
下图展示了 Pod 重建过程中，生命周期、网络、存储三者的时序依赖关系。
3.5 治理清单：K8s 环境缓存一致性要点
- Pod 生命周期：配置
preStop+terminationGracePeriodSeconds，确保异常终止时数据不丢失。 - 网络模型：使用 Headless Service 暴露缓存 Pod，客户端侧实现拓扑感知（如 Redis Cluster 的
CLUSTER SLOTS缓存）。 - 存储卷：优先选择本地 SSD CSI 卷，避免 NFS/CephFS 用于 RDB 持久化；配置
fsync: everysec平衡性能与安全。 - 滚动更新：设置
maxUnavailable: 1，配合 PDB 保证缓存集群不出现多数节点同时离线。 - 启动顺序：在 readinessProbe 中检查数据加载完成（如 Redis 的
INFO persistence确认 RDB 加载完毕），再开放流量。