Otomi Core 项目中的网络策略重构方案解析

在 Kubernetes 生态系统中，网络策略(NetworkPolicy)是控制 Pod 之间网络通信的重要机制。近期 Otomi Core 项目团队针对网络策略的管理方式进行了重要重构，将原本与服务绑定的网络策略独立出来，使其更加符合 Kubernetes 的设计理念和实际使用场景。

重构背景与动机

传统实现中，Otomi 将网络策略定义在团队服务(team service)对象中，这种方式存在几个明显问题：

1. 网络策略本质上针对的是工作负载(Pod)而非服务(Service)
2. 出口策略(egress)通常是命名空间级别的控制
3. 现有结构限制了跨命名空间的流量控制能力

重构后的设计将网络策略作为独立的一级资源，用户可以直接通过左侧菜单访问和管理，这更符合 Kubernetes 的原生设计思想。

架构变更要点

策略位置迁移

网络策略从原来的 <team>.services.[*].networkPolicy 路径迁移到了新的 <team>.networkPolicies[*] 位置。这种变化使得策略定义不再与服务强耦合，可以独立存在和管理。

字段语义优化

重构对字段命名进行了重大调整，使其更加准确反映功能：

• podSelector 改为 toLabel，明确表示这是目标 Pod 的选择器
• team 改为 fromNamespace，并自动添加 team- 前缀
• service 改为 fromLabel，更准确地描述来源工作负载

权限结构调整

自服务(selfService)的网络策略配置从 selfService.service.networkPolicy 移动到了 selfService.networkPolicy，这一变化简化了权限管理结构，使 API 能够更直接地处理相关权限。

策略定义示例

新的网络策略定义采用更清晰的语法结构：

netpol:
  - type: ingressPrivate
    name: my-net
    toNamespace: team-a
    fromNamespace: team-b
    toLabel: 
      - a=b
    fromLabel: 
      - a=b
  - type: egressExternal
    name: toGoogle
    domain: https://google.com

这种结构明确区分了入口和出口策略，并提供了更灵活的标签选择机制。

标签选择器最佳实践

在 Kubernetes 中，工作负载通常带有标准 Helm 标签：

metadata:
  labels:
    helm.sh/chart: rabbitmq-0.1.0
    app.kubernetes.io/name: rabbitmq
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/version: "1.16.0"
    app.kubernetes.io/managed-by: Helm

由于 Helm release 名称在命名空间内必须唯一，网络策略可以安全地使用 app.kubernetes.io/instance 标签来精确选择目标 Pod。

迁移与兼容性考虑

项目团队设计了平滑的迁移方案：

1. 自动将现有策略转换为新格式
2. 处理所有字段重命名和结构调整
3. 确保权限系统继续正常工作

这种向后兼容的设计确保了用户在升级 Otomi 时不会遇到服务中断或配置丢失的问题。

总结

Otomi Core 这次网络策略重构体现了几个重要改进方向：

1. 更符合 Kubernetes 原生资源的设计理念
2. 提供了更灵活的网络隔离控制能力
3. 改善了配置的可读性和可维护性
4. 保持了良好的向后兼容性

这些变化将使 Otomi 用户能够更有效地管理微服务间的网络通信，同时为未来的功能扩展奠定了更好的基础。对于正在使用或考虑采用 Otomi 的团队，建议尽快熟悉这一新机制，以充分利用其提供的增强功能。