pod网络的解决方案
Kubernetes网络模型
Kubernetes集群上会存在三个分别用于节点、Pod和Service的网络
◼ 三个网络于集群节点上完成交汇
◼ 由节点内核中的路由模块，以及iptables/netfilter和ipvs等完成网络间的流量转发
Kubernetes的Pod网络
Kubernetes将Pod网络功能通过CNI委托给了外部的插件，该类插件主要负责解决如下4个问题
◼ 同一Pod内容器间的通信（Container to Container）
◼ Pod间的通信（Pod to Pod）
◼ Service到Pod间的通信（Service to Pod）
◼ 集群外部与Service之间的通信（external to Service）
插件安装在/opt/cni/bin/目录下
CNI网络插件基础
 CNI的全称为“容器网络接口”，它是容器引擎与遵循该规范网络插件的中间层，专用于为容器配置
网络子系统
简单来说，目前的CNI规范主要由NetPlugin（网络插件）和IPAM两个插件API组成
  ◼ 网络插件也称Main插件，负责创建/删除网络以及向网络添加/删除容器
    ◆它专注于连通容器与容器之间以及容器与宿主机之间的通信，同容器相关网络设备通常都由该类插件所创建，例如
bridge、ipvlan、macvlan、loopback、ptp、veth以及vlan等虚拟设备；
  ◼ IPAM的全称“IP Address Management”，该类插件负责创建/删除地址池以及分配/回收容器的IP地址
    ◆目前，该类型插件的实现主要有host-local和dhcp两个，前一个基于预置的地址范围进行地址分配，而后一个通过dhcp
协议获取地址；

网络管理
Pod Network: 
Calico: 192.168.0.0/16
Flannel: 10.244.0.0/16

将Pod使用的网络地址，划分为多个小子网，每个子网配置给一个节点使用，用作给该节点上的Pod分配地址的地址池；
每个节点上负责分配地址的插件是ipam插件
如何选择网络插件
通常来说，选择网络插件时应该通过底层系统环境限制、容器网络的功能需求和性能需求三个重要的
评估标准来衡量插件的适用性
   ◼ 底层系统环境限制：公有云环境多有专有的实现，例如Google GCE、Azure CNI、AWS VPC CNI和Aliyun
Terway等，它们通常是相应环境上较佳的选择；否则，虚拟化环境限制较多，除叠加网络模型别无选择，可
用有Flannel vxlan、Calico ipip、Weave和Antrea等；物理机环境几乎支持任何类型的网络插件，此时一般应该
选择性能较好的的Calico BGP、Flannel host-gw或DAMM IPVLAN等
   ◼ 容器网络功能需求：支持NetworkPolicy的解决方案以Calico、WeaveNet和Antrea为代表，而且后两个支持节点
到节点间的通信加密；而大量Pod需要与集群外部资源互联互通时应该选择承载网络模型一类的解决方案
   ◼ 容器网络性能需求：Overlay网络中的协议报文有隧道开销，性能略差，而Underlay网络则几乎不存这方面的
问题；但Overlay或Underlay路由模型的网络插件支持较快的Pod创建速度，而Underlay模型中IPVLAN或
MACVLAN模式中较慢
更少的资源消耗及更好的性能，选flannel
更在意网络加密等安全因素，选WeaveNet
更好的各因素的均衡特征，选Calico