kubernetes 5 （网络通信、flannel 网络、calico网络策略）

一、k8s网络通信

1、k8s通过CNI接口接入其他插件来实现网络通讯。目前比较流行的插件有flannel，calico等。
CNI插件存放位置： cat /etc/cni/net.d/10-flannel.conflist

插件使用的解决方案如下：
虚拟网桥，虚拟网卡，多个容器共用一个虚拟网卡进行通信。
多路复用：MacVLAN，多个容器共用一个物理网卡进行通信。
硬件交换：SR-LOV，一个物理网卡可以虚拟出多个接口，这个性能最好。

2、容器间通信：同一个pod内的多个容器间的通信，通过lo即可实现；

pod之间的通信：
同一节点的pod之间通过cni网桥转发数据包。
不同节点的pod之间的通信需要网络插件支持。

3、pod和service通信: 通过iptables或ipvs实现通信，ipvs取代不了iptables，因为ipvs只能做负载均衡，而做不了nat转换。

pod和外网通信：iptables的MASQUERADE。

Service与集群外部客户端的通信；（ingress、nodeport、loadbalancer）

二、flannel网络

1.flannel简介

1、Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。
2、在默认的Docker配置中，每个节点上的Docker服务会分别负责所在节点容器的IP分配。这样导致的一个问题是，不同节点上容器可能获得相同的内外IP地址。并使这些容器之间能够之间通过IP地址相互找到，也就是相互ping通。
3、Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则，从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址，并让属于不同节点上的容器能够直接通过内网IP通信。

2.flannel组件

VXLAN
即Virtual Extensible LAN（虚拟可扩展局域网），是Linux本身支持的一网种网络虚拟化技术。
VXLAN可以完全在内核态实现封装和解封装工作，从而通过“隧道”机制，构建出覆盖网络（Overlay Network）。

VTEP：VXLAN Tunnel End Point（虚拟隧道端点），在Flannel中 VNI的默认值是1，这也是为什么宿主机的VTEP设备都叫flannel.1的原因。

Cni0: 网桥设备，每创建一个pod都会创建一对 veth pair。
其中一端是pod中的eth0，另一端是Cni0网桥中的端口（网卡）。

Flannel.1: TUN设备(虚拟网卡)，用来进行 vxlan 报文的处理（封包和解包）。
不同node之间的pod数据流量都从overlay设备以隧道的形式发送到对端。

Flanneld：flannel在每个主机中运行flanneld作为agent，它会为所在主机从集群的网络地址空间中，获取一个小的网段subnet，本主机内所有容器的IP地址都将从中分配。
同时Flanneld监听K8s集群数据库，为flannel.1设备提供封装数据时必要的mac、ip等网络数据信息。

3.flannel网络原理

Flannel vxlan模式跨主机通信原理

当容器发送IP包，通过veth pair 发往cni网桥，再路由到本机的flannel.1设备进行处理。

VTEP设备之间通过二层数据帧进行通信，源VTEP设备收到原始IP包后，在上面加上一个目的MAC地址，封装成一个内部数据帧，发送给目的VTEP设备。

内部数据桢，并不能在宿主机的二层网络传输，Linux内核还需要把它进一步封装成为宿主机的一个普通的数据帧，承载着内部数据帧通过宿主机的eth0进行传输。

Linux会在内部数据帧前面，加上一个VXLAN头，VXLAN头里有一个重要的标志叫VNI，它是VTEP识别某个数据桢是不是应该归自己处理的重要标识。

flannel.1设备只知道另一端flannel.1设备的MAC地址，却不知道对应的宿主机地址是什么。在linux内核里面，网络设备进行转发的依据，来自FDB的转发数据库，这个flannel.1网桥对应的FDB信息，是由flanneld进程维护的。

linux内核在IP包前面再加上二层数据帧头，把目标节点的MAC地址填进去，MAC地址从宿主机的ARP表获取。

此时flannel.1设备就可以把这个数据帧从eth0发出去，再经过宿主机网络来到目标节点的eth0设备。目标主机内核网络栈会发现这个数据帧有VXLAN Header，并且VNI为1，Linux内核会对它进行拆包，拿到内部数据帧，根据VNI的值，交给本机flannel.1设备处理,flannel.1拆包，根据路由表发往cni网桥，最后到达目标容器。

4.flannel配置

flannel支持多种后端：
（1）Vxlan：
vxlan 报文封装，默认
Directrouting 直接路由，跨网段使用vxlan，同网段使用host-gw模式。
（2）host-gw：主机网关，性能好，但只能在二层网络中，不支持跨网络，如果有成千上万的Pod，容易产生广播风暴，不推荐
（3）UDP：性能差，不推荐

配置flannel

server2查看所有pod，进入IP为10.244.1.59的pod ( node 在server3上) ，查看网关

server3查看cni0网卡配置，IP地址为10.244.1.1

查看server3的网关，Flannel .1的模式

查询系统中缓存的ARP表

查找并修改kube-flannel-cfg配置文件，将type由vxlan改为host-gw直连模式


在查看pod信息的时候，flannel模式还在

更新pod（删除节点副本，重新生成的节点会读取修改后的配置文件并生效）

此时在server3上查看网关，发现方式变为了eth0（目的地是10.244.0.0/24网段的数据由server2作为网关）

在server4上查看网关，也变为了eth0

三、calico网络插件

1.calico简介

flannel实现的是网络通信，calico的特性是在pod之间的隔离。
通过BGP路由，但大规模端点的拓扑计算和收敛往往需要一定的时间和计算资源。
纯三层的转发，中间没有任何的NAT和overlay，转发效率最好。
Calico 仅依赖三层路由可达。Calico 较少的依赖性使它能适配所有 VM、Container、白盒或者混合环境场景。

2.calico网络架构

Felix：监听ECTD中心的存储获取事件，用户创建pod后，Felix负责将其网卡、IP、MAC都设置好，然后在内核的路由表里面写一条，注明这个IP应该到这张网卡。同样如果用户制定了隔离策略，Felix同样会将该策略创建到ACL中，以实现隔离。

BIRD：一个标准的路由程序，它会从内核里面获取哪一些IP的路由发生了变化，然后通过标准BGP的路由协议扩散到整个其他的宿主机上，让外界都知道这个IP在这里，路由的时候到这里来。

3.calico网络插件

IPIP工作模式：适用于互相访问的pod不在同一个网段中，跨网段访问的场景。

BGP工作模式：适用于互相访问的pod在同一个网段，适用于大型网络。

网络策略：NetworkPolicy策略模型：控制某个namespace下的pod的网络出入站规则

4.calico组件安装

安装caloco替换原先的flannel网络组件；
首先server2 创建calico目录，获取calico.yaml配置文件

真实主机将calico的压缩包发送给server1

网页创建calico项目

server1导入calico镜像

server1将本地的calico镜像批量上传至仓库


server2 修改calico.yaml资源清单的镜像版本





将隧道模式关闭

查看pod信息，看到还有flannel的pod，删除之前的网络插件flannel

再次查看，flannel相关pod已被删除

server2/3/4 将/etc/cni/net.d目录下的flannel的配置文件移除



server2执行calico.yaml清单，完成初始化

再次查看pod信息，可以看到生成了4个calico相关pod

查看svc信息

查看网关

利用lb-svc.yaml文件创建一个服务；
查看新创建的lb-svc服务，外部访问ip是172.25.36.20

客户端访问该地址，可以看到负载均衡

四、calico网络策略

1.限制访问指定服务

server2编辑deny-nginx.yaml配置文件,限制访问标签为myapp的pod容器

查看标签

运行 deny-nginx.yaml资源清单：kubectl apply -f deny-nginx.yaml
查看NetworkPolicy资源：kubectl get networkpolicies.

删除deployment相关的配置文件

应用下列yaml配置文件；
查看服务，看到lb-svc的集群ip和外部访问ip，对这两个地址访问，发现访问失败

查看pod信息，访问pod所在节点的ip地址，依然访问失败，因为这些pod的标签都是myapp，已经设置了限制访问

2.允许指定pod访问服务

使用nginx镜像拉起一个新的容器，标签为run=demo

访问demo容器所在节点ip 10.244.22.2，可以成功访问

使用busyboxplus镜像拉起一个新容器，标签为test；
进入该容器去访问demo，可以访问成功，但仍然不能访问myapp的节点地址


继续编辑deny-nginx.yaml配置文件，设定可以标签为test的容器可以访问标签为myapp的容器；

查看信息，发现多了一条网络策略

连接test容器，访问标签为myapp的容器，此时可以正常访问

3.禁止 namespace 中所有 Pod 之间的相互访问

删除deny-myapp.yaml资源清单；
查看所有命名空间

查看 (default 默认）命名空间的pod

默认同一个ns中的pod是可以相互访问的;
编辑ns.yaml，设定他们不能相互访问；
查看网络策略查看详细信息，看到默认拒绝

查看demo的服务节点ip 10.244.22.2，serve2无法访问；
连接test容器，依然无法访问默认ns的pod节点（内外都无法访问）

4.禁止其他namespace访问服务

创建名为test的ns;
拉起test命名空间内busybox镜像创建的容器，无法访问默认ns的pod

运行nginx镜像容器，指定ns为test


连接test容器，可以访问nginx服务

5.只允许指定 namespace 访问服务

继续编辑ns.yaml文件，设定匹配到角色是prod的ns时，允许访问默认ns的myapp服务；
给test命名空间添加prod角色

应用资源清单，连接test容器，访问myapp服务，可以看到正常访问

但仍不能访问demo，因为标签不是myapp

6.允许外网访问服务

查看所有pod并显示标签，有3个标签为myapp的pod；
查看lb-svc的外部访问地址为172.25.36.20

真机无法访问

继续修改ns.yaml文件，允许标签为myapp的服务可以被外网通过80端口访问到；
from表示来源，没有内容就是不限来源


此时真机成功访问myapp服务