K8s 核心接口：CNI、CSI、CRI、LB 一篇讲透

K8s 之所以能成为云原生的「操作系统」，靠的就是这套可插拔的接口设计。搞懂 CNI、CSI、CRI、LB，你对 K8s 架构的理解会上一个台阶。

一、K8s 的四大核心接口是什么

CNI、CSI、CRI 是 Kubernetes 的三大核心扩展接口，分别定义了网络、存储、运行时的标准。它们的设计哲学一致：K8s 只定义接口，具体实现交给插件。

LB（Load Balancer）则不同——它不是 K8s 的内部接口，而是 Service 的一种对外暴露方式，通常依赖云厂商的负载均衡器或软件实现（如 MetalLB）。

1. 为什么需要这些接口

K8s 作为一个容器编排平台，面临三个必须解决的底层问题：

如果 K8s 把这些能力硬编码进内核，就会跟特定实现绑死。通过定义标准接口，任何符合规范的插件都能接入——这就是「可插拔架构」的核心价值。

┌─────────────────────────────────────────────────────┐
│ Kubernetes API │
├──────────────┬──────────────┬────────────────────────┤
│ CNI │ CSI │ CRI │
│ (网络接口) │ (存储接口) │ (运行时接口) │
├──────────────┼──────────────┼────────────────────────┤
│ Calico │ Ceph CSI │ containerd │
│ Flannel │ NFS CSI │ CRI-O │
│ Cilium │ 云盘 CSI │ Docker (已废弃) │
└──────────────┴──────────────┴────────────────────────┘

二、CNI — 容器网络接口

1. 什么是 CNI

CNI（Container Network Interface）定义的是容器网络的标准。它的核心职责：

• 为每个 Pod 分配独立的 IP 地址
• 让同一集群内任意两个 Pod 能够直接通信（无需 NAT）
• 让节点上的 kubelet 能够调用 CNI 插件完成网络配置

没有 CNI，Pod 就只能跟同一节点上的 Pod 通信，跨节点完全不通。

2. 主流 CNI 插件对比

各插件一句话总结：

• Flannel：最简单、最轻量，只做网络连通，啥高级功能都没有
• Calico：纯三层路由 + BGP，性能强，NetworkPolicy 强，通用云原生首选
• Cilium：eBPF 加持，性能天花板最高，适合对网络性能和可观测性有极致要求的场景
• Kube-OVN：企业级 SDN 架构，VPC 多租户、Underlay 强、功能最全，灵雀云自家核心 CNI

3. 选型建议

大多数中小团队的生产集群，Calico 是最稳妥的选择——功能完备、社区活跃、排坑资料多。

三、CSI — 容器存储接口

1. 什么是 CSI

CSI（Container Storage Interface）是 K8s 与外部存储系统之间的标准接口。容器本身是无状态的——Pod 一删，数据就没了。CSI 让 Pod 能以标准化的方式挂载外部持久化存储，保障数据不丢失。

通过 CSI 接口对接第三方存储插件（如 NFS、CephFS、各云厂商云盘），实现存储卷的创建、挂载、卸载、删除。典型场景：数据库 Pod 的数据留存、日志持久化、共享文件存储。

2. 存储流程

一条完整的存储生命周期，涉及四个步骤：

2.1 用户创建 PVC

用户声明存储需求：大小（如 10Gi）、访问模式（ReadWriteOnce / ReadWriteMany）、指定 StorageClass。

2.2 PV Controller 创建 PV 并绑定

PV Controller 通过 StorageClass 调用 CSI 插件创建实际的存储资源（PV），并完成 PVC 与 PV 的绑定。

2.3 kubelet 挂载存储

Pod 被调度后，kubelet 调用 CSI 插件，将存储卷挂载到容器的指定路径。

2.4 Pod 删除时卸载

Pod 删除时，CSI 插件依次执行存储卸载、解绑操作。根据 PV 的回收策略（Retain / Delete / Recycle），决定底层存储是保留还是删除。

用户创建 PVC → PV Controller 调用 CSI 创建 PV → kubelet 挂载到 Pod → Pod 删除时 CSI 卸载

3. PV / PVC / StorageClass 详解

这是 K8s 存储体系里最容易搞混的三个概念，用一句话说清楚：

三种模式：

• 静态供给：管理员手动创建 PV，用户创建 PVC 后自动绑定匹配的 PV
• 动态供给：用户只创建 PVC + StorageClass，系统自动创建 PV 并绑定——这是大规模生产环境的标准做法
• StorageClass 的关键参数：provisioner（用哪个 CSI 插件）、reclaimPolicy（删除策略）、parameters（存储类型、IOPS 等）

# 一个典型的 StorageClass 示例
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast–ssd
provisioner: disk.csi.azure.com # ← CSI 插件
parameters:
skuName: Premium_LRS # ← 高性能 SSD
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

四、CRI — 容器运行时接口

1. 什么是 CRI

CRI（Container Runtime Interface）是 K8s 与容器运行时之间的接口。控制平面（kubelet）通过 CRI 接口向容器运行时发送指令：创建容器、启动容器、停止容器、删除容器。

CNCF 推动了 CRI 的标准化，让 K8s 不再绑死某一种容器运行时。只要实现了 CRI 规范的运行时（containerd、CRI-O 等），都能无缝接入。

2. Docker 与 Containerd 区别

这是很多人搞混的点。K8s 1.20 起正式废弃 dockershim，1.24 起彻底移除。背后发生了什么？

简单说：Docker 是个瑞士军刀，containerd 是那把刀。K8s 只需要刀，不需要军刀上那些开瓶器、剪刀。

生产环境推荐 containerd，理由有三：

• 稳定性更好（少一层 dockerd，少一个故障点）
• 资源占用更低（精简组件、少一个守护进程）
• 集群兼容性更好（所有主流 K8s 发行版默认 containerd）

五、LB — 负载均衡器

1. 什么是 LB

LB（Load Balancer）不是 K8s 的内部接口，而是 Service 的一种对外暴露方式。它的作用：将外部流量分发到后端的多个 Pod 上，实现高可用和负载均衡。

2. Service 类型对比

K8s 的 Service 有四种类型，分别对应不同的流量暴露方式：

3. LoadBalancer 的工作原理

LoadBalancer 类型的 Service 创建后，K8s 会调用云厂商的 Cloud Controller Manager（CCM），向云平台申请一个负载均衡器实例。云 LB 将流量转发到各节点的 NodePort 端口，再分发到 Pod。

自建集群怎么办？

如果集群不在公有云上（比如裸金属或自己搭的集群），没有云 LB 可用，就需要部署软件 LB：

• MetalLB：最常用的开源方案，支持 Layer2 和 BGP 模式
• OpenELB：青云开源的替代方案
• Traefik / Nginx Ingress：七层负载，适合 HTTP/HTTPS 流量

# 云环境下的 LoadBalancer Service
apiVersion: v1
kind: Service
metadata:
name: my–app
spec:
type: LoadBalancer # ← 云厂商会自动创建 LB
selector:
app: my–app
ports:
– port: 80
targetPort: 8080

六、总结

把四者的关系放在一起看：

一句话总结：

CNI 管网络，CSI 管存储，CRI 管容器，LB 管入口。搞懂这四个，K8s 的底层架构你就摸清了七成。