企业运维实战--k8s学习笔记 k8s网络通信、Flannel vxlan模式简介、calico网络插件替换、网络策略范例总结
1.k8s网络通信k8s通过CNI接口接入其他插件来实现网络通讯。目前比较流行的插件有flannel,calico等。CNI插件存放位置:# cat /etc/cni/net.d/10-flannel.conflist插件使用的解决方案如下:虚拟网桥,虚拟网卡,多个容器共用一个虚拟网卡进行通信。多路复用:MacVLAN,多个容器共用一个物理网卡进行通信。硬件交换:SR-LOV,一个物理网卡可以虚拟
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.
重新访问 发现成功访问
更多推荐
所有评论(0)