0
点赞
收藏
分享

微信扫一扫

Kubernetes(8)---k8s网络通信

雅典娜的棒槌 2022-03-30 阅读 73

一、k8s网络通信简介

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

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

二、flannel网络

2.1、flannel网络简介

Flannel是CoreOS团队针对Kubernetes设计的一个网络规划服务,简单来说,它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。

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

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

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

2.2、flannel网络原理

Flannelvxlan模式跨主机通信原理
在这里插入图片描述

  • 当容器发送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.3、flannel配置

flannel支持多种后端:

  • Vxlan:
    vxlan //报文封装,默认
    Directrouting //直接路由,跨网段使用vxlan,同网段使用host-gw模式。
  • host-gw: //主机网关,性能好,但只能在二层网络中,不支持跨网络, 如果有成千上万的Pod,容易产生广播风暴,不推荐
  • UDP: //性能差,不推荐
[root@server3 ~]# yum install -y bridge-utils
[root@server3 ~]# brctl show
[root@server3 ~]# ip addr

route -n

server2用cni0进行通信,server3和server4利用flannel进行通信

 bridge fdb:查看主机ip对应的MAC地址

server3对应的MAC地址为f6:5a:8b:dc:8a:b6

[root@server2 ingress]# kubectl -n kube-system get cm

[root@server2 ingress]# kubectl -n kube-system edit cm kube-flannel-cfg ##修改
configmap/kube-flannel-cfg edited
        "Type": "host-gw"

 删除重建会自动更新

[root@server2 ingress]# kubectl get pod -n kube-system | grep kube-flannel | awk '{system("kubectl delete pod "$1" -n kube-system")}'

 查看各个节点网关(server4为关闭状态,所以未改变)

三、calico网络插件

3.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在这里,路由的时候到这里来。
    在这里插入图片描述
    工作模式:
  • IPIP工作模式:适用于互相访问的pod不在同一个网段中,跨网段访问的场景。
    在这里插入图片描述
  • BGP工作模式:适用于互相访问的pod在同一个网段,适用于大型网络。
    在这里插入图片描述

3.2、calico的安装部署

真实主机获取calico.yaml和calico的压缩包,然后将压缩包发送给server1,将calico.yaml发送到server2的/root/calico目录下

从官方获取文档

[root@server2 service]# mkdir calico
[root@server2 service]# cd calico/
[root@server2 calico]# wget https://docs.projectcalico.org/manifests/calico.yaml --no-check-certificate

[root@server2 calico]# vim calico.yaml   查看image镜像文件

拉取所需镜像并上传至仓库

[root@server1 ~]# docker pull calico/cni:v3.22.1
[root@server1 ~]# docker pull calico/pod2daemon-flexvol:v3.22.1
[root@server1 ~]# docker pull calico/node:v3.22.1
[root@server1 ~]# docker pull calico/kube-controllers:v3.22.1
[root@server1 ~]# docker images | grep calico | awk '{system("docker tag "$1":"$2" reg.westos.org/"$1":"$2"")}'
[root@server1 ~]# docker images | grep reg.westos.org/calico | awk '{system("docker push "$1":"$2"")}'

 

 [root@server2 calico]# vim calico.yaml   ##修改镜像下载地址,与仓库保持一致

  注意:在执行前需要删除flannel,否则有冲突

每个节点都要删除10-flannel.conflist  

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

 查看节点

  切换完成之后,测试一下

四、calico网络策略

4.1、限制访问指定服务

server2进入calico目录下编辑deny-nginx.yaml配置文件

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

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

 删除depoly相关的配置文件

[root@server2 ~]# cd pod/
[root@server2 pod]# kubectl delete -f depoly.yml 

应用下列yml配置文件,查看服务,看到ip,对这两个地址测试访问,发现

[root@server2 pod]# kubectl apply -f depoly.yml 
deployment.apps/deployment-myapp created
[root@server2 pod]# cd 
[root@server2 ~]# cd service/calico/
[root@server2 calico]# ls
calico.yaml  deny-nginx.yml
[root@server2 calico]# kubectl apply -f deny-nginx.yml 

对这两个地址测试访问,发现web1访问失败,web2访问成功

 因为web1的pod的标签都是myapp,已经设置了限制访问

 

4.2、允许指定pod访问服务

使用nginx镜像拉起一个新的容器,名为demo

 查看demo容器所在节点地址,测试访问,看到可以成功访问

使用busyboxplus镜像拉起一个新容器,标签为test,然后进入该容器去访问demo,可以看到访问成功,再去访问myapp的节点地址,发现能访问

 编辑deny-nginx.yaml配置文件,配置可以访问myapp服务的容器,这里是test

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

编辑完成后应用配置,查看网络策略,可以看到配置好的策略

 连接test容器,访问myapp服务,现在可以正常访问了

 

 

举报

相关推荐

0 条评论