Kubernetes 经典问题

Redis 有三大缓存问题

（先对齐认知）

缓存穿透
缓存击穿
缓存雪崩

👉 本质：高并发 + 依赖关系 + 瞬时放大效应

Kubernetes 有哪些“典型系统性问题”？

Kubernetes 的问题不在“功能不全”，而在规模化 + 自动化 + 分布式带来的放大效应。

一、Kubernetes 三大“基础性问题”

1️⃣ 控制平面瓶颈问题（API Server 风暴）

📌 现象

集群一切操作变慢
kubectl 卡顿
Pod 创建延迟巨大
HPA / Controller 失效

📌 根因

kube-apiserver 是唯一入口
watch/list 太多
控制器、Operator、CRD 过多
高频 List 而不是 Watch

📌 放大效应

一个组件异常 -> 触发大量重试 -> API Server 被打爆

📌 典型场景

大规模集群（>1000 Node）
CRD/Operator 滥用
自研控制器写得不规范

#### 📌 解决思路

启用 APIServer 缓存
合理拆分集群
优化控制器 Watch 行为
限制 QPS / Burst

📌 类比 Redis

👉 缓存雪崩（流量集中打到后端）

2️⃣ 调度与资源失真问题（资源看得见，用不到）

📌 现象

Node 还有资源，但 Pod Pending
资源碎片严重
HPA 扩容失败

📌 根因

requests / limits 配置不合理
Binpack 导致碎片
节点异构（CPU / NUMA / GPU）

📌 典型错误

resources:
  requests:
    cpu: "4"
    memory: "8Gi"

👉 实际只用 0.5C

📌 后果

资源利用率低
扩容成本暴涨

📌 解决思路

精准 requests
VPA / 推荐工具
Pod 拆分
合理 Node Pool

📌 类比 Redis

👉 缓存击穿（热点 key 资源被锁死）

3️⃣ 网络复杂性与排错困难（看不见的黑盒）

📌 现象

Pod 互相 ping 不通
Service 正常，访问失败
Node 间通信异常
NetworkPolicy 生效异常

📌 根因

CNI 复杂（iptables / ipvs / eBPF）
Overlay 网络
NAT 多层
多组件协同（kube-proxy + CNI）

📌 特点

问题不稳定
重启可能“好了”
难复现

📌 解决思路

网络可观测性
统一 CNI
使用 eBPF（Calico eBPF / Cilium）

📌 类比 Redis

👉 缓存穿透（请求路径不可控）

二、Kubernetes 三大“运维级问题”（生产常见）

4️⃣ etcd 风险（单点 & 放大器）

📌 现象

集群整体异常
所有操作失败

📌 根因

etcd 是唯一状态源
IOPS / 磁盘 / 延迟敏感
磁盘满直接写失败

📌 解决

SSD
定期 compaction
监控 db size
多副本

5️⃣ 滚动升级 ≠ 无感升级

📌 误区

Deployment rolling update = 业务无感

📌 真实情况

readiness 配置错误
连接被中断
负载突增

📌 解决

正确探针
preStop
maxUnavailable 控制

6️⃣ 自动化的“错误放大”

📌 现象

配置错误 -> 全集群传播
Operator bug -> 大规模事故

📌 本质

Kubernetes 是一个错误放大器

📌 解决

灰度
命名空间隔离
Admission 校验
GitOps

三、Kubernetes 的“隐性三大坑”（高级）

7️⃣ 可观测性缺失

指标多但不完整
日志分散
Trace 困难

👉 没有可观测性 = 盲飞

8️⃣ 多租户与权限复杂度

RBAC 难理解
Namespace 不是安全边界
网络、存储隔离不天然

9️⃣ 学习成本与认知错位

📌 常见误区：

“学会 kubectl = 会 Kubernetes”
“Pod 跑起来就算稳定”
“加副本就能抗流量”

四、总结

Redis 的问题是高并发缓存失效的瞬时冲击，

Kubernetes 的问题是自动化、规模化下的系统性放大效应：

控制面瓶颈、资源失真、网络复杂性、状态中心（etcd）风险。