目录
一.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网络
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.vxlan模式
Directrouting直连路由模式,适用于同网段通信。表现为host-gw,主机网关,性能好,但只能在二层网络中,不支持跨网。
查看server3的网关,Flannel .1的模式
route -n
查看arp
arp -an
3.host-gw模式
因为在一个电脑上的虚拟机做实验,所以用host-gw直连模式就可以了!
修改kube-flannel配置文件,将type改为直连模式
kubectl -n kube-system get cm
cd
kubectl -n kube-system edit cm kube-flannel-cfg
type: host-gw
我们查看pod信息的时候,flannel模式还在!
kubectl -n kube-system get pod
是因为没有更新pod节点:
那么就更新它!并查看pod节点信息
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
在server4上查看网关,也是一样发变为了eth0
三.calico网络插件
1.calico简介:
flannel实现的是网络通信,calico的特性是在pod之间的隔离。
通过BGP路由,但大规模端点的拓扑计算和收敛往往需要一定的时间和计算资源。
纯三层的转发,中间没有任何的NAT和overlay,转发效率最好。
Calico 仅依赖三层路由可达。Calico 较少的依赖性使它能适配所有 VM、Container、白盒或者混合环境场景。
2.calico组件安装
安装caloco替换原先的flannel
建立一个目录calico用来存放它的文件
cd
mkdir calico
cd calico/
wget https://docs.projectcalico.org/manifests/calico.yaml
在私有仓库建立新的项目calico
然后将calico-v3.19.1.tar拉取下来上传私有仓库!
因为本人本地有不需要拉取!
上传仓库!
上传成功!
将calico.yaml资源清单的镜像版本改对:
image:calico/cni:v3.19.1
3833,3547,3574,3615行都需要改!
将隧道模式关闭
IPIP
vaule: "off"
删除之前的网络插件flannel
kubectl delete -f kube-flannel.yml
将所有k8s节点的网络插件配置缓存文件移走!
server2.3.4都需要移走!
cd /etc/cni/net.d/
ls
mv 10-flannel.conflist /mnt/
执行calico.yaml清单,完成初始化!
kubectl apply -f calico.yaml
查看节点,可以看到正在初始化:
等一会就会完成!
kubectl get pod -n kube-system
查看网关,和svc信息
kubectl -n kube-system svc
route -n
将之前实验的svc删除
重新运行一个svc,并访问IP!!
kubectl apply -f lb-svc.yaml
kubectl get svc
curl 10.98.183.249
四.calico网络策略
1.限制访问指定服务
vim deny-nginx.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-nginx
spec:
podSelector:
matchLabels:
app: myapp
查看标签:
运行 deny-nginx.yaml清单,查看状态
kubectl apply -f deny-nginx.yaml
kubectl get networkpolicies.
访问IP
kubectl get svc
curl 10.98.183.249
完成之后,删除svc节点
修改svc清单内容再次执行:
cd /root/metallb
vim lb-svc.yaml
apiVersion: v1
kind: Service
metadata:
name: lb-svc
spec:
ports:
- name: http
port: 80
targetPort: 80
selector:
app: myapp
type: LoadBalancer
kubectl apply -f lb-svc.yaml
kubectl get svc
访问生成的IP
cd
kubectl run demo --image=busyboxplus -it --restart=Never
curl 10.107.242.186
2.允许指定pod访问服务:
deny-nginx.yaml文件下面继续添加!
vim deny-nginx.yaml
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: access-nginx
spec:
podSelector:
matchLabels:
app: myapp
ingress:
- from:
- podSelector:
matchLabels:
run: test
执行清单,查看信息,发现多了一条允许的策略!
kubectl apply -f deny-nginx.yaml
kubectl get networkpolicies.
运行一个容器test,使用镜像busyboxplus,标签名为test
kubectl run test --image=busyboxplus -it --labels app=test
查看ip,访问:
发现失败了,是因为标签的名字没有对应一致,更改标签名:
kubectl get pod --show-labels
kubectl label pod test run=test
再次进入容器test,访问IP发现成功了!
kubectl attach test -it
ip addr
curl 10.244.22.2
实验完成之后,将deny-nginx.yaml节点删掉!!
3.禁止 namespace 中所有 Pod 之间的相互访问
vim ns.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
namespace: default
spec:
podSelector: {}
执行ns.yaml清单并查看状态:
kubectl apply -f ns.yaml
kubectl get networkpolicies.
查看详细信息:
kubectl describe networkpolicies.
查看节点的IP地址:
kubectl get pod -o wide
测试:发现内外都不能访问了!!
curl 10.244.22.3
kubectl attach test -it
curl 10.244.22.3
重新创建一个namespace
kubectl create namespace test
kubectl get ns
运行容器查看IP,并访问:
kubectl run test --image=busyboxplus -it -n test
ip addr
curl *****
4.只允许指定namespace访问服务:
在ns.yaml后面添加
vim ns.yaml
---
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: access-namespace
spec:
podSelector:
matchLabels:
app: myapp
ingress:
- from:
- namespaceSelector:
matchLabels:
role: prod
执行ns.yaml文件,进入容器中访问:
访问的时候会发现失败了!
kubectl apply -f ns.yaml
kubectl attach test -it -n test
curl 10.244.22.3
为什么?
因为ns.yaml里面指定的是prod角色,而我们的标签不对所以访问呢不了!
更改标签后再次访问:
kubectl label namespace test role=prod
kubectl get ns --show-labels
但是我们发现外部访问还是不成功,如下图:
kubectl get pod -o wide
curl ********
5.允许外网访问:
修改ns.yaml清单内容!
vim ns.yaml
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: web-allow-external
spec:
podSelector:
matchLabels:
app: myapp
ingress:
- ports:
- port: 80
from: []
执行清单,在外部访问172.25.0.10:
成功!
kubectl apply -f ns.yaml
curl 172.25.0.10