根据天翼云官方文档《混合集群网络》的详细内容，现对线上（云上VPC）与线下（本地自建K8s集群）容器实例Pod的互联条件与原理，做更细颗粒度的技术说明。
一、核心目标
文档明确指出混合集群网络要打通两个层面：
“搭建混合集群的网络关键在于打通云上云下网络连通，包括：云上VPC网络与云下网络互通，即计算节点之间互连互通；云上容器网络与云下容器网络互通，即容器Pod之间互连互通。”
两个层面的关系是：节点网络互通是容器网络互通的前提条件，只有节点之间能够互相访问，运行在节点上的Pod才具备通信的基础。
二、节点网络互通：技术实现细节
2.1 专线接入方案
文档明确要求将云下网络通过内网接入天翼云，具体方案为天翼云提供的专线方案：
“将云下网络通过内网接入天翼云，请参考天翼云提供的专线方案 云上云下网络专线接通方案。”
技术原理：专线方案通过物理或虚拟专用通道，在云上VPC与云下数据中心之间建立二层或三层直连网络。与传统公网VPN相比，专线方案能够提供更稳定的带宽、更低的延迟和更高的安全性。专线建立后，云上VPC的路由表和云下数据中心的路由器需要配置相互指向对方网段的路由规则，确保数据包能够跨环境转发。
2.2 连通性验证
“测试云上云下连通性，验证云下节点与云上节点是否互通。”
验证方式：通常通过ping命令测试云上ECS节点IP与云下物理节点IP之间的连通性，确认网络延迟和丢包率在可接受范围内。
2.3 域名解析配置（针对云产品访问）
“如需要云下网络需要通过内网访问云产品，云下网络需配置云产品的域名解析（*.ctyun.cn域名解析转发到云上DNS VPCE IP），云产品包括：CRS镜像仓库、对象存储、日志、监控等。”
技术原理：云下节点访问云产品（如镜像仓库、对象存储等）时，域名*.ctyun.cn的解析请求会被转发到云上DNS VPCE（VPC Endpoint）的内网IP。VPCE是一种VPC内的私有连接服务，允许云下节点通过内网而非公网访问云服务，从而降低网络延迟并提高安全性。这种机制避免了云下节点走公网出口访问云产品，保证了网络路径的统一性。
三、容器网络互通：场景一（Underlay模式）
3.1 什么是Underlay模式
“平面网络模式，一般用于集群规模较大(或规划较大)且对网络性能要求较高的场景。常见的开源Underlay模式组件包括：Flannel Host-GW模式、Calico 路由反射模式、Cilium BGP路由模式。”
技术原理：Underlay模式下，Pod的网络接口直接复用宿主机所在的底层物理网络。每个Pod都会被分配一个在底层网络中可路由的IP地址，相当于Pod成为了网络中的“一等公民”。数据包从Pod发出后，直接经过宿主机的网络协议栈，依靠底层网络设备（交换机、路由器）的路由表进行转发，无需额外的隧道封装。这种模式性能接近宿主机原生网络，Pod IP在集群外也天然可达。
关键特性：
-
Pod IP可路由：Pod IP在集群外部（包括云上VPC内）可直接访问。
-
高性能：无隧道封装开销，网络延迟低。
-
依赖路由配置：需要底层网络设备配置正确的路由规则。
3.2 Underlay模式下的配置条件
“若云下Kubernetes的容器网络模式是Underlay模式，那么云上节点需要使用Cubecni网络插件。在此模式下，需要满足以下条件：云下网络插件只运行在云下计算节点。云上的Cubecni网络插件只运行在云上计算节点，不会被调度到云下计算节点。”
配置条件解读：
-
云上节点必须使用Cubecni：Cubecni是天翼云自研的CNI网络插件，专为VPC环境设计。它能够将云上VPC的弹性网卡（ENI）直接分配给Pod，使Pod获得VPC内的独立IP地址，与云上ECS处于同一网络平面，实现高性能网络通信。
-
插件隔离的必要性：云下网络插件（如Calico）是为管理物理服务器的网络接口设计的，无法正确配置云上ECS的虚拟网卡。如果云下插件被调度到云上节点，会导致网络配置错误、Pod无法通信等问题。同理，Cubecni也无法在物理服务器上正常工作。因此，必须通过调度策略将两种插件限制在各自的环境中运行。
3.3 插件隔离的具体实现方式
3.3.1 节点标签自动添加
“分布式容器云平台三方集群节点扩容的云上ECS节点会自动添加节点标签k8s.node.ctyun.cn/cloud=true，默认云上Cubecni网络插件会根据云上节点标签自动调度到云上ECS节点。”
技术原理：当通过CCE One平台将云上ECS节点扩容到混合集群中时，系统会自动为该节点打上k8s.node.ctyun.cn/cloud=true标签。Cubecni插件作为DaemonSet部署时，通过节点亲和性（NodeAffinity）规则，只会调度到带有该标签的节点上，即只运行在云上节点。
3.3.2 为云下网络插件设置调度策略
“请根据节点标签为云下网络插件设置NodeAffinity，或设置相关污点来确保云下网络插件只运行在云下。例如，针对云下Calico网络插件，使用nodeAffinity设置其不会被调度到标签为k8s.node.ctyun.cn/cloud=true的节点上。”
配置示例：
cat <<EOF > calico-ds.patch spec: template: spec: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: k8s.node.ctyun.cn/cloud operator: NotIn values: - "true" EOF kubectl -n kube-system patch ds calico-node -p "$(cat calico-ds.patch)"[reference:8]
技术原理：requiredDuringSchedulingIgnoredDuringExecution是Kubernetes中一种强制性的节点亲和性规则。上述配置的含义是：Calico网络插件的Pod必须被调度到k8s.node.ctyun.cn/cloud标签值不为true的节点上，即只能运行在线下节点。operator: NotIn表示“不包含”，values: ["true"]指定了要排除的标签值。这样，即使集群中混入了云上节点，Calico插件也不会被调度到这些节点上。
3.3.3 安装Cubecni插件
“在插件市场页面，搜索cubecni插件或者cubecni-standalone插件，单击右下方安装。...在三方集群扩容云上节点前，cubecni不会被调度到任何一个云下节点上。”
技术原理：Cubecni插件通过DaemonSet方式部署，Kubernetes调度器会根据节点的标签和Pod的节点亲和性规则，自动将Cubecni Pod调度到符合条件的节点上。由于Cubecni配置了只调度到带有k8s.node.ctyun.cn/cloud=true标签的节点，而该标签只存在于云上ECS节点上，因此Cubecni Pod只会运行在云上节点。在云上节点尚未扩容加入集群之前，Cubecni Pod处于Pending状态，不会被调度到云下节点。
3.4 Underlay模式跨集群通信的数据流
当配置完成后，云上Pod（使用Cubecni）与云下Pod（使用Calico Underlay模式）通信的数据流如下：
-
源Pod发起请求：云上Pod A产生一个发往云下Pod B IP的数据包。
-
节点路由查询：数据包到达云上节点后，Cubecni根据节点上维护的路由表，查询目标Pod B IP所属的网段。由于Underlay模式下各集群的容器网段已通过专线路由表同步，路由表中存在指向云下容器网段的路由规则。
-
数据包转发：云上节点根据路由规则，将数据包发送到专线接口，由专线设备将数据包传递到云下数据中心。
-
云下节点接收：云下节点收到数据包后，Calico插件根据本地路由表，将数据包最终交付给Pod B。
四、容器网络互通：场景二（Overlay隧道模式）
4.1 什么是Overlay隧道模式
“隧道网络模式相较平面网络模式，存在10%~20%的性能损失，一般用于集群规模较小且对网络性能要求不高的场景。场景开源组件模式包括：Flannel VXLan模式、Calico IPIP模式、Cilium VXLan模式。”
技术原理：Overlay模式在现有底层网络（Underlay网络）之上构建一个虚拟的、逻辑上的网络层。Pod的原始IP包被封装在一个新的IP包中，新IP包的源和目标地址分别是源节点和目标节点的物理IP地址。封装后的数据包通过底层网络进行传输，到达目标节点后，再由网络插件解封装，恢复出原始的Pod IP包并交付给目标Pod。这种“隧道”机制使得Pod网络可以与底层网络解耦，Pod IP不需要在底层网络中可路由。
性能损耗原因：封装和解封装过程需要额外的CPU计算，且封装后的数据包体积增大（VXLAN封装会增加50字节左右的头部），导致网络吞吐量下降和延迟增加。
4.2 Overlay模式下的配置条件
“若云下Kubernetes集群的容器网络模式为隧道网络，则云上节点也可以复用该网络模式，只需保证云上节点能够拉取到容器网络插件所需容器镜像即可。”
配置条件解读：
-
复用相同的网络插件：云上节点需要安装与云下集群相同的网络插件（如Flannel、Calico），且使用相同的隧道协议（如VXLAN或IPIP）。
-
镜像拉取能力：云上节点需要能够拉取到该网络插件所需的容器镜像。这要求云上节点能够访问镜像仓库（可以是公网或私有仓库）。
-
无需插件隔离：由于Overlay模式不依赖底层网络的具体实现，同一个网络插件既可以在云下物理服务器上工作，也可以在云上ECS上工作。因此，不需要像Underlay模式那样进行复杂的插件隔离配置。
4.3 Overlay模式跨集群通信的数据流
以VXLAN隧道模式为例，跨集群Pod通信的数据流如下：
-
源Pod发起请求：云下Pod A产生一个发往云上Pod B IP的数据包（Pod IP可能在10.244.0.0/16网段）。
-
源节点封装：云下节点的Flannel插件识别到目标Pod IP属于另一个节点（云上节点），将原始Pod IP包封装在一个VXLAN UDP包中。新数据包的源IP是云下节点的物理IP，目标IP是云上节点的物理IP。
-
底层网络传输：封装后的数据包通过已打通的专线网络，从云下节点传输到云上节点。
-
目标节点解封装：云上节点的Flannel插件收到VXLAN包后，解封装取出原始的Pod IP包。
-
最终交付：云上节点根据本地路由信息，将原始Pod IP包交付给目标Pod B。
五、两种模式的对比总结
| 对比维度 | Underlay模式 | Overlay隧道模式 |
|---|---|---|
| 网络模型 | Pod直接使用宿主机底层网络 | Pod网络通过隧道叠加在底层网络之上 |
| Pod IP可达性 | 集群外可路由，需配置路由 | 集群外不可达，需隧道封装 |
| 性能损耗 | 接近原生，无明显损耗 | 10%~20%性能损失（封装/解封装开销） |
| 云上插件要求 | 必须使用Cubecni | 复用云下相同插件（Flannel/Calico） |
| 插件调度 | 必须隔离：通过节点亲和性强制分开 | 无需特殊隔离 |
| 配置复杂度 | 较高（需配置路由、插件亲和性） | 较低（复用即可） |
| 适用场景 | 大规模集群、对性能要求高的场景 | 中小规模集群、对性能不敏感的场景 |
| 网段重叠容忍 | 不允许（路由会冲突） | 允许（隧道隔离） |
