Kubernetes网络插件Flannel

1.Kubernetes网络通信

(1) 容器间通信
同一个Pod内的多个容器间的通信, lo
(2)Pod通信
Pod IP <-（直达）-> Pod IP 意思就是pod和pod之间使用自己的IP不经过任何转换直达，通信双方所见的地址就是双方的地址
(3)Pod与Service通信
PodIP <–> ClusterIP IPVS和iptables规则可以实现，ipvs可以做负载但是无法取代iptables，因为很多功能ipvs做不到
(4)Service与集群外部客户端的通信
Nodeport，ingress等等

2.K8s网络解决方案

（1）方案介绍
①k8s网络实现要靠网络插件–CNI（容器Container 网络Network 接口Interface）
②K8s本身不提供网络解决方案，允许托管去使用第三方的任何解决方案来代为解决k8s集群中这4种通信模型当中的需要执行的通信问题任何一种程序都可以（简单来说就是用第三方插件解决4中k8s集群的通信模型，能解决就可以用）
③CNI：flannel、calico、canel、cube-router
（2）方案所涉及的技术
①虚拟网桥
隧道or叠加网络，可以实现更强的控制功能但是开销会比较大
能保证pod和容器有专用的网络接口，一半留在pod或者容器上，一半留在宿主机上接入到网桥中去使用，类似于docker的bridge
② 多路复用
MacVLAN----基于Mac的方式去创建VLAN（为每个虚拟接口配置一个独有的Mac，让一个物理网卡可以承载多个容器去使用，这样子直接使用物理网卡，并基于物理网卡中的MacVLAN去跨节点通信）
③ 硬件交换
SR-IOV-----单根IO虚拟化（一个物理网卡可以直接虚拟多个网卡，直接给容器使用）

3.加载配置文件
Kubelet在启动时直接通过路径去加载配置文件 /etc/cni/net.d
任何其他网络插件部署完以后，也要把配置文件仍在这个路径下，从而被kubelet所加载，从而可以被kubelet作为必要时创建一个pod，pod要有网络，那么kubelet就调用这个目录下的配置文件，由网络插件代为实现地址分配，网络创建，接口创建等各种功能这叫CNI
[root@k8s-master net.d]# pwd
/etc/cni/net.d
[root@k8s-master net.d]# cat 10-flannel.conflist

{
  "name": "cbr0",               
  "plugins": [                 #插件类型
    {
      "type": "flannel",        
      "delegate": {             #授权使用方式
        "hairpinMode": true,
        "isDefaultGateway": true
      }
    },
    {
      "type": "portmap",       #类型
      "capabilities": {
        "portMappings": true  #支持端口映射（叠加网络）
      }
    }
  ]
}

4.网络插件功能介绍

（1）flannel简介
网络插件flannel最为简单，但是缺点是在k8s集群上网络插件不仅仅要实现网络地址分配，网络管理等功能，还要实现网络策略，flannel不支持网络策略
（2）策略的重要性
虽然k8s有命名空间管理隔离，和所谓管理隔离就是说rolebinding的user是无法对其他命名空间的资源做管控，但是他可以控制自己的pod去访问别的命名空间的pod的，比如两个项目之间互相不认识，但是pod访问pod万一出事，容易背锅，那么我们继续要一些网络插件进行设置pod与pod访问策略之类的
（3）解决方案
基本解决方案可以先使用flannel然后需要策略的时候去加calico，虽然加calico但是不让他做网络地址分配等等的工作，只让他做策略，这样就没必要用canel这种合起来的

5.flannel的三种模式

后端传输方式：下面的长条封装报文守护分别是 以太网、IP、UDP、VxLAN （额外的开销）所以说基于VxLAN性能可能会低，但是可以独立管理一个网络跟物理不冲突
flannel：
支持多种后端：
（1）VxLAN (扩展的虚拟局域网)

(1) vxlan
(2) Directrouting
支持同一网段我们使用直接路由通信（源和目标在同意网络），如果不在同一网段我们就使用VxLAN

后端传输方式：下面的长条封装报文守护分别是 以太网、IP、UDP、VxLAN （额外的开销）所以说基于VxLAN性能可能会低，但是可以独立管理一个网络跟物理不冲突

（2）host-gw: Host Gateway （主机网关）

在node节点上虚拟一个虚拟网卡，所有pod都是虚拟网卡所属网段，那么通过路由条目，路由转发可以送达至其他node节点，虽然这种方式性能高，但是面临的就是说如果node节点数量过多，路由条目会非常大，并且一旦有广播报文所有都会受到波及，而且所有node节点必须工作再同一个2层或3层网络

（3）UDP（性能极差）

6.配置flannel的模式

（1）configmap配置参数介绍
flannel的配置参数：
Network：flannel使用的CIDR格式的网络地址，用于为Pod配置网络功能；
10.244.0.0/16 ->
master: 10.244.0.0/24
node01: 10.244.1.0/24
…
node255: 10.244.255.0/24
10.0.0.0/8
10.0.0.0/24
…
10.255.255.0/24
SubnetLen：把Network切分子网供各节点使用时，使用多长的掩码进行切分，默认为24位；
SubnetMin：10.244.10.0/24
SubnetMax: 10.244.100.0/24
Backend：vxlan, host-gw, udp
vxlan:
（2）修改VxLAN改为Directrouting
因为我们把flannel封装为容器运行了，所以修改flannel的configmap
方法1（不推荐）
kubectl edit configmaps -n kube-system kube-flannel-cfg

  net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "vxlan",
        "Directrouting": true            #修改这个参数切记  vxlan后面会有个逗号
      }
    }

修改完以后需要重启所有节点的flannel
方法2（推荐）
准备好flannel的yaml文件，直接修改yaml文件

  net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "vxlan",           #注意这里有个逗号
        "Directrouting": true
      }
    }

kubectl apply -f kube-flannel.yml
如果你的flannel没有作过其他的改动可以直接应用，如果作过网段之间的什么修改的话，需要查看是否一致，然后再进行应用，前面提到过就是说apply和edit或者create之间不要混着用，所以既然我们apply声明的flannel，那么我们最好也是apply应用一下
测试方法（测试是否修改成功）
修改之前

改完以后

可以在node节点分别来一个pod，用节点1的pod去ping节点2的 然后在node1上抓包

如果他还是隧道的话 我们在ens33上面是抓不到icmp的因为已经封装为udp了
注意：需要注意的是就是说这个网络策略应该是在装好k8s集群以后就该有的策略，而不是半途改的，因为修改需要重启flannel，可能会导致服务出现问题，所以我们需要提前想到这个问题，而且这个配置仅是为了可能集群内node节点过多，网络性能出现瓶颈