【项目实战19】k8s(5.5)—k8s网络通信（flannel和calico网络插件）_k8s cni flannel calico

一、k8s网络通信简介

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

插件使用的解决方案如下：

1、虚拟网桥：虚拟网卡，多个容器共用一个虚拟网卡进行通信。
2、多路复用：MacVLAN，多个容器共用一个物理网卡进行通信。
3、硬件交换：SR-LOV，一个物理网卡可以虚拟出多个接口，这个性能最好。
1
2
3

关于k8s不同容器之间的通信方式

容器间通信：同一个pod内的多个容器间的通信，通过lo即可实现；
pod之间的通信： 同一节点的pod之间通过cni网桥转发数据包。 不同节点的pod之间的通信需要网络插件支持。
pod和service通信:通过iptables或ipvs实现通信，ipvs取代不了iptables，因为ipvs只能做负载均衡，而做不了nat转换。
pod和外网通信：iptables的MASQUERADE。
Service与集群外部客户端的通信；（ingress、nodeport、loadbalancer）
1
2
3
4
5

二、flannel网络

(1)、flannel网络简介

Flannel简单来说，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。

在默认的Docker配置中，每个节点上的Docker服务会分别负责所在节点容器的IP分配。这样导致的一个问题是，不同节点上容器可能获得相同的内外IP地址。并使这些容器之间能够之间通过IP地址相互找到，也就是相互ping通。

Flannel的设计目的就是为集群中的所有节点重新规划IP地址的使用规则，从而使得不同节点上的容器能够获得“同属一个内网”且”不重复的”IP地址，并让属于不同节点上的容器能够直接通过内网IP通信。
具体参数选项如下

1、VXLAN，即Virtual Extensible LAN（虚拟可扩展局域网），是Linux本身支持的一网种网络虚拟化技术。VXLAN可以完全在内核态实现封装和解封装工作，从而通过“隧道”机制，构建出覆盖网络（OverlayNetwork）。
2、VTEP：VXLAN Tunnel End Point（虚拟隧道端点），在Flannel中VNI的默认值是1，这也是为什么宿主机的VTEP设备都叫flannel.1的原因。
3、Cni0: 网桥设备，每创建一个pod都会创建一对 vethpair。其中一端是pod中的eth0，另一端是Cni0网桥中的端口（网卡）。
4、Flannel.1:TUN设备(虚拟网卡)，用来进行 vxlan报文的处理（封包和解包）。不同node之间的pod数据流量都从overlay设备以隧道的形式发送到对端。
5、Flanneld：flannel在每个主机中运行flanneld作为agent，它会为所在主机从集群的网络地址空间中，获取一个小的网段subnet，本主机内所有容器的IP地址都将从中分配。同时Flanneld监听K8s集群数据库，为flannel.1设备提供封装数据时必要的mac、ip等网络数据信息。
1
2
3
4
5

• 当容器发送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网桥，最后到达目标容器

(2)、flannel使用

flannel支持多种后端：

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

1、修改配置文件

[root@server2 ~] kubectl -n kube-system edit cm kube-flannel-cfg 
1

2、应用deployment控制器开启容器

[root@server2 pod]  kubectl apply -f deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  select: 
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp
        image: myapp:v1
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

3、进入容器查看网关
查看到此容器在server3上

进入容器查看网关

4、进入server3查看cni0
发现cni0作为了网关

5、修改flannel模式由vxlan改为host-gw直连模式

[root@server2 pod] kubectl -n kube-system edit cm kube-flannel-cfg 
1

更新pod节点

6、结果
首先先了解各个节点flannel和cni0的ip
server2

server3

server4

查看server4的路由表，目的地是10.244.0.0/24（server2）网段的数据由server2作为网关，目的地是10.244.1.0/24（server3）网段的数据由server3作为网关。

三、calico网络插件

(1)、calico简介

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

网络架构：

Felix：监听ECTD中心的存储获取事件，用户创建pod后，Felix负责将其网卡、IP、MAC都设置好，然后在内核的路由表里面写一条，注明这个IP应该到这张网卡。同样如果用户制定了隔离策略，Felix同样会将该策略创建到ACL中，以实现隔离。
BIRD：一个标准的路由程序，它会从内核里面获取哪一些IP的路由发生了变化，然后通过标准BGP的路由协议扩散到整个其他的宿主机上，让外界都知道这个IP在这里，路由的时候到这里来。
1
2

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

(2)、calico的安装部署

1、server1（仓库所在主机）获取安装包,上传镜像文件



2、server2创建calico目录，编辑calico.yaml配置文件

3、清除server2之前的flannel插件

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



4、server应用文件

[root@server2 calico] kubectl apply -f calico.yaml 
1

可以在k8的系统配置中查看到当前的calico文件

查看路由表，将目的为10.244.1.0(server3)网段的数据交给server3作为网关，将目的为10.244.2.0(server4)网段的数据交给server4作为网关.

四、calico网络策略

(1)、loadbalancer实现容器外部访问

启动控制器，启动svc，利用loadbance模式，发现ip是172.25.42.10

[root@server2 metallb] cat configmap.yaml 
//
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 172.25.42.10-172.25.42.20
//
[root@server2 metallb] cat deployment.yml 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: myapp:v2

[root@server2 metalb] cat mysvc.yaml 
//
apiVersion: v1
kind: Service
metadata:
  name: mysvc                                                    
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  selector:
    app: nginx 
  type: LoadBalancer       
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

[root@server2 calico] kubectl apply -f bashconfigmap.yaml 
[root@server2 calico] kubectl apply -f deployment.yml
[root@server2 calico] kubectl apply -f mysvc.yaml 
1
2
3

在真实主机可以实现对容器的均衡负载访问。

(2)、限制访问指定服务

要进行限制访问的是标签为nginx的pod容器

[root@server2 calico] cat deny-nginx.yaml 
/
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-nginx
spec:
  podSelector:
    matchLabels:
      app: nginx
/

[root@server2 calico] kubectl apply -f deny-nginx.yaml 
[root@server2 calico] kubectl apply -f deny-nginx.yaml 
[root@server2 calico] kubectl apply -f deny-nginx.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

之前可以访问容器的ip，现在不能访问了

查看pod信息并输出所在的节点，访问pod所在节点的ip地址，依然访问失败。

(3)、允许指定pod访问服务

拉起一个demo容器,查看到标签如下

访问刚刚的demo容器，可以访问成功

再建立一个容器标签为test，然后进入该容器去访问demo，可以看到访问成功，再去访问nginx的标签地址，发现不能访问，因为刚才的策略是禁止访问nginx标签的容器

编辑deny-nginx.yaml配置文件，设置标签为test的的容器可以访问nginx服务的容器

[root@server2 calico] cat deny-nginx.yaml 
///
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-nginx
spec:
  podSelector:
    matchLabels:
      app: nginx
---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: access1-nginx
spec:
  podSelector:
    matchLabels:
      app: nginx
  ingress:
  - from:
      - podSelector:
          matchLabels:
            app: test
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

可以查看到有两条网络策略

再次进入，发现可以访问到之前的nginx标签的容器。（策略允许了test标签的容器访问nginx标签的容器）