企业运维实战--k8s学习笔记 k8s网络通信、Flannel vxlan模式简介、calico网络插件替换、网络策略范例总结

1.k8s网络通信

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

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

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

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

pod之间的通信：

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

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

pod和外网通信：iptables的MASQUERADE。

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

2.Flannel网络

2.1.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等网络数据信息。

原理图：

当容器发送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.2vxlan模式

Directrouting直连路由模式，适用于同网段通信。表现为host-gw，主机网关，性能好，但只能在二层网络中，不支持跨网。

查看server1的网关，Flannel .1的模式
route -n

查看arp
arp -an

2.3.host-gw模式

因为在一个电脑上的虚拟机做实验，所以用host-gw直连模式就可以了！
修改kube-flannel配置文件，将type改为直连模式

kubectl -n kube-system edit cm kube-flannel-cfg

 "Type": "host-gw"

更新pod节点

kubectl get pod -n kube-system |grep kube-flannel | awk '{system("kubectl delete pod "$1" -n kube-system")}'

此时在server1上查看网关，发现方式变为了eth0

3.calico网络插件

3.1.calico简介

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

3.2.calico组件安装

安装caloco替换原先的flannel

建立一个目录calico用来存放它的文件

mkdir calico
cd calico/
wget https://docs.projectcalico.org/manifests/calico.yaml

然后将calico-v3.20.2.tar拉取下来上传私有仓库
因为本人本地有不需要拉取！

将calico.yaml资源清单的镜像版本改对：

vi calico.yaml

image:calico/cni:v3.20.2   ####3833,3547,3574,3615行都需要改
# Enable IPIP
            - name: CALICO_IPV4POOL_IPIP
              value: "off"

删除之前的网络插件flannel

cd
kubectl delete -f kube-flannel.yml

将server123所有k8s节点的网络插件配置缓存文件移走

cd /etc/cni/net.d/
rm -rf 10-flannel.conflist 

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

kubectl apply -f calico.yaml

查看节点 初始化完成

kubectl get pod -n kube-system

查看网关，和svc信息
route -n

重新运行一个svc,并访问IP

kubectl apply -f lb-svc.yaml
kubectl get svc
curl 10.108.26.185

4.calico网络策略

详情请访问官方网站：
https://kubernetes.io/zh/docs/concepts/services-networking/network-policies/

4.1.限制访问指定服务

 vi policy.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: access-nginx
spec:
  podSelector:
    matchLabels:
      app: myapp
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: "true"

查看标签：

运行 deny-nginx.yaml清单，查看状态

kubectl apply -f  deny-nginx.yaml
kubectl get networkpolicies.

kubectl get svc

访问IP

 kubectl run demo -it --image=busyboxplus --restart=Never

卡住了是因为被限制了（若没卡住则重新开启一遍deployment）
在开启一个server1终端 查看标签
kubectl get pod --show-labels
`kubectl label pod demo access=true #添加标签
成功

4.2.允许指定namespace访问服务

policy.yaml文件下面继续添加

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: access-nginx
spec:
  podSelector:
    matchLabels:
      app: myapp
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: "true"
    - namespaceSelector:
        matchLabels:
          project: test

 kubectl create ns test #创建namespace
 cp ../ingress/deployment.yaml .  将之前ingress实验的清单复制过来
kubectl apply -f deployment.yaml -n test   并在test里执行
kubectl get pod -n test    查看

kubectl label ns test project=test 添加标签即可访问

4.3允许与禁止指定网段访问服务

kubectl get svc
kubectl edit svc lb-svc
将type改为LoadBalancer

编辑policy.yaml

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: access-nginx
spec:
  podSelector:
    matchLabels:
      app: myapp
  ingress:
  - from:
    - podSelector:
        matchLabels:
          access: "true"
    - namespaceSelector:
        matchLabels:
          project: test
    - ipBlock:
        cidr: 172.25.0.0/16
        except:
        - 172.25.76.0/24   #76网段不能访问

将except下两行注释掉后
kubectl describe networkpolicies.

重新访问 发现成功访问