【K8s】K8s的声明式API核心

在看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 下的一个资源，反映了一种高度抽象、声明式、解耦的现代化系统设计结构：

1. 声明式 API 驱动​​：NetworkPolicy 是用户向系统声明的“期望网络状态”。

2. ​​控制平面与数据平面分离​​：Kubernetes 核心作为控制平面负责管理和下发声明；CNI 插件作为数据平面负责具体实现。

3. ​​以应用为中心​​：策略使用应用层概念（标签、命名空间）进行定义，而不是底层网络细节。

4. ​​生态扩展性​​：通过标准化的 API，Kubernetes 成功地将网络能力外包给了专业的第三方插件，构建了强大的生态系统。