K8s---网络通信

目录k8s网络通信简介flannel网络flannel网络简介flannel网络原理flannel配置calico网络插件calico简介k8s网络通信简介k8s通过CNI接口接入其他插件来实现网络通讯。目前比较流行的插件有flannel，calico等。CNI插件存放位置：# cat /etc/cni/net.d/10-flannel.conflist插件使用的解决方案如下：虚拟网桥，虚拟网卡，

芒果会飞

702人浏览 · 2022-01-15 15:57:45

芒果会飞 · 2022-01-15 15:57:45 发布

禁用namespace中所有pod之前的相互访问

只允许指定的ns访问服务

允许外网访问服务：

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）

flannel网络

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

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

flannel配置

flannel支持多种后端：

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

同一节点的pod是通过cni网桥转发

kubectl get pod -o wide 
#可以看到ip相同的在一个节点，不同的不再

server3：

ip addr
通过网桥（cni0），1.1是其网关

yum install -y bridge-utils

brctl show
可以看到容器都桥接到cni0【和docker0没有区别】

server2：

ip addr
可以看到有一个flannel.1【每个节点都会分配一个】

server4：

ip addr
ip addr show flannel.1
可以看到mac地址是2b：b2

server3：

route -n
#server3是1网段，数据包走的是cni0走的是本地网桥
要是别的网段要从隧道走（flannel.1）

arp -an
发现有缓存的2网段的mac地址（2b：b2），

bridge  fdb
转发数据库

server2：

kubectl -n kube-system edit cm kube-flannel-cfg
编辑【type： host-gw（直连陆游，就是直接走主机网关）】

kubectl -n kube-system get pod

kubectl get pod -n kube-system |grep kube-flannel | awk '{system("kubectl delete pod "$1" -n kube-system")}'
删除之前的pod，是其生效

route -n
跟之前是有区别的，（找2网段会直接有网关）【每个节点都有】

calico网络插件

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在同一个网段，适用于大型网络。

server2：

cd ..
mkdir calico
cd calico/
需要下载calico-v3.21.2.yaml文件并修改

网页：创建新项目：calico

server1：

docker load -i calico-v3.21.2.tar 
docker images | grep reg.westos.org/calico
docker images | grep reg.westos.org/calico | awk '{system("docker push "$1":"$2"")}'
上传镜像至私有仓库

server2

kubectl -n kube-system get pod
已经安装了kube-flannel，需要清除掉

cd
ls

kubectl delete -f kube-flannel.yml 
删除kube-flannel

kubectl -n kube-system get pod
可以看到已经清理干净

cd /etc/cni/net.d/
ls

rm -f 10-flannel.conflist 
#【每个节点都要删】不然会对节点里的网络插件有影响
下次创建会自动生成

server3、4

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

server2

cd service/calico/

kubectl apply -f calico-v3.21.2.yaml 
部署创建

kubectl get pod -n kube-system 
等待全部就绪【这个时候calico已经全部替代flannel】

网页：访问www1.westos.org
网络组建替换后依然可以访问，没有问题

kubectl get svc
curl 10.111.110.66
访问ClusterIP也可以
curl 10.111.110.66/hostname.html

calico网络策略

实验前准备：
server1：
cd harbor/
docker-compose ps
docker-compose start
docker-compose ps
server2：
查看pod是否准备就绪
kubectl get pod
kubectl get pod -o wide 
kubectl -n kube-system get pod

限制访问指定服务

server2：

kubectl get pod --show-labels 
cd service/calico/
ls

vim demo.yml 
默认控制当前的namespace

kubectl apply -f demo.yml 
kubectl get networkpolicies.
cd ..
cd ingress/
ls

vim ingress.yml 【注释重定向、认证】
kubectl apply -f ingress.yml

真机中：

curl www1.westos.org
可以访问

curl www2.westos.org
访问不通（因为刚才文件中限制了）

kubectl describe svc web2
查看web2的选择器(app=nginx)

允许指定pod访问服务

cd ..
cd calico/
kubectl apply -f demo.yml 
kubectl describe networkpolicies deny-nginx 
kubectl get svc
kubectl run -it demo --image=busyboxplus --restart=Never
--/ # curl  10.105.243.221
访问不了（因为标签）

不退出重新开启一个server2窗口

kubectl get pod --show-labels 
可以看到标签是：run=demo,是运行时自动加的【刚才是app=demo】

kubectl label pod demo app=demo
添加标签

回到第一台server2窗口

--/ # curl  10.105.243.221
添加标签后访问成功

--/ # curl  10.105.243.221/hostname.html
访问页面，负载均衡

禁用namespace中所有pod之前的相互访问

server2:

--/ # curl 10.111.110.66
访问web1的CLUSTER-IP，是可以访问成功的
因为www1是另外的标签（app=myapp）不在网络策略控制范围内

第二台server2：

cd service/calico/
vim demo.yml 
kubectl apply -f  demo.yml 

kubectl get networkpolicies.
可以看到有2个网络策略（没有指定POD-SELECTOR的话就是所有）

回到第一台server2窗口

--/ # curl 10.111.110.66
不能访问web1

--/ # curl 10.105.243.221
访问web2可以因为有白名单

kubectl create namespace test
创建一个namespace
kubectl run -it demo --image=busyboxplus --restart=Never -n test

第二台server2：

kubectl get  pod
kubectl delete pod demo 
删掉之前的demo

kubectl get  pod
里面没有demo

kubectl get pod -n test 
demo在test里面

第一台server2窗口：

--/ # curl 10.105.243.221
--/ # curl 10.111.110.66
访问web2和web1都是不可以的

/ # curl 10.244.141.195
访问pod的ip也不可以

/ # nslookup web1.default.svc.cluster.local

/ # nslookup web2.default.svc.cluster.local
因为目前的demo是运行在test下。web1和web2是创建在default下，默认情况下在解析的时候会加上当前的ns的后缀
所以需要手工加上后缀

只允许指定的ns访问服务

第二台server2：

vim demo.yml 
kubectl apply -f demo.yml 

kubectl get ns --show-labels 
目前没有test标签（所以目前还是不能访问）

kubectl label namespaces test role=test
添加标签

kubectl get namespaces --show-labels 
查看添加

回到第一台server2窗口

--/ # curl 10.111.110.66
不能访问web1

--/ # curl 10.105.243.221
访问web2可以因为有匹配（能访问的是app=nginx）

第二台server2：

vim demo.yml 【注释掉禁止整个pod的通信】
kubectl delete networkpolicies default-deny

真机中

curl www1.westos.org
可以访问

curl www2.westos.org
不能访问（因为没有开放外部的原地址）

允许外网访问服务：

第二台server2：

vim demo.yml 
kubectl apply -f demo.yml

真机中

curl www2.westos.org
可以访问了

第二台server2：

kubectl delete -f demo.yml 

kubectl get networkpolicies.
清空掉所有的网络策略（为不影响之后的网络配置）

kubectl delete namespaces test 
删除之前创建的ns

kubectl get pod -n kube-system

K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 | 韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。长夜有穷，真水无香。领略过了 K8s“身在江

K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub