在看K8s官方文档时,发现networkpolicy网络策略资源在K8s API目录下,由这一点对K8s的声明式API驱动和控制平面与数据平面分离又有了新的理解。分享给大家。
Kubernetes 不自己实现网络功能,但它通过 API 对象来定义和声明"所需的网络状态",然后由第三方网络插件(CNI)来接收这个声明并负责实现它。
Kubernetes API Server 是所有这些声明的唯一真相来源(Source of Truth)。NetworkPolicy 作为一个 API 资源,意味着网络策略的定义、存储、校验和分发都是由 Kubernetes 核心统一管理的。
层面 | 角色 | 在 NetworkPolicy 中的体现 |
---|---|---|
控制平面 (Control Plane) | 做出决策,下发规则。 | Kubernetes API Server 和控制器: 1. 接收用户提交的 NetworkPolicy YAML。 2. 验证其合法性并存入 etcd。 3. 将策略的"声明"下发到各个节点。 |
数据平面 (Data Plane) | 执行决策,处理实际的数据包。 | CNI 网络插件(如 Calico, Cilium, Weave Net): 1. 监听 API Server 的 NetworkPolicy 变化。 2. 将 NetworkPolicy 的声明转换 为具体的、可执行的网络规则(如 iptables 规则、eBPF 程序)。 3. 在数据路径上实施这些规则,真正地允许或拒绝流量。 |
-
你定义策略时,使用的是 Pod 标签选择器(Selectors) 、命名空间(Namespace),而不是传统的 IP 地址、子网、网卡。
-
这意味着开发者/运维人员可以继续使用他们熟悉的 Kubernetes 概念(标签、命名空间)来管理网络安全,而无需深入了解底层的复杂网络知识(IP 地址管理、路由协议、防火墙命令)。
NetworkPolicy 被列为 Kubernetes API 下的一个资源,反映了一种高度抽象、声明式、解耦的现代化系统设计结构:
-
声明式 API 驱动:NetworkPolicy 是用户向系统声明的"期望网络状态"。
-
控制平面与数据平面分离:Kubernetes 核心作为控制平面负责管理和下发声明;CNI 插件作为数据平面负责具体实现。
-
以应用为中心:策略使用应用层概念(标签、命名空间)进行定义,而不是底层网络细节。
-
生态扩展性:通过标准化的 API,Kubernetes 成功地将网络能力外包给了专业的第三方插件,构建了强大的生态系统。