CNI项目中路由表ID管理的技术演进与实践

在容器网络接口(CNI)生态系统中，路由管理一直是网络配置的核心环节。近期社区针对路由表ID的管理方式提出了重要改进方案，这一变化将显著提升多租户网络和复杂路由场景下的配置透明度与控制能力。

背景与现状分析

当前CNI规范的路由结果(Route结构体)中缺少对路由表ID的显式定义，这导致在使用源策略路由(SBR)和虚拟路由转发(VRF)等插件时存在以下痛点：

1. 路由追踪困难：当插件自动将路由迁移到新建表时，运维人员无法直接从CNI结果中获取最终路由位置
2. 配置耦合度高：路由表创建与路由迁移操作强绑定，限制了网络架构的灵活性
3. 策略一致性风险：链式调用中后续插件可能无法准确感知前置插件设置的路由表信息

技术方案详解

新方案在pkg/types/types.go中扩展了Route结构体，新增Table字段作为路由配置的标准属性：

type Route struct {
    Dst   net.IPNet
    GW    net.IP
    Table int    // 新增字段
}

这种设计带来三大核心改进：

1. 声明式路由配置：允许在CNI配置中直接指定目标路由表

{
    "routes": [
        {
            "dst": "10.0.0.1/32",
            "gw": "169.255.100.105",
            "table": 5001
        }
    ]
}

2. 职责分离：基础网络插件只需按配置创建路由，路由策略插件专注规则管理

3. 结果可观测性：CNI执行结果中完整呈现各路由的最终表归属

典型应用场景

多租户网络隔离

通过为每个租户分配独立路由表，配合策略路由实现：

• 租户A路由表：5001
• 租户B路由表：5002
• 默认路由表：main

流量工程

针对不同业务流设置差异化路径：

{
    "routes": [
        {
            "dst": "DB集群/24",
            "table": 200,
            "gw": "备份链路网关"
        },
        {
            "dst": "Web集群/24",
            "table": 100,
            "gw": "主链路网关"
        }
    ]
}

实现建议

1. 版本兼容：Table字段应作为可选属性，未指定时保持现有行为
2. 插件适配：
   • 基础插件(如bridge/macvlan)需支持按表创建路由
   • 策略插件(如SBR)应优先使用配置中的表ID
3. 验证机制：增加表ID冲突检测和合法性校验

未来展望

该改进为CNI生态系统打开了更多可能性：

• 与网络策略引擎深度集成
• 支持动态路由表管理
• 实现跨节点路由表同步

这一演进标志着CNI在复杂网络场景下的成熟度提升，为云原生网络提供了更精细化的控制能力。