在 Kubernetes 中要保证容器之间网络互通，网络至关重要。而 Kubernetes 本身并没有自己实现容器网络，而是通过插件化的方式自由接入进来。在容器网络接入进来需要满足如下基本原则：
1、pod 无论运行在任何节点都可以互相直接通信，而不需要借助 NAT 地址转换实现。
2、node 与 pod 可以互相通信，在不限制的前提下，pod 可以访问任意网络。
3、pod 拥有独立的网络栈，pod 看到自己的地址和外部看见的地址应该是一样的，并且同个 pod 内所有的容器共享同个网络栈。
一、容器网络基础
一个 Linux 容器的网络栈是被隔离在它自己的 Network Namespace中，Network Namespace 包括了：
1、网卡（Network Interface）
2、回环设备（Lookback Device）
3、路由表（Routing Table）和 iptables 规则
对于服务进程来讲这些就构建了它发起请求和相应的基本环境。
而要实现一个容器网络，离不开以下 Linux 网络功能：
1、网络命名空间：将独立的网络协议栈隔离到不同的命令空间中，彼此间无法通信。
2、Veth Pair：Veth设备对的引入是为了实现在不同网络命名空间的通信,总是以两张虚拟网卡（veth peer）的形式成对出现的。并且，从其中一端发出的数据，总是能在另外一端收到。
- 3、Iptables/Netfilter：Netfilter 负责在内核中执行各种挂接的规则(过滤、修改、丢弃等)，运行在内核中；Iptables 模式是在用户模式下运行的进程，负责协助维护内核中 Netfilter 的各种规则表；通过二者的配合来实现整个 Linux 网络协议栈中灵活的数据包处理机制。
- 4、网桥：网桥是一个二层网络虚拟设备,类似交换机,主要功能是通过学习而来的Mac地址将数据帧转发到网桥的不同端口上。
- 5、
- 路由：Linux系统包含一个完整的路由功能，当IP层在处理数据发送或转发的时候，会使用路由表来决定发往哪里。
基于以上的基础，同宿主机的容器时间如何通信呢？
我们可以简单把他们理解成两台主机，主机之间通过网线连接起来，如果要多台主机通信，我们通过交换机就可以实现彼此互通，在 Linux 中，我们可以通过网桥来转发数据。
在容器中，以上的实现是通过 docker0 网桥，凡是连接到 docker0 的容器，就可以通过它来进行通信。要想容器能够连接到 docker0 网桥，我们也需要类似网线的虚拟设备Veth Pair 来把容器连接到网桥上。
启动一个容器：
[root@localhost yum.repos.d]# docker pull alpine [root@localhost yum.repos.d]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE alpine latest d4ff818577bc 2 weeks ago 5.6MB [root@localhost yum.repos.d]# docker run -d --rm --name myalpine alpine /bin/sh 84a970cba9c1f8faaef74fb9251762fedb51f1d97803a35147b0cd64c75f56a8 [root@localhost yum.repos.d]#
进入容器，查看网络
[root@localhost yum.repos.d]# docker run -it --name myalpine alpine /bin/sh / # ifconfig eth0 Link encap:Ethernet HWaddr 02:42:AC:11:00:02 inet addr:172.17.0.2 Bcast:172.17.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:656 (656.0 B) TX bytes:0 (0.0 B) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) / #
其中的eth0网卡就是veth peer其中一端的虚拟网卡。
/ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.17.0.1 0.0.0.0 UG 0 0 0 eth0 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 / #
通过 route -n 查看容器中的路由表，eth0 也正是默认路由出口。所有对172.17.0.0/16 网段的请求都会从 eth0 出去。
再来看 Veth peer 的另一端，查看宿主机的网络设备：
[root@localhost ~]# ifconfig docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255 inet6 fe80::42:3ff:feec:6418 prefixlen 64 scopeid 0x20<link> ether 02:42:03:ec:64:18 txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 2 bytes 176 (176.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 em1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.28.5.124 netmask 255.255.255.128 broadcast 172.28.5.127 inet6 fe80::dc63:56e4:7a1e:4231 prefixlen 64 scopeid 0x20<link> ether 50:9a:4c:8b:8b:6a txqueuelen 1000 (Ethernet) RX packets 15582489 bytes 2655206863 (2.4 GiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1371098 bytes 603212280 (575.2 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 16 em2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ether 50:9a:4c:8b:8b:6b txqueuelen 1000 (Ethernet) RX packets 13955739 bytes 951445164 (907.3 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 17 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 1239483 bytes 245838215 (234.4 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1239483 bytes 245838215 (234.4 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 veth9a0aa9e: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet6 fe80::906d:13ff:fe1f:a825 prefixlen 64 scopeid 0x20<link> ether 92:6d:13:1f:a8:25 txqueuelen 0 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 8 bytes 656 (656.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@localhost ~]#
可以看到容器的网卡eth0正好对应宿主机上的veth9a0aa9e虚拟网卡，eth0的RX：656，veth9a0aa9e的TX:656
在宿主机上查看网桥信息,首先安装网桥管理工具brctl
[root@localhost ~]# yum install -y bridge-utils
查看网桥
[root@localhost ~]# brctl show bridge name bridge id STP enabled interfaces docker0 8000.024203ec6418 no veth9a0aa9e [root@localhost ~]#
可以看到veth9a0aa9e虚拟网卡是在docker0网桥设备上。
我们再启动一个容器
[root@localhost ~]# docker run -it --name myalpine-1 alpine /bin/sh
然后在第一个容器中ping第二个容器的IP
/ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.17.0.1 0.0.0.0 UG 0 0 0 eth0 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 / # ping 172.17.0.3 PING 172.17.0.3 (172.17.0.3): 56 data bytes 64 bytes from 172.17.0.3: seq=0 ttl=64 time=0.126 ms 64 bytes from 172.17.0.3: seq=1 ttl=64 time=0.072 ms 64 bytes from 172.17.0.3: seq=2 ttl=64 time=0.077 ms ^C --- 172.17.0.3 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.072/0.091/0.126 ms / #
能够ping通，这是因为在路由表中目标网段：172.17.0.0的地址的网关是0.0.0.0，表示是一条直连路由，不走网关， 直接2层转发到目的地，也就是通过docker0网桥转发。
要通过二层网络到达172.17.0.3，我们需要知道它的 Mac 地址，此时就需要第一个容器发送一个ARP广播，来通过IP地址查找Mac。此时 Veth peer 另外一段是 docker0 网桥，它会广播到所有连接它的 veth peer 虚拟网卡去，然后正确的虚拟网卡收到后会响应这个ARP报文，然后网桥再回给第一个容器。
同宿主机不同容器通过 docker0 通信，如下图所示：
默认情况下，通过 network namespace 限制的容器进程，本质上是通过Veth peer设备和宿主机网桥的方式，实现了不同 network namespace 的数据交换。与之类似地，当你在一台宿主机上，访问该宿主机上的容器的 IP 地址时，这个请求的数据包，也是先根据路由规则到达 docker0 网桥，然后被转发到对应的 Veth Pair 设备，最后出现在容器里。
二、跨主机网络通信
在 Docker 的默认配置下，不同宿主机上的容器通过 IP 地址进行互相访问是根本做不到的。为了解决这个问题，社区中出现了很多网络方案。同时 K8s 为了更好的控制网络的接入，推出了 CNI 即容器网络的 API 接口。它是 K8s 中标准的一个调用网络实现的接口，kubelet通过这个API来调用不同的网络插件以实现不同的网络配置，实现了这个接口的就是CNI插件，它实现了一系列的CNI API接口。目前已经有的包括flannel、calico、weave、contiv等等。实际上 CNI 的容器网络通信流程跟前面的基础网络一样，只是CNI维护了一个单独的网桥来代替 docker0。这个网桥的名字就叫作：CNI 网桥，它在宿主机上的设备名称默认是：cni0。
cni的设计思想，就是：Kubernetes 在启动 Infra 容器之后，就可以直接调用 CNI 网络插件，为这个 Infra 容器的 Network Namespace，配置符合预期的网络栈。
CNI 插件三种网络实现模式：
1、overlay 模式：是基于隧道技术实现的，整个容器网络和主机网络独立，容器之间跨主机通信时将整个容器网络封装到底层网络中，然后到达目标机器后再解封装传递到目标容器。不依赖与底层网络的实现。实现的插件有flannel（UDP、vxlan）、calico（IPIP）等等
2、三层路由模式：容器和主机也属于不通的网段，他们容器互通主要是基于路由表打通，无需在主机之间建立隧道封包。但是限制条件必须依赖大二层同个局域网内。实现的插件有flannel（host-gw）、calico（BGP）等等
3、underlay网络：是底层网络，负责互联互通。容器网络和主机网络依然分属不同的网段，但是彼此处于同一层网络，处于相同的地位。整个网络三层互通，没有大二层的限制，但是需要强依赖底层网络的实现支持.实现的插件有calico（BGP）等等。
我们看下路由模式的一种实现 flannel Host-gw：
如图可以看到当 node1上container-1 要发数据给 node2 上的 container2 时，会匹配到如下的路由表规则：
10.244.1.0/24 via 10.168.0.3 dev eth0
表示前往目标网段 10.244.1.0/24 的 IP 包，需要经过本机 eth0 出去发往的下一跳ip地址为10.168.0.3（node2）。到达 10.168.0.3 以后，匹配到如下路由表规则：
10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1
再通过路由表转发 cni 网桥，进而进入到 container2。
以上可以看到 host-gw 工作原理，其实就是在每个 node 节点配置到每个 pod 网段的下一跳为pod网段所在的 node 节点 IP，pod 网段和 node 节点 ip 的映射关系，flannel 保存在etcd或者k8s中。flannel 只需要 watch 这些数据的变化来动态更新路由表即可。
这种网络模式最大的好处就是避免了额外的封包和解包带来的网络性能损耗。缺点我们也能看见主要就是容器ip包通过下一跳出去时，必须要二层通信封装成数据帧发送到下一跳。如果不在同个二层局域网，那么就要交给三层网关，而此时网关是不知道目标容器网络的（也可以静态在每个网关配置pod网段路由）。所以 flannel host-gw 必须要求集群宿主机是二层互通的。
而为了解决二层互通的限制性，calico提供的网络方案就可以更好的实现，calico 大三层网络模式与flannel 提供的类似，也会在每台宿主机添加如下格式的路由规则：
<目标容器IP网段> via <网关的IP地址> dev eth0
其中网关的 IP 地址不同场景有不同的意思,如果宿主机是二层可达那么就是目的容器所在的宿主机的 IP 地址，如果是三层不同局域网那么就是本机宿主机的网关IP（交换机或者路由器地址）。
不同于 flannel 通过 k8s 或者 etcd 存储的数据来维护本机路由信息的做法，calico是通过BGP 动态路由协议来分发整个集群路由信息。
BGP 全称是 Border Gateway Protocol边界网关协议,linxu原生支持的、专门用于在大规模数据中心为不同的自治系统之间传递路由信息。只要记住BGP简单理解其实就是实现大规模网络中节点路由信息同步共享的一种协议。而BGP这种协议就能代替flannel 维护主机路由表功能。
calico 主要由三个部分组成：
1、calico cni插件：主要负责与kubernetes对接，供kubelet调用使用。
2、felix： 负责维护宿主机上的路由规则、FIB转发信息库等。
3、BIRD： 负责分发路由规则，类似路由器。
4、confd： 配置管理组件。
除此之外，calico 还和 flannel host-gw 不同之处在于，它不会创建网桥设备，而是通过路由表来维护每个pod的通信，如下图所示：
可以看到 calico 的 cni 插件会为每个容器设置一个 veth pair 设备，然后把另一端接入到宿主机网络空间，由于没有网桥，cni 插件还需要在宿主机上为每个容器的 veth pair设备配置一条路由规则，用于接收传入的IP包，路由规则如下：
10.92.77.163 dev cali93a8a799fe1 scope link
以上表示发送10.92.77.163的IP包应该发给cali93a8a799fe1设备，然后到达另外一段容器中。
有了这样的veth pair设备以后，容器发出的IP包就会通过veth pair设备到达宿主机，然后宿主机根据路由规则的下一条地址，发送给正确的网关(10.100.1.3)，然后到达目标宿主机，在到达目标容器。
10.92.160.0/23 via 10.106.65.2 dev bond0 proto bird
这些路由规则都是felix维护配置的，而路由信息则是calico bird组件基于BGP分发而来。calico实际上是将集群里所有的节点都当做边界路由器来处理,他们一起组成了一个全互联的网络，彼此之间通过BGP交换路由，这些节点我们叫做BGP Peer。
需要注意的是calico 维护网络的默认模式是 node-to-node mesh ,这种模式下，每台宿主机的BGP client都会跟集群所有的节点BGP client进行通信交换路由。这样一来，随着节点规模数量N的增加，连接会以N的2次方增长，会集群网络本身带来巨大压力。