Calico

Calico 支持网络策略，Calico 是纯三层虚拟网络方案，Calico 在每一个计算节点利用 Linux Kernel 实现了一个高效的 vRouter 来负责数据转发，而每个 vRouter 通过 BGP 协议负责把自己上运行的 workload 的路由信息像整个 Calico 网络内传播——小规模部署可以直接互联，大规模下可通过指定的 BGP route reflector 来完成。这样保证最终所有的 workload 之间的数据流量都是通过 IP 路由的方式完成互联的。Calico 节点组网可以直接利用数据中心的网络结构(无论是 L2 或者 L3)，不需要额外的 NAT，隧道或者 Overlay Network。Calico 基于 iptables 还提供了丰富而灵活的 Network Policy，保证通过各个节点上的 ACLs 来提供 Workload 的多租户隔离、安全组以及其他可达性限制等功能

查看node路由

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    0      0        0 eth0
10.42.0.0       192.168.6.139   255.255.255.0   UG    0      0        0 tunl0
10.42.1.0       0.0.0.0         255.255.255.0   U     0      0        0 *
10.42.1.40      0.0.0.0         255.255.255.255 UH    0      0        0 calia7465c6c10d
10.42.1.41      0.0.0.0         255.255.255.255 UH    0      0        0 cali2f5015abade
10.42.1.42      0.0.0.0         255.255.255.255 UH    0      0        0 cali6fa73a0315b
10.42.2.0       192.168.4.138   255.255.255.0   UG    0      0        0 tunl0
10.42.3.0       192.168.6.140   255.255.255.0   UG    0      0        0 tunl0
10.42.4.0       192.168.4.139   255.255.255.0   UG    0      0        0 tunl0
10.42.5.0       192.168.3.138   255.255.255.0   UG    0      0        0 tunl0
10.42.6.0       192.168.4.123   255.255.255.0   UG    0      0        0 tunl0

Calico只要组件

Calico 主要由 Felix、etcd、BGP client 以及 BGP Route Reflector 组成

1. Felix，Calico Agent，跑在每台需要运行 Workload 的节点上，主要负责配置路由及 ACLs 等信息来确保 Endpoint 的连通状态；
2. etcd，分布式键值存储，主要负责网络元数据一致性，确保 Calico 网络状态的准确性；
3. BGP Client(BIRD), 主要负责把 Felix 写入 Kernel 的路由信息分发到当前 Calico 网络，确保 Workload 间的通信的有效性；
4. BGP Route Reflector(BIRD)，大规模部署时使用，摒弃所有节点互联的 mesh 模式，通过一个或者多个 BGP Route Reflector 来完成集中式的路由分发。
5. calico/calico-ipam，主要用作 Kubernetes 的 CNI 插件

Calico CLI安装

下载地址：https://github.com/projectcalico/calicoctl/releases

wget https://github.com/projectcalico/calicoctl/releases/download/v3.1.1/calicoctl -O /usr/bin/calicoctl
chmod +x /usr/bin/calicoctl

calicoctl 配置文件 将以下内容写入文件/etc/calico/calicoctl.cfg:

apiVersion: projectcalico.org/v3
kind: CalicoAPIConfig
metadata:
spec:
  etcdEndpoints: https://192.168.4.138:2379
  etcdKeyFile: /etc/kubernetes/ssl/kubernetes-key.pem
  etcdCertFile: /etc/kubernetes/ssl/kubernetes.pem
  etcdCACertFile: /etc/kubernetes/ssl/ca.pem

或者当使用API Server作为数据存储时，需要配置认证 DATASTORE_TYPE=kubernetes KUBECONFIG=~/.kube/config calicoctl get nodes 也可以将认证信息保存于配置文件中，默认配置文件为 /etc/calico/calicoctl.cfg

apiVersion: projectcalico.org/v3
kind: CalicoAPIConfig
metadata:
spec:
  datastoreType: "kubernetes"
  kubeconfig: "path/to/.kube/config"

calicoctl node status

Flannel

Flannel通过给每台宿主机分配一个子网的方式为容器提供虚拟网络，它基于Linux TUN/TAP，使用UDP封装IP包来创建overlay网络，并借助etcd维护网络的分配情况。Flannel 目前支持三种后端的实现：UDP、VXLAN、host-gw 三种方式，flannel 网络插件目前不支持 NetworkPolicy ，支持Network Policy的插件包括：Calico、Weave 和 kube-router 等项目；如需要 Flannel支持 NetworkPolicy ，就需要再额外安装一个网络插件，比如 Calico+Flanne(Canel)，来负责NetworkPolicy。

Flannel  UDP模式

上面就是基于 Flannel UDP 模式的跨主通信的基本流程了，从上面的整个流程来看，Flanneld 主要有两方面的功能：• UDP 封包解包 • 节点上的路由表的动态更新 我们可以明显看出来数据包是通过 tun 设备从内核态复制到用户态的应用中的，然后再通过用户态复制到内核态，仅一次网络传输就进行了两次用户态和内核态的切换，显然这种效率是不会很高的，由于低效率所以这种方式基本上不使用，要提高效率最简单的方式就是把封包解包这些事情都交给内核去干好了，事实上 Linux 内核本身也提供了比较成熟的网络封包解包(隧道传输)实现方案 VXLAN，Flanneld 也实现了基于 VXLAN 的方案，该方案在我们日常使用的时候也是最普遍的。

VXLAN 方式

VXLAN，即 Virtual Extensible LAN(虚拟可扩展局域网)，是 Linux 内核本身就支持的一种网络虚化技术。所以说，VXLAN 可以完全在内核态实现上述封装和解封装的工作，从而通过与前面相似的“隧道”机制。VXLAN 模式下，Flanneld 进程只维护各节点对应的 VTEP 相关信息，报文的封装和解装工作，以及传送 VXLAN 包的工作都由 Linux 内核来完成，通信效率就更高了。

host-gw 方式

host-gw 即 Host Gateway，从名字中就可以想到这种方式是通过把主机当作网关来实现跨节点网络通信的。采用 host-gw 模式后 Flanneld 的唯一作用就是负责主机上路由表的动态更新，其实就是将每个 Flannel 子网(Flannel Subnet，比如：10.244.1.0/24)的“下一跳”，设置成了该子网对应的宿主机的 IP 地址，当然，Flannel 子网和主机的信息，都是保存在 etcd 当中的。Flanneld 进程只需要 WACTH 这些数据的变化，然后实时更新路由表即可。这样就完成了整个跨主机通信流程，这个流程可能是最简单最容器理解的模式了，而且容器通信的过程还免除了额外的封包和解包带来的性能损耗，所以理论上性能肯定要更好，但是该模式是通过节点上的路由表来实现各个节点之间的跨节点网络通信，那么就得保证两个节点是可以直接路由过去的。按照内核当中的路由规则，网关必须在跟主机当中至少一个 IP 处于同一网段，故造成的结果就是采用host-gw 这种模式的时候，集群中所有的节点必须处于同一个网络当中，这对于集群规模比较大时需要对节点进行网段划分的话会存在一定的局限性，另外一个则是随着集群当中节点规模的增大，Flanneld 需要维护主机上成千上万条路由表的动态更新也是一个不小的压力。