企业实战-Kubernetes(五)网络通信

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

2.2vxlan模式

原理图

当容器发送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.3host-gw模式

更改为host-gw模式，重启pod

kubectl -n kube-system get cm
kubectl -n kube-system edit cm kube-flannel-cfg
type: host-gw

更新节点信息

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

server3上查看网关，变为eth0

3 calico网络插件替换flannel

calico简介:

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

在仓库中创建calico仓库并设置为公开，上传下载好的镜像进去
创建calico目录

vim calico.yaml #镜像路径记得写成本地仓库的

kubectl delete -f kube-flannel.yml #删除之前的网络插件flannel

删除所有k8s节点的网络插件配置缓存文件(server2、3、4上)
移走或直接删除/etc/cni/net.d/10-flannel.conflist

启用后查看节点

kubectl apply -f calico.yaml
kubectl get pod -n kube-system

查看新生成的网络插件配置文件

4 calico网络策略

官网：https://kubernetes.io/zh/docs/concepts/services-networking/network-policies/

具体策略根据自己的需求进行编写

限制访问指定服务:

vim nginx-policy.yml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-nginx
spec:
  podSelector:
    matchLabels:
      app: nginx

允许指定pod访问服务

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

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}

禁止其他 namespace 访问服务

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-namespace
spec:
  podSelector:
    matchLabels:
  ingress:
  - from:
    - podSelector: {}

只允许指定namespace访问服务

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: access-namespace
spec:
  podSelector:
    matchLabels:
      app: myapp
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          role: prod

允许外网访问服务

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: web-allow-external
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - ports:
    - port: 80
    from: []