超全面的 Kubernetes 容器网络技能，运维看后都说好
-
pod 无论运行在任何节点都可以互相直接通信，而不需要借助 NAT 地址转换实现。 -
node 与 pod 可以互相通信，在不限制的前提下，pod 可以访问任意网络。 -
pod 拥有独立的网络栈，pod 看到自己的地址和外部看见的地址应该是一样的，并且同个 pod 内所有的容器共享同个网络栈。
容器网络基础
一个 Linux 容器的网络栈是被隔离在它自己的 Network Namespace中，Network Namespace 包括了：网卡（Network Interface），回环设备（Lookback Device），路由表（Routing Table）和 iptables 规则，对于服务进程来讲这些就构建了它发起请求和相应的基本环境。
而要实现一个容器网络，离不开以下 Linux 网络功能：
-
网络命名空间：将独立的网络协议栈隔离到不同的命令空间中，彼此间无法通信。 -
Veth Pair：Veth设备对的引入是为了实现在不同网络命名空间的通信,总是以两张虚拟网卡（veth peer）的形式成对出现的。并且，从其中一端发出的数据，总是能在另外一端收到。 -
Iptables/Netfilter：Netfilter 负责在内核中执行各种挂接的规则(过滤、修改、丢弃等)，运行在内核中；Iptables 模式是在用户模式下运行的进程，负责协助维护内核中 Netfilter 的各种规则表；通过二者的配合来实现整个 Linux 网络协议栈中灵活的数据包处理机制 -
网桥：网桥是一个二层网络虚拟设备,类似交换机,主要功能是通过学习而来的Mac地址将数据帧转发到网桥的不同端口上。 -
路由：Linux系统包含一个完整的路由功能，当IP层在处理数据发送或转发的时候，会使用路由表来决定发往哪里
在容器中，以上的实现是通过 docker0 网桥，凡是连接到 docker0 的容器，就可以通过它来进行通信。要想容器能够连接到 docker0 网桥，我们也需要类似网线的虚拟设备Veth Pair 来把容器连接到网桥上。
veth20b3dac，并且可以通过 brctl 查看网桥信息看到这张网卡是在 docker0 上。
172.17.0.3时，会匹配到我们的路由表第二条规则，网关为0.0.0.0，这就意味着是一条直连路由，通过二层转发到目的地。
要通过二层网络到达172.17.0.3，我们需要知道它的 Mac 地址，此时就需要第一个容器发送一个ARP广播，来通过IP地址查找Mac。
此时 Veth peer 另外一段是 docker0 网桥，它会广播到所有连接它的 veth peer 虚拟网卡去，然后正确的虚拟网卡收到后会响应这个ARP报文，然后网桥再回给第一个容器。
跨主机网络通信
它是 K8s 中标准的一个调用网络实现的接口，kubelet通过这个API来调用不同的网络插件以实现不同的网络配置，实现了这个接口的就是CNI插件，它实现了一系列的CNI API接口。目前已经有的包括flannel、calico、weave、contiv等等。
实际上 CNI 的容器网络通信流程跟前面的基础网络一样，只是CNI维护了一个单独的网桥来代替 docker0。这个网桥的名字就叫作：CNI 网桥，它在宿主机上的设备名称默认是：cni0。
cni的设计思想，就是：Kubernetes 在启动 Infra 容器之后，就可以直接调用 CNI 网络插件，为这个 Infra 容器的 Network Namespace，配置符合预期的网络栈。
CNI 插件三种网络实现模式：
-
overlay 模式是基于隧道技术实现的，整个容器网络和主机网络独立，容器之间跨主机通信时将整个容器网络封装到底层网络中，然后到达目标机器后再解封装传递到目标容器。不依赖与底层网络的实现。实现的插件有flannel（UDP、vxlan）、calico（IPIP）等等 -
三层路由模式中容器和主机也属于不通的网段，他们容器互通主要是基于路由表打通，无需在主机之间建立隧道封包。但是限制条件必须依赖大二层同个局域网内。实现的插件有flannel（host-gw）、calico（BGP）等等 -
underlay网络是底层网络，负责互联互通。容器网络和主机网络依然分属不同的网段，但是彼此处于同一层网络，处于相同的地位。整个网络三层互通，没有大二层的限制，但是需要强依赖底层网络的实现支持.实现的插件有calico（BGP）等等
我们看下路由模式的一种实现 flannel Host-gw：
如图可以看到当 node1上container-1 要发数据给 node2 上的 container2 时，会匹配到如下的路由表规则：
表示前往目标网段 10.244.1.0/24 的 IP 包，需要经过本机 eth0 出去发往的下一跳ip地址为10.168.0.3（node2）。然后到达 10.168.0.3 以后再通过路由表转发 cni 网桥，进而进入到 container2。
这种网络模式最大的好处就是避免了额外的封包和解包带来的网络性能损耗。缺点我们也能看见主要就是容器ip包通过下一跳出去时，必须要二层通信封装成数据帧发送到下一跳。如果不在同个二层局域网，那么就要交给三层网关，而此时网关是不知道目标容器网络的（也可以静态在每个网关配置pod网段路由）。所以 flannel host-gw 必须要求集群宿主机是二层互通的。
而为了解决二层互通的限制性，calico提供的网络方案就可以更好的实现，calico 大三层网络模式与flannel 提供的类似，也会在每台宿主机添加如下格式的路由规则：
BGP 全称是 Border Gateway Protocol边界网关协议,linxu原生支持的、专门用于在大规模数据中心为不同的自治系统之间传递路由信息。只要记住BGP简单理解其实就是实现大规模网络中节点路由信息同步共享的一种协议。而BGP这种协议就能代替flannel 维护主机路由表功能。
-
calico cni插件: 主要负责与kubernetes对接，供kubelet调用使用。 -
felix: 负责维护宿主机上的路由规则、FIB转发信息库等。 -
BIRD: 负责分发路由规则，类似路由器。 -
confd: 配置管理组件。
有了这样的veth pair设备以后，容器发出的IP包就会通过veth pair设备到达宿主机，然后宿主机根据路有规则的下一条地址，发送给正确的网关(10.100.1.3)，然后到达目标宿主机，在到达目标容器。
这些路由规则都是felix维护配置的，而路由信息则是calico bird组件基于BGP分发而来。calico实际上是将集群里所有的节点都当做边界路由器来处理,他们一起组成了一个全互联的网络，彼此之间通过BGP交换路由，这些节点我们叫做BGP Peer。
需要注意的是calico 维护网络的默认模式是 node-to-node mesh ,这种模式下，每台宿主机的BGP client都会跟集群所有的节点BGP client进行通信交换路由。这样一来，随着节点规模数量N的增加，连接会以N的2次方增长，会集群网络本身带来巨大压力。
所以一般这种模式推荐的集群规模在50节点左右,超过50节点推荐使用另外一种RR（Router Reflector）模式，这种模式下，calico 可以指定几个节点作为RR，他们负责跟所有节点 BGP client 建立通信来学习集群所有的路由，其他节点只需要跟RR节点交换路由即可。这样大大降低了连接数量，同时为了集群网络稳定性，建议RR>=2.
以上的工作原理依然是在二层通信，当我们有两台宿主机，一台是10.100.0.2/24，节点上容器网络是10.92.204.0/24;另外一台是10.100.1.2/24,节点上容器网络是10.92.203.0/24,此时两台机器因为不在同个二层所以需要三层路由通信，这时calico就会在节点上生成如下路由表：
这时候问题就来了，因为10.100.1.2跟我们10.100.0.2不在同个子网，是不能二层通信的。这之后就需要使用Calico IPIP模式，当宿主机不在同个二层网络时就是用overlay网络封装以后再发出去。如下图所示：
IPIP模式下在非二层通信时，calico 会在node节点添加如下路由规则:
