作者：云原生应用平台 - 陈赟豪(环河)

本文深入浅出地介绍了容器网络出现的背景、容器网络的CNI插件及分类对比，描述了容器网络插件的Pod同节点和跨节点通信过程及其应用场景，让读者能过通过简短的篇幅窥见容器网络的真谛。

背景

容器网络为何出现

在一个汽车发动机的生产车间中，汽车发动机的各个组件会存在一定的顺序进行组装，这就要求有直接关系的组件必须知道下一个组件的具体位置。当一个汽车发动机组装完成后，距离最后成品汽车，还差了很多部件，比如底盘，车身等。此时，需要将发动机发往一个装配中心进行组合安装，这样我们就必须知道装配中心的地理位置。

这些位置在容器中可以理解为IP地址，容器网络便是如此。在上面这个例子里，即描述了容器网络本节点内部互通场景，又描述了跨节点的通信场景

随着云计算的发展，应用间通信从物理机网络，虚拟机网络，发展到目前的容器网络。由于容器不同于物理机、虚拟机，容器可以被理解为一个标准的，轻量级的，便携的，独立的集装箱，集装箱之间相互隔离，都使用自己的环境和资源。但随着越来越复杂环境变化，容器在运行中会需要容器间或者容器与集群外部之间的信息传输，这时候容器就要在网络层面拥有一个名字（即IP地址），由此容器网络就应运而生。

再从技术的角度来谈容器网络的由来，首先要从容器本质说起，它是由以下几点来实现的：

• cgroup：实现资源的可配额
• overlay fs：实现文件系统的安全性和便携性
• namespace：实现资源的隔离性

• IPC ：System V IPC 和 POSIX 消息队列
• Network：网络设备、网络协议栈、网络端口等
• PID：进程
• Mount：挂载点
• UTS：主机名和域名
• USR：用户和用户组

由于主机与容器、容器与容器间的网络栈并不相通，也没有统一的控制面，导致容器间无法直接的感知。为了解决这个问题，本文中我们要讨论的容器网络出现了，再配合不同的网络虚拟化技术带来了多样化的容器网络方案。

容器网络的基本要求

• IP-per-Pod，每个 Pod 都拥有一个独立 IP 地址，Pod 内所有容器共享一个网络命名空间
• 集群内所有 Pod 都在一个直接连通的扁平网络中，可通过 IP 直接访问

• 所有容器之间无需 NAT 就可以直接互相访问
• 所有 Node 和所有容器之间无需 NAT 就可以直接互相访问
• 容器自己看到的 IP 跟其他容器看到的一样

• Service cluster IP 尽可在集群内部访问，外部请求需要通过 NodePort、LoadBalance或者 Ingress 来访问

网络插件介绍

网络插件概述

容器和该容器所在的宿主机是分隔的两地，如果需要连通就得建立一座桥梁，但由于容器侧还没有名字，就无法建立桥梁，这时候就先需要给容器侧命名，这样才能成功建立起桥梁。网络插件就是起到给容器侧命名和建立桥梁的功能。

即网络插件将网络接口插入容器网络命名空间（例如，veth 对的一端），并在主机上进行任何必要的改变（例如将 veth 的另一端连接到网桥）。然后通过调用适当的 IPAM 插件（IP地址管理插件）分配给接口一个空闲的IP地址，并设置与此IP地址相对应的路由规则。

对于 k8s 来讲，网络属于最重要的功能之一，因为没有一个良好的网络，集群不同节点之间甚至同一个节点之间的 pod 就无法良好的运行起来。

但是k8s在设计网络的时候，采用的准则就一点：“灵活”！那怎么才能灵活呢？那就是k8s 自身没有实现太多跟网络相关的操作，而是制定了一个规范：

1. 有配置文件，能够提供要使用的网络插件名，以及该插件所需信息
2. 让 CRI 调用这个插件，并把容器的运行时信息，包括容器的命名空间，容器 ID 等信息传给插件
3. 不关心网络插件内部实现，只需要最后能够输出网络插件提供的pod IP即可

没错一共就这三点，如此简单灵活的规范就是大名鼎鼎的 CNI 规范

不过恰恰因为 k8s 自己“啥也不干”，所以大家可以自由发挥，自由实现不同的 CNI 插件，即网络插件。除了社区大名鼎鼎的Calico、Bifrost网络插件，阿里也开发了一款功能和性能极优的网络插件Hybridnet。

Hybridnet

Hybridnet是专为混合云设计的开源容器网络解决方案，与Kubernetes集成，并被以下PaaS平台使用:

• 阿里云ACK发行版 
• 阿里云AECP 
• 蚂蚁金服 SOFAStack 

Hybridnet 专注于高效的大规模集群、异构基础设施和用户友好性

Github地址

Calico

Calico 是一种广泛采用、久经考验的开源网络和网络安全解决方案，适用于 Kubernetes、虚拟机和裸机工作负载。 Calico 为 Cloud Native 应用程序提供两大服务：

• 工作负载之间的网络连接
• 工作负载之间的网络安全策略

Github地址

Bifrost

Bifrost 是一个可为 Kubernetes 启用 L2 网络的开源解决方案，支持以下特性

• Bifrost 中的网络流量可以通过传统设备进行管理和监控
• 支持macvlan对于service流量的访问

Github地址

通信路径介绍

Overlay方案：意味着将不同主机上的容器用同一个虚拟网络连接起来的跨主机网络

• VXLAN

• VXLAN（Virtual eXtensible Local Area Network，虚拟扩展局域网），是由IETF定义的NVO3（Network Virtualization over Layer 3）标准技术之一，采用L2 over L4（MAC-in-UDP）的报文封装模式，将二层报文用三层协议进行封装，可实现二层网络在三层范围内进行扩展，同时满足数据中心大二层虚拟迁移和多租户的需求

• IPIP

• 基于TUN设备实现 IPIP 隧道，TUN 网络设备能将三层（IP 网络数据包）数据包封装在另外一个三层数据包之中，Linux 原生支持好几种不同的 IPIP 隧道类型，但都依赖于 TUN 网络设备

• ipip: 普通的 IPIP 隧道，就是在报文的基础上再封装成一个 IPv4 报文
  • gre: 通用路由封装（Generic Routing Encapsulation），定义了在任意网络层协议上封装其他网络层协议的机制，所以对于 IPv4 和 IPv6 都适用
  • sit: sit 模式主要用于 IPv4 报文封装 IPv6 报文，即 IPv6 over IPv4
  • isatap: 站内自动隧道寻址协议（Intra-Site Automatic Tunnel Addressing Protocol），类似于 sit 也是用于 IPv6 的隧道封装
  • vti: 即虚拟隧道接口（Virtual Tunnel Interface），是一种 IPsec 隧道技术

• 本文中我们使用的是ipip这种普通的IPIP隧道

Underlay方案：由交换机和路由器等设备组成，借助以太网协议、路由协议和VLAN协议等驱动的网络

• BGP

• 边界网关协议BGP（Border Gateway Protocol）是一种实现自治系统AS（Autonomous System）之间的路由可达，并选择最佳路由的距离矢量路由协议

• Vlan

• VLAN（Virtual Local Area Network）即虚拟局域网，是将一个物理的LAN在逻辑上划分成多个广播域的通信技术。VLAN内的主机间可以直接通信，而VLAN间不能直接通信，从而将广播报文限制在一个VLAN内

网络插件的原理

• calico利用IPIP等隧道技术或者宿主机间建立BGP连接完成容器路由的互相学习解决了跨节点通信的问题。
• hybridnet利用vxlan隧道技术、宿主机间建立BGP连接完成容器路由的互相学习或者ARP代理来解决跨节点通信的问题。
• bifrost通过内核macvlan模块利用交换机vlan的能力来解决容器通信问题

网络插件分类及对比

网络插件分类

网络插件对比

• SNAT: 对数据包的源IP地址进行转化
• podIP：由podIP直接通信
• veth pair：在 Linux 下，可以创建一对 veth pair 的网卡，从一边发送包，另一边就能收到，对于容器流量来说会通过主机侧的veth pair网卡进入主机网络栈，即会过主机的iptables规则后再由物理网卡发出。
• macvlan子接口：macvlan 子接口和原来的宿主机主接口是完全独立的，可以单独配置 MAC 地址和 IP 地址，对外通信时，容器流量不会进入主机网络栈，既不会过主机的iptables规则，只会经过二层由物理网卡发出。

网络插件应用场景

针对数据中心复杂的网络情况，我们要按需求出发去选择相对应的容器网络方案

• 希望对数据中心物理网络较少侵入性，可选择使用隧道方案

• 需支持双栈，则可选hybridnet vxlan方案
• 只支持单栈IPv4，则可选calico IPIP，calico vxlan方案

• 希望数据中心支持并使用BGP

• 宿主机处于同网段内，则可选calico BGP方案（支持双栈）
• 宿主机处于不同网段内，则可选hybridnet bgp方案（支持双栈）

• 对于业务的高性能和低延迟的追求，出现了macvlan，ipvlan l2等方案
• 公有云场景下，可选用terway方案，或者其他ipvlan l3方案，或者隧道方案
• 也有为了满足全场景而开发的方案，如hybridnet、multus等， Multus 一款为支持其他CNI能力的开源容器网络插件

本文我们将对hybridnet vxlan、hybridnet vlan、hybridnet bgp、calico IPIP、calico BGP和基于macvlan改造的bifrost进行pod数据链路上的详细分析

网络插件架构及通信路径

Hybridnet

整体架构

• Hybridnet-daemon： 控制每个节点上的数据平面配置，例如Iptables规则，策略路由等

通信路径

VXLAN模式

同节点通信

Pod1访问Pod2的通信过程

发包过程：

1. Pod1流量通过veth-pair网卡，即从pod1的eth0->主机侧的hybrXXX，进入主机网络栈中
2. 根据目的IP，流量在主机的策略路由匹配到39999路由表，并在39999路由表中匹配到Pod2的路由规则
3. 流量从hybrYYY网卡进入Pod2容器网络栈，完成发包动作

回包过程：

1. Pod2流量通过veth-pair网卡，即从pod2的eth0->主机侧的hybrYYY，进入主机网络栈中
2. 根据目的IP，流量在主机的策略路由匹配到39999路由表，并在39999路由表中匹配到Pod1的路由规则
3. 流量从hybrXXX网卡进入Pod1容器网络栈，完成回包动作

跨节点通信

Pod1访问Pod2的通信过程

发包过程：

1. Pod1流量通过veth-pair网卡，即从pod1的eth0->主机侧的hybrXXX，进入主机网络栈中
2. 根据目的IP，流量在主机的策略路由匹配到40000路由表，并在40000路由表中匹配到Pod2所在网段需要发往eth0.vxlan20网卡的路由规则
3. eth0.vxlan20设备的转发表中记录了对端vtep的mac地址和remoteip的对应关系
4. 流量经过eth0.vxlan20网卡，封装一个UDP的头部
5. 经过查询路由，与本机处于同网段，通过mac地址查询获取到对端物理网卡的mac地址，经由Node1 eth0物理网卡发送
6. 流量从Node2 eth0物理网卡进入，并经过eth0.vxlan20网卡解封一个UDP的头部
7. 根据39999路由表，流量从hybrYYY网卡进入Pod2容器网络栈，完成发包动作

回包过程：

1. Pod2流量通过veth-pair网卡，即从pod2的eth0->主机侧的hybrYYY，进入主机网络栈中
2. 根据目的IP，流量在主机的策略路由匹配到40000路由表，并在40000路由表中匹配到Pod1所在网段需要发往eth0.vxlan20网卡的路由规则
3. eth0.vxlan20设备的转发表中记录了对端vtep的mac地址和remoteip的对应关系
4. 流量经过eth0.vxlan20网卡，封装一个UDP的头部
5. 经过查询路由，与本机处于同网段，通过mac地址查询获取到对端物理网卡的mac地址，经由Node2 eth0物理网卡发送
6. 流量从Node1 eth0物理网卡进入，并经过eth0.vxlan20网卡解封一个UDP的头部
7. 根据39999路由表，流量从hybrXXX网卡进入Pod1容器网络栈，完成回包动作

VLAN模式

同节点通信

Pod1访问Pod2的通信过程

发包过程：

1. Pod1流量通过veth-pair网卡，即从pod1的eth0->主机侧的hybrXXX，进入主机网络栈中
2. 根据目的IP，流量在主机的策略路由匹配到39999路由表，并在39999路由表中匹配到Pod2的路由规则
3. 流量从hybrYYY网卡进入Pod2容器网络栈，完成发包动作

回包过程：

1. Pod2流量通过veth-pair网卡，即从pod2的eth0->主机侧的hybrYYY，进入主机网络栈中
2. 根据目的IP，流量在主机的策略路由匹配到39999路由表，并在39999路由表中匹配到Pod1的路由规则
3. 流量从hybrXXX网卡进入Pod1容器网络栈，完成回包动作

跨节点通信

Pod1访问Pod2的通信过程

发包过程：

1. Pod1流量通过veth-pair网卡，即从pod1的eth0->主机侧的hybrXXX，进入主机网络栈中
2. 根据目的IP，流量在主机的策略路由匹配到10001路由表，并在10001路由表中匹配到Pod2相对应的路由规则
3. 根据路由规则，流量从eth0.20网卡所对应的eth0物理网卡发出，并发往交换机
4. 在交换机上匹配到pod2的MAC地址，所以将流量发往Node2所对应的eth0物理网卡
5. 流量被eth0.20 vlan网卡接收到，并根据39999路由表匹配到的路由，将流量从hybrYYY网卡打入pod2容器网络栈，完成发包动作

回包过程：

1. Pod2流量通过veth-pair网卡，即从pod2的eth0->主机侧的hybrYYY，进入主机网络栈中
2. 根据目的IP，流量在主机的策略路由匹配到10001路由表，并在10001路由表中匹配到Pod1相对应的路由规则
3. 根据路由规则，流量从eth0.20网卡所对应的eth0物理网卡发出，并发往交换机
4. 在交换机上匹配到pod1的MAC地址，所以将流量发往Node1所对应的eth0物理网卡
5. 流量被eth0.20 vlan网卡接收到，并根据39999路由表匹配到的路由，将流量从hybrXXX网卡打入pod1容器网络栈，完成回包动作

BGP模式

同节点通信

Pod1访问Pod2的通信过程

发包过程：

1. Pod1流量通过veth-pair网卡，即从pod1的eth0->主机侧的hybrXXX，进入主机网络栈中
2. 根据目的IP，流量在主机的策略路由匹配到39999路由表，并在39999路由表中匹配到Pod2的路由规则
3. 流量从hybrYYY网卡进入Pod2容器网络栈，完成发包动作

回包过程：

1. Pod2流量通过veth-pair网卡，即从pod2的eth0->主机侧的hybrYYY，进入主机网络栈中
2. 根据目的IP，流量在主机的策略路由匹配到39999路由表，并在39999路由表中匹配到Pod1的路由规则
3. 流量从hybrXXX网卡进入Pod1容器网络栈，完成回包动作

跨节点通信

Pod1访问Pod2的通信过程

发包过程：

1. Pod1流量通过veth-pair网卡，即从pod1的eth0->主机侧的hybrXXX，进入主机网络栈中
2. 根据目的IP，流量在主机的策略路由匹配到10001路由表，并在10001路由表中匹配到默认路由
3. 根据路由，将流量发往10.0.0.1所对应的交换机
4. 在交换机上匹配到pod2所对应的特定路由，将流量发往Node2 eth0物理网卡
5. 流量从hybrYYY网卡进入Pod2容器网络栈，完成发包动作

回包过程：

1. Pod2流量通过veth-pair网卡，即从pod2的eth0->主机侧的hybrYYY，进入主机网络栈中
2. 根据目的IP，流量在主机的策略路由匹配到10001路由表，并在10001路由表中匹配到默认路由
3. 根据路由，将流量发往10.0.0.1所对应的交换机
4. 在交换机上匹配到pod1所对应的特定路由，将流量发往Node1 eth0物理网卡
5. 流量从hybrXXX网卡进入Pod1容器网络栈，完成回包动作

Calico

基本概念：

• 纯三层的数据中心网络方案
• 利用Linux Kernel使得宿主机实现vRouter来负责数据转发
• vRouter通过BGP协议传播路由信息 
• 基于iptables还提供了丰富而灵活的网络策略规则

整体架构

• Felix：运行在每个容器宿主节点上，主要负责配置路由、ACL等信息来确保容器的联通状态
• Brid：把 Felix 写入 Kernel 的路由信息分发到 Calico 网络，保证容器间的通信有效性
• etcd：分布式的 Key/Value 存储，负责网络元数据一致性，确保 Calico 网络状态的准确性
• RR：路由反射器，默认 Calico 工作在 node-mesh 模式，所有节点互相连接， node-mesh 模式在小规模部署时工作是没有问题的，当大规模部署时，连接数会非常大，消耗过多资源，利用 BGP RR ，可以避免这种情况的发生，通过一个或者多个 BGP RR 来完成集中式的路由分发，减少对网络资源的消耗以及提高 Calico 工作效率、稳定性

通信路径

IPIP模式

同节点通信

Pod1访问Pod2的通信过程

发包过程：

1. Pod1流量通过veth-pair网卡，即从pod1的eth0->主机侧的caliXXX，进入主机网络栈中
2. 根据目的IP，流量在路由表中匹配到Pod2的路由规则
3. 流量从caliYYY网卡进入Pod2容器网络栈，完成发包动作

回包过程：

1. Pod2流量通过veth-pair网卡，即从pod2的eth0->主机侧的caliYYY，进入主机网络栈中
2. 根据目的IP，流量在路由表中匹配到Pod1的路由规则
3. 流量从caliXXX网卡进入Pod1容器网络栈，完成回包动作

跨节点通信

Pod1访问Pod2的通信过程

发包过程：

1. Pod1流量通过veth-pair网卡，即从pod1的eth0->主机侧的caliXXX，进入主机网络栈中

1. src: pod1IP
2. dst: pod2IP

1. 根据目的IP，流量在路由表中匹配到将流量转发到tunl0网卡上的路由规则

1. src: pod1IP
2. dst: pod2IP

1. 流量从tunl0进行IPIP封装（即封装一个IP头部），通过eth0物理网卡发出

1. src: Node1IP
2. dst: Node2IP

1. 流量从Node2的eth0网卡进入Node2的主机网络栈

1. src: Node1IP
2. dst: Node2IP

1. 流量进入tunl0进行IPIP解包

1. src: pod1IP
2. dst: pod2IP

1. 流量从caliYYY网卡进入Pod2容器网络栈，完成发包动作

1. src: pod1IP
2. dst: pod2IP

回包过程：

1. Pod2流量通过veth-pair网卡，即从pod2的eth0->主机侧的caliYYY，进入主机网络栈中

1. src: pod2IP
2. dst: pod1IP

1. 根据目的IP，流量在路由表中匹配到将流量转发到tunl0网卡上的路由规则

1. src: pod2IP
2. dst: pod1IP

1. 流量从tunl0进行IPIP封装（即封装一个IP头部），通过eth0物理网卡发出

1. src: Node2IP
2. dst: Node1IP

1. 流量从Node1的eth0网卡进入Node1的主机网络栈

1. src: Node2IP
2. dst: Node1IP

1. 流量进入tunl0进行IPIP解包

1. src: pod2IP
2. dst: pod1IP

1. 流量从caliXXX网卡进入Pod1容器网络栈，完成回包动作

1. src: pod2IP
2. dst: pod1IP

BGP模式

同节点通信

Pod1访问Pod2的通信过程

发包过程：

1. Pod1流量通过veth-pair网卡，即从pod1的eth0->主机侧的caliXXX，进入主机网络栈中
2. 根据目的IP，流量在路由表中匹配到Pod2的路由规则
3. 流量从caliYYY网卡进入Pod2容器网络栈，完成发包动作

回包过程：

1. Pod2流量通过veth-pair网卡，即从pod2的eth0->主机侧的caliYYY，进入主机网络栈中
2. 根据目的IP，流量在路由表中匹配到Pod1的路由规则
3. 流量从caliXXX网卡进入Pod1容器网络栈，完成回包动作

跨节点通信

Pod1访问Pod2的通信过程

发包过程：

1. Pod1流量通过veth-pair网卡，即从pod1的eth0->主机侧的caliXXX，进入主机网络栈中
2. 根据目的IP，流量在路由表中匹配到Pod2相对应网段的路由规则，并从Node1 eth0物理网卡发出
3. 流量从Node2 eth0物理网卡进入，并从caliYYY网卡进入Pod2容器网络栈，完成发包动作

回包过程：

1. Pod2流量通过veth-pair网卡，即从pod2的eth0->主机侧的caliYYY，进入主机网络栈中
2. 根据目的IP，流量在路由表中匹配到Pod1相对应网段的路由规则，并从Node2 eth0物理网卡发出
3. 流量从Node1 eth0物理网卡进入，并从caliXXX网卡进入Pod1容器网络栈，完成回包动作

Bifrost

整体架构

• veth0-bifrXXX：bifrost对于macvlan实现service访问的一套解决方案，通过veth-pair网卡完成在主机网络栈中的kube-proxy + iptables对于服务流量转化为对pod的访问
• eth0：容器内的eth0网卡为主机vlan子网卡对应的macvlan网卡

通信路径

MACVLAN模式

同节点同vlan通信

Pod1访问Pod2的通信过程

发包过程：

1. Pod1流量通过macvlan网卡，即pod1的eth0走二层网络进入eth0-10 vlan子网卡
2. 由于macvlan开启bridge模式，能够匹配到pod2 的MAC地址
3. 流量从eth0-10 vlan子网卡进入Pod2容器网络栈，完成发包动作

回包过程：

1. Pod2流量通过macvlan网卡，即pod2的eth0走二层网络进入eth0-10 vlan子网卡
2. 由于macvlan开启bridge模式，能够匹配到pod1 的MAC地址
3. 流量从eth0-10 vlan子网卡进入Pod1容器网络栈，完成回包动作

同节点跨vlan通信

Pod1访问Pod2的通信过程

发包过程：

1. Pod1流量通过macvlan网卡，即pod1的eth0走默认路由（网关为5.0.0.1）进入eth0-5 vlan子网卡
2. 由于在eth0-5 上找到网关5.0.0.1的MAC地址，所以将流量从eth0物理网卡出打到交换机上
3. 流量在交换机上匹配到了pod2的MAC地址
4. 流量进入Pod2所在宿主机的物理网卡，并进入相对应的eth0-10 vlan子网卡
5. 流量从eth0-10 vlan子网卡进入Pod2容器网络栈，完成发包动作

回包过程：

1. Pod2流量通过macvlan网卡，即pod2的eth0走默认路由（网关为10.0.0.1）进入eth0-10 vlan子网卡
2. 由于在eth0-10上找到网关10.0.0.1的MAC地址，所以将流量从eth0物理网卡出打到交换机上
3. 流量在交换机上匹配到了pod1的MAC地址
4. 流量进入Pod1所在宿主机的物理网卡，并进入相对应的eth0-5 vlan子网卡
5. 流量从eth0-5 vlan子网卡进入Pod1容器网络栈，完成回包动作

跨节点通信

Pod1访问Pod2的通信过程

发包过程：

1. Pod1流量通过macvlan网卡，即pod1的eth0走默认路由（网关为5.0.0.1）进入eth0-5 vlan子网卡
2. 由于在eth0-5 上找到网关5.0.0.1的MAC地址，所以将流量从eth0物理网卡出打到交换机上
3. 流量在交换机上匹配到了pod2的MAC地址
4. 流量进入Pod2所在宿主机的物理网卡，并进入相对应的eth0-10 vlan子网卡
5. 流量从eth0-10 vlan子网卡进入Pod2容器网络栈，完成发包动作

回包过程：

1. Pod2流量通过macvlan网卡，即pod2的eth0走默认路由（网关为10.0.0.1）进入eth0-10 vlan子网卡
2. 由于在eth0-10上找到网关10.0.0.1的MAC地址，所以将流量从eth0物理网卡出打到交换机上
3. 流量在交换机上匹配到了pod1的MAC地址
4. 流量进入Pod1所在宿主机的物理网卡，并进入相对应的eth0-5 vlan子网卡
5. 流量从eth0-5 vlan子网卡进入Pod1容器网络栈，完成回包动作

面临的问题及未来发展

IPv4/IPv6双栈

背景

IP作为互联网最基础的要素，是为计算机网络相互连接进行通信而设计的协议，正是因为有了IP协议，因特网才得以迅速发展成为世界上最大的、开放的计算机通信网络。IP协议随着互联网的发展，产生了IPv4和IPv6两种协议：

• IPv4

• IPv4是互联网协议第四版，是计算机网络使用的数据报传输机制，此协议是第一个被广泛部署的IP协议。每一个连接Internet的设备（不管是交换机、PC还是其他设备），都会为其分配一个唯一的IP地址，如192.149.252.76，如下图所示，IPv4使用32位（4字节）地址，大约可以存储43亿个地址，但随着越来越多的用户接入到Internet，全球IPv4地址已于2019年11月已全数耗尽。这也是后续互联网工程任务组（IEIF）提出IPv6的原因之一

• IPv6

• IPv6是由IEIF提出的互联网协议第六版，用来替代IPv4的下一代协议，它的提出不仅解决了网络地址资源匮乏问题，也解决了多种接入设备接入互联网的障碍。IPv6的地址长度为128位，可支持340多万亿个地址。如下图，3ffe:1900:fe21:4545:0000:0000:0000:0000，这是一个IPv6地址，IPv6地址通常分为8组，4个十六进制数为一组，每组之间用冒号分隔

在IPv4占主流，IPv6还未兴起时，主要面临的问题：

1. IPv4地址数量已经不再满足需求，需要IPv6地址进行扩展
2. 随着国内下一代互联网发展政策的明确，客户数据中心需要使用IPv6来符合更严格的监管

现状

calico IPIP不支持IPv6的原因:

• ipip是普通的 IPIP 隧道，就是在报文的基础上再封装成一个 IPv4 报文，所以不支持IPv6的封包

多网卡（多通信机制）

背景

通常情况下在k8s中，一个Pod只有一个接口，即单网卡，用于集群网络中pod和pod通信 而Pod需要和异构网络进行通信时，可选择在Pod中建立多个接口，即多网卡

目前的问题：

1. 部分客户真实IP资源紧张，导致无法全部使用underlay方案
2. 客户希望把UDP网络和TCP网络分开，导致如基于TCP协议的网络模型无法独立存在于UDP网络中

现状

目前实现多网卡的方案，大致两种：

• 在单一CNI调用IPAM时，通过CNI config配置生成相对应的网卡并分配合适的IP资源
• 通过元CNI依次调用各个CNI来完成相对应的网卡并分配合适的IP资源，如multus方案

网络流量管控

背景

通常在数据中心中，我们将其网络流量分为两种类型，一种是数据中心外部用户和内部服务器之间交互的流量，这样的流量称作南北向流量或者纵向流量；另外一种就是数据中心内部服务器之间交互的流量，也叫东西向流量或者横向流量。

那么在容器云范畴内，我们将东西向流量定义为集群内宿主机和容器、容器间或宿主机间的流量，南北向流量为容器云外部与容器云内部之间交互的流量。

目前的问题：

1. 传统防火墙在容器云的东西向场景下，难以起到流量管控，需要提供服务间或容器间流量管控的能力

现状

参考资料

calico vxlan ipv4 overlay组网跨主机通信分析

Qunar容器平台网络之道：Calico

最好的vxlan介绍

揭秘 IPIP 隧道

BGP基础知识

VLAN基础知识

Overlay和Underlay网络协议区别及概述讲解 

东西向流量牵引方案小结

容器网络接口（CNI）

K8s 网络之深入理解 CNI

​