Meshery 中的 Kubernetes NetworkPolicy 设计模式：以应用为中心控制 TCP/UDP/SCTP 流量

• 云原生
• 微服务
• 运维
• DevOps

本文围绕 Meshery 官方 Catalog 中的 “Network policy” 流量管理设计（patternId7b2e40b0-3cc8-4da3-bccd-b66bc6cd206a）展开，讲解如何在 Meshery 中以可视化设计与 YAML 两种方式构建 Kubernetes NetworkPolicy，并深入解析其 Ingress/Egress 规则、选择器语义与底层组件 Schema，帮助你掌握一套开箱即用的集群网络隔离落地模板。

为什么要用 NetworkPolicy 管理集群流量

在 Kubernetes 集群中，Pod 之间的流量默认是“全通”的。当你希望在 IP 地址或端口级别控制 TCP、UDP 与 SCTP 协议的流量流向时，Kubernetes 提供的NetworkPolicy是首选原语。它不是一个服务网格能力，而是一个**以应用为中心（application-centric）**的构造：它描述的是“某个 Pod 被允许与哪些网络实体通信”，这里的“实体”（entity）是官方刻意选择的措辞，用于避免与 Kubernetes 中已有特定语义的术语如endpoints、services产生歧义。

NetworkPolicy 作用于一端或两端都连接 Pod 的连接，对于不涉及 Pod 的连接并不生效。也就是说，它是围绕工作负载（Pod）做细粒度放行规则，而不是围绕节点或网段做防火墙。

在 Meshery 中，这类策略被封装为可复用的 Catalog 设计。本次分析的示例设计即是一个同时定义了Ingress（入站）与Egress（出站）规则的样例策略，官方 Caveats 明确指出：This is a sample network policy with ingress, egress defined, change according to your requirements——即它是供你按业务需求修改的起点模板。

设计蓝图：这份 NetworkPolicy 到底做了什么

Meshery Catalog 的每个设计都以 JSON/YAML 形式存储在 docs/data/catalog 目录下，本文对应文件为 7b2e40b0-3cc8-4da3-bccd-b66bc6cd206a/0.0.1/design.yml。该设计由以下组件与关系组成：

• 一个Namespace（default）组件：作为策略的承载命名空间，也是层级关系的父节点；
• 一个NetworkPolicy（network-policy-policy）组件：apiVersion为networking.k8s.io/v1，配置了完整的spec；
• 一条hierarchical / parent关系：将defaultNamespace 作为父组件，NetworkPolicy 的metadata.namespace由父组件继承补齐。

从design.yml的configuration字段可以还原出等价的 Kubernetes 清单：

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: network-policy-policy namespace: default spec: podSelector: matchLabels: role: db policyTypes: - Ingress - Egress ingress: - from: - namespaceSelector: matchLabels: project: myproject - podSelector: matchLabels: role: frontend ports: - protocol: TCP port: 6379 egress: - to: - ipBlock: cidr: 10.0.0.0/24 ports: - protocol: TCP port: 5978

逐字段拆解规则语义

上述from/to中三类对端描述方式对应 KubernetesNetworkPolicyPeer的三种形态，语义上相互排斥（同一 peer 只能设置其中一种）：

• podSelector：选择策略所在命名空间内的 Pod（若与namespaceSelector同时出现，则选择“由 namespaceSelector 选中的命名空间内、匹配 podSelector 的 Pod”）；
• namespaceSelector：按集群级命名空间标签选择命名空间；为空时选中所有命名空间；
• ipBlock：用 CIDR 指定网段，如192.168.1.0/24或2001:db8::/64，并可通过except字段在 CIDR 范围内排除部分地址。

两个容易踩坑的默认行为

1. 端口缺省：ports为空或缺失时，规则匹配所有端口；protocol缺省时默认TCP。因此“只写from不写ports”意味着放行该来源的所有端口流量，请务必按最小权限原则补齐端口。
2. Egress-only 必须显式声明：官方 Schema 明确指出，如果要写一条只影响出站的策略，必须显式指定policyTypes: ["Egress"]；否则 Kubernetes 会把策略同时视为 Ingress 策略，导致目标 Pod 入站流量也被隔离。

这些字段的权威描述直接内嵌在仓库的 Kubernetes 模型定义中：models/kubernetes/v1.35.0/v1.0.0/components/NetworkPolicy.json（component.schema字段完整覆盖了ingress、egress、podSelector、policyTypes、NetworkPolicyPort、IPBlock等结构的类型、默认值与约束），是核对字段行为的可靠参考。

在 Meshery 中使用这份设计

方式一：用 mesheryctl 导入

Catalog 设计的标准消费方式是通过mesheryctl design import将设计文件导入到你的 Meshery 实例。命令用法如下：

mesheryctl design import -f [file/URL] -s [source-type] -n [name]

对应当前设计，你可以直接导入仓库中已存在的数据文件：

mesheryctl design import -f docs/data/catalog/7b2e40b0-3cc8-4da3-bccd-b66bc6cd206a/0.0.1/design.yml -s "Meshery Design" -n network-policy

参数说明：

• -f, --file：设计文件的本地路径或可直接下载的远程 URL（如 GitHub raw 直链）；
• -s, --source-type：源文件类型，可选Helm Chart、Kubernetes Manifest、Meshery Design、Docker Compose；不传时由 Meshery 自动识别，YAML 与 TGZ（仅 Helm）均可，Meshery Design 还支持 OCI 格式；
• -n, --name：导入后设计名称，缺省时以文件名作为名称。

从源码看，导入流程的调用链位于 mesheryctl/internal/cli/root/design/import.go：

1. CLI 将sourceType映射为内部枚举（K8sManifest、MesheryDesign、HelmChart、DockerCompose）；
2. 构造POST {baseMesheryURL}/api/pattern/import请求体，本地文件以MesheryPatternImportFilePayload（携带fileName与文件内容）提交，远程 URL 则以MesheryPatternImportURLPayload提交；
3. 服务端返回已保存设计（[]*models.MesheryPattern），CLI 打印导入成功信息与设计 ID（utils.TruncateID截断显示）。

仓库的端到端测试 mesheryctl/tests/e2e/003-design/01-design-import.bats 也验证了mesheryctl design import -f nginx.yaml --source-type "Kubernetes Manifest"的成功输出（包含imported/Design ID/saved等关键词），可作为导入命令的验收基准。

方式二：在 Meshery UI 的画布上可视化编辑

Catalog 中该设计的 UI 元数据（位于 docs/catalog/traffic-management/7b2e40b0-3cc8-4da3-bccd-b66bc6cd206a.md）说明它归属traffic-management类型，兼容kubernetes平台，并携带 0.0.1 的发布版本号。你可以在 Meshery 的Designs（设计）画布中：

• 从调色板拖入NetworkPolicy组件（Kubernetes 模型，版本networking.k8s.io/v1），并为其配置Workload Configuration（编辑spec）；
• 将Namespace拖入画布后，通过Compound Drag And Drop把 NetworkPolicy 放入命名空间内，画布会自动建立 hierarchical 的 parent 关系，并将命名空间名称写入策略的metadata.namespace；
• 在设计中关联真实集群连接后，通过Deploy（部署）动作把策略应用到目标 Kubernetes 环境。

画布上的 NetworkPolicy 节点样式（圆形、#326CE5主色）与全部可执行能力（性能测试、配置、关系查看、Schema 查看、形状修改、复合拖放等）均定义在组件的styles与capabilities字段中，这些能力同时被设计文件design.yml和模型定义 NetworkPolicy.json 所引用，保证了“设计即代码”的一致体验。

结合源码理解：Meshery 如何把设计变成集群策略

Meshery 的组件模型（components.meshery.io/v1beta1）将每一个 Kubernetes 资源都描述为kind + schema + capabilities的元数据组合。对本设计而言：

• 组件识别：component.kind为NetworkPolicy，version为networking.k8s.io/v1，schema 内嵌完整的 OpenAPI 描述（来源标注为git://github.com/kubernetes/kubernetes/master/api/openapi-spec/v3）；
• 关系推断：设计与 Namespace 之间使用hierarchical/parent关系，selectors定义了 patch 方向——父组件的displayName会被写入子组件的configuration.metadata.namespace。这意味着在画布中只要把策略拖入命名空间，命名空间归属就会被自动补全，无需手写metadata.namespace；
• 部署语义：导入后的设计（designs.meshery.io/v1beta1）即可通过mesheryctl design apply/deploy或 UI 部署到已连接的集群。

这种“组件 + 关系”的建模方式意味着：你看到的这张画布（NetworkPolicy 挂在一个 default Namespace 下）本质上就是一份完整的、可版本化、可导入导出的基础设施即代码（IaC），与手写的 YAML 清单在部署结果上等价。

实战建议：如何把样例改造成你的生产策略

官方将本设计定位为“按需修改的样例”。结合上述规则语义，给出三条改造建议：

1. 收紧 Ingress 来源：示例同时放行了project=myproject命名空间与role=frontendPod 两类来源（OR 语义）。生产环境中建议按真实调用关系删除多余分支，仅保留必要的调用方；
2. 为 Egress 补充端口矩阵：出站规则只放行了10.0.0.0/24网段的TCP 5978。如果工作负载还需访问 DNS（UDP 53）或对象存储，需要追加对应规则，否则流量会被策略拦截（Kubernetes 会据此在兼容的 CNI 上生成流表）；
3. 显式声明 policyTypes：无论规则如何裁剪，都建议显式写出policyTypes: ["Ingress", "Egress"]（或只写需要的类型），避免依赖隐式默认值带来的语义漂移。

改造完成后，通过mesheryctl design import重新导入、或直接在画布中保存为新的设计版本，即可纳入 Meshery 的统一设计与部署流程。

延伸阅读

• 本设计的 Catalog 入口文档：docs/catalog/traffic-management/7b2e40b0-3cc8-4da3-bccd-b66bc6cd206a.md
• 设计数据文件（含完整组件与关系定义）：docs/data/catalog/7b2e40b0-3cc8-4da3-bccd-b66bc6cd206a/0.0.1/design.yml
• NetworkPolicy 组件模型与字段 Schema：models/kubernetes/v1.35.0/v1.0.0/components/NetworkPolicy.json
• 设计导入命令实现与测试：mesheryctl/internal/cli/root/design/import.go、mesheryctl/tests/e2e/003-design/01-design-import.bats
• 更多同类流量管理设计可参考 docs/catalog/traffic-management 目录下的其余条目

• 云原生
• 微服务
• 运维
• DevOps