Otomi Core 项目网络策略重构技术解析

背景与动机

在 Kubernetes 生态中，网络策略(NetworkPolicy)是控制 Pod 之间网络通信的重要机制。Otomi Core 项目近期对其网络策略实现进行了重要重构，将原本内置于服务(Service)对象中的网络策略抽离出来，形成独立的配置结构。这一变革主要基于以下技术考量：

1. 关注点分离：网络策略本质上作用于工作负载(Pod)层面，而非服务抽象层
2. 作用域清晰化：出口策略(egress)通常作用于整个命名空间范围
3. 配置灵活性：允许跨团队命名空间的通信控制

架构变更要点

配置结构迁移

重构前，网络策略嵌套在服务配置中：

team:
  services:
    - name: my-service
      networkPolicy: {...}

重构后采用扁平化结构：

team:
  networkPolicies:
    - name: policy1
      type: ingressPrivate
      toLabel:
        app.kubernetes.io/instance: my-service

关键字段语义优化

1. 选择器重命名：

   • podSelector → toLabel（明确表示目标工作负载）
   • service → fromLabel（准确描述来源工作负载特征）

2. 命名空间引用规范化：

   • team → fromNamespace（语义更明确）
   • 自动添加team-前缀保持命名一致性

3. 策略类型细分：

   • ingressPrivate：团队内部或跨团队入口策略
   • egressExternal：外部域名访问控制

技术实现细节

标签选择器最佳实践

Kubernetes 工作负载通常带有标准标签：

labels:
  app.kubernetes.io/name: rabbitmq
  app.kubernetes.io/instance: release-name

在策略配置中，我们推荐使用app.kubernetes.io/instance作为主要选择器，因为：

• Helm release 名称在命名空间内唯一
• 避免与同名应用的不同实例混淆

策略作用域控制

示例配置展示完整能力：

networkPolicies:
  - type: ingressPrivate
    name: inter-team-comm
    toNamespace: team-a
    fromNamespace: team-b
    toLabel: 
      - app.kubernetes.io/instance: frontend
    fromLabel: 
      - app.kubernetes.io/instance: backend
  - type: egressExternal
    name: google-access
    domain: https://google.com

迁移与兼容性

项目提供了平滑迁移方案：

1. 自动转换：旧版配置自动迁移至新结构
2. 字段映射：保持功能不变的同时优化字段命名
3. 权限继承：服务级策略权限自动提升至团队级

运维建议

1. 策略调试：建议使用kubectl describe networkpolicy验证策略生效情况
2. 标签管理：统一采用Kubernetes推荐标签规范
3. 渐进式部署：复杂环境建议分阶段验证策略效果

总结

这次重构使Otomi Core的网络策略管理更加符合Kubernetes设计哲学，提供了更清晰的抽象层次和更灵活的配置能力。运维团队现在可以：

• 独立管理网络策略而不影响服务定义
• 实现精细化的跨团队通信控制
• 更直观地理解策略作用范围

该变更体现了云原生配置管理的发展趋势——通过声明式配置实现关注点分离，同时保持系统的可维护性和可扩展性。