ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

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

Meshery 中的 Kubernetes NetworkPolicy 设计模式:以应用为中心控制 TCP/UDP/SCTP 流量 云原生微服务运维DevOps【免费下载链接】mesheryMeshery, the cloud native manager项目地址https://gitcode.com/GitHub_Trending/me/meshery点击查看免费下载本文围绕 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。该设计由以下组件与关系组成一个Namespacedefault组件作为策略的承载命名空间也是层级关系的父节点一个NetworkPolicynetwork-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逐字段拆解规则语义字段示例取值语义说明spec.podSelectorrole: db策略作用的目标 Pod 集合空选择器表示匹配策略所在命名空间内的所有 Pod。多个策略可以同时选中同一批 Pod规则是**累加additive**生效的spec.policyTypes[Ingress, Egress]声明本策略管辖的规则类型。注意若只写了egress规则而不显式声明policyTypes: [Egress]策略会默认同时影响 Ingress可能导致意外隔离ingress[].from命名空间选择器 Pod 选择器from列表内各项是OR关系来自projectmyproject命名空间内任意 Pod或本命名空间内rolefrontend的 Pod 均被允许ingress[].portsTCP 6379端口列表内各项同样是OR关系只有同时匹配端口与来源的流量才被放行egress[].toipBlock: 10.0.0.0/24出站目标这里用 IPBlock 而非选择器适合表达对某个子网网段的放行egress[].portsTCP 5978出站端口约束规则要求同时满足to与ports才会放行上述from/to中三类对端描述方式对应 KubernetesNetworkPolicyPeer的三种形态语义上相互排斥同一 peer 只能设置其中一种podSelector选择策略所在命名空间内的 Pod若与namespaceSelector同时出现则选择“由 namespaceSelector 选中的命名空间内、匹配 podSelector 的 Pod”namespaceSelector按集群级命名空间标签选择命名空间为空时选中所有命名空间ipBlock用 CIDR 指定网段如192.168.1.0/24或2001:db8::/64并可通过except字段在 CIDR 范围内排除部分地址。两个容易踩坑的默认行为端口缺省ports为空或缺失时规则匹配所有端口protocol缺省时默认TCP。因此“只写from不写ports”意味着放行该来源的所有端口流量请务必按最小权限原则补齐端口。Egress-only 必须显式声明官方 Schema 明确指出如果要写一条只影响出站的策略必须显式指定policyTypes: [Egress]否则 Kubernetes 会把策略同时视为 Ingress 策略导致目标 Pod 入站流量也被隔离。这些字段的权威描述直接内嵌在仓库的 Kubernetes 模型定义中models/kubernetes/v1.35.0/v1.0.0/components/NetworkPolicy.jsoncomponent.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.goCLI 将sourceType映射为内部枚举K8sManifest、MesheryDesign、HelmChart、DockerCompose构造POST {baseMesheryURL}/api/pattern/import请求体本地文件以MesheryPatternImportFilePayload携带fileName与文件内容提交远程 URL 则以MesheryPatternImportURLPayload提交服务端返回已保存设计[]*models.MesheryPatternCLI 打印导入成功信息与设计 IDutils.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为NetworkPolicyversion为networking.k8s.io/v1schema 内嵌完整的 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 清单在部署结果上等价。实战建议如何把样例改造成你的生产策略官方将本设计定位为“按需修改的样例”。结合上述规则语义给出三条改造建议收紧 Ingress 来源示例同时放行了projectmyproject命名空间与rolefrontendPod 两类来源OR 语义。生产环境中建议按真实调用关系删除多余分支仅保留必要的调用方为 Egress 补充端口矩阵出站规则只放行了10.0.0.0/24网段的TCP 5978。如果工作负载还需访问 DNSUDP 53或对象存储需要追加对应规则否则流量会被策略拦截Kubernetes 会据此在兼容的 CNI 上生成流表显式声明 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.ymlNetworkPolicy 组件模型与字段 Schemamodels/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【免费下载链接】mesheryMeshery, the cloud native manager项目地址https://gitcode.com/GitHub_Trending/me/meshery点击查看免费下载相关推荐在 Meshery 中通过 Catalog 设计模式为 Kubernetes Pod 配置资源限制在 Meshery 中通过 Catalog 设计模式为 Kubernetes Pod 配置资源限制 本篇技术指南围绕 Meshery Catalog 中的 Po云原生微服务运维DevOpsMeshery Edge Firewall 关系解析基于 NetworkPolicy 的 Pod 间流量管控设计实践Meshery Edge Firewall 关系解析基于 NetworkPolicy 的 Pod 间流量管控设计实践 导读 本文围绕 Meshery Cata云原生微服务运维DevOpsLynx list 元素完全指南从选型决策、属性事件到引擎侧实现原理Lynx list 元素完全指南从选型决策、属性事件到引擎侧实现原理 本篇围绕 Lynx 仓库中 ai/skills/lynx api docs 技能包内的云原生微服务运维DevOps上一篇终极NS模拟器管理神器让你的Switch游戏体验轻松起飞下一篇NS模拟器管理困境的终结者NsEmuTools如何重塑你的游戏体验创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表