kubernetes系列之 service代理模式ipvs
2021-02-14 17:19
标签:其他 查看ip running 容器 obs 机制 部分 lan system 环境信息: Service是由kube-proxy组件实现,而kube-proxy支持多种负载均衡机制,今天讲ipvs模式在kubenertes中的应用。 kube-proxy不能动态生效,需要删除kube-proxy,后才会生效 我们写一个测试yml文件 nginx-deploy-svc.yml,如下: 部署 获取svc/deploy/pod 获取svc详情 从上面可以看到访问宿主机+30981 (网络可达宿主机就行),访问 10.243.21.14:8880 (由于是vip,非集群主机不能访问,只能集群内部访问) 时会转发流量到 10.244.3.32:80,10.244.5.23:80,10.244.5.24:80。 那这种转发是如何实现的了? 再查看ipvsadm帮助 可以看到这里ipvs使用的是NAT模式(NAT模式可参考其他文章)。 测试,在172.16.20.120 执行 curl http://10.243.21.14:8880 ,在各机器抓包 172.16.20.121: eth0 , 看到的是 172.16.20.120 -> 172.16.20.121:8472 是flannel进程的端口 , udp ,这里有一个OTV ,可以网上查一查 172.16.20.120: flannel.1 ,和 172.16.20.121 flannel.1看到的是一样的。 再查看nat转发表, 可以看到这是fullnat转发。 另外两台是lvs转发给5.24和5.23的,这是120本地的容器。 执行curl的大致过程如下: 再测试,从121节点上的 busybox容器 telnet 10.243.21.14 8880 kubernetes系列之 service代理模式ipvs 标签:其他 查看ip running 容器 obs 机制 部分 lan system 原文地址:https://www.cnblogs.com/owasp/p/12977792.html
集群网络:10.244.0.0/16
Service网络: 10.243.0.0/16
节点: 172.16.20.120 , 集群网络: 10.244.5.0/24 , cni0: 10.244.5.1/24 ,flannel.1: 10.244.5.0/32
节点: 172.16.20.121 , 集群网络: 10.244.3.0/24 , cni0: 10.244.3.1/24 , flannel.1: 10.244.3.0/32
修改ipvs模式:kubectl edit configmap kube-proxy -n kube-system
mode: "ipvs"
kubectl delete pod kube-proxy-xxx -n kube-system
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: lvs-test
name: lvs-deploy-test
spec:
replicas: 3
selector:
matchLabels:
app: lvs-test
template:
metadata:
labels:
app: lvs-test
spec:
containers:
- image: nginx
name: lvs-pod-test
restartPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
labels:
app: lvs-test
name: lvs-svc-test
spec:
ports:
- port: 8880
protocol: TCP
targetPort: 80
selector:
app: lvs-test
type: NodePort
kubectl apply -f nginx-deploy-svc.yml
# kubectl get svc,pod,deploy -l app=lvs-test -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
service/lvs-svc-test NodePort 10.243.21.14
# kubectl describe service/lvs-svc-test
Name: lvs-svc-test
Namespace: default
Labels: app=lvs-test
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app":"lvs-test"},"name":"lvs-svc-test","namespace":"default"},...
Selector: app=lvs-test
Type: NodePort
IP: 10.243.21.14
Port:
我们查看lvs# ipvsadm -L -n (省略部分输出)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.243.21.14:8880 rr
-> 10.244.3.32:80 Masq 1 0 0
-> 10.244.5.23:80 Masq 1 0 0
-> 10.244.5.24:80 Masq 1 0 0
# ipvsadm -L -n
--gatewaying -g gatewaying (direct routing) (default) # DR
--ipip -i ipip encapsulation (tunneling) # TUN
--masquerading -m masquerading (NAT) # NAT
# man ipvsadm
rr - Round Robin: distributes jobs equally amongst the available real servers. # 轮询
172.16.20.121:flannel.1 , 看到的是10.244.5.0 -> 10.244.3.32:80120机器
请求发起:10.243.21.14:48480->10.243.21.14:8880
IPVS-轮询,目标为:10.244.3.32:80
根据路由表,下一跳为 10.244.3.0 ,出口为flannel.1 ,flannel.1的ip地址为10.244.5.0 #10.244.3.0 10.244.3.0 255.255.255.0 UG 0 0 0 flannel.1
根据FULLNAT:10.244.5.0:48480->10.244.3.32:80 (称为:原始包), 并记录nat表。# ipv4 2 tcp 6 112 TIME_WAIT src=10.243.21.14 dst=10.243.21.14 sport=48480 dport=8880 src=10.244.3.32 dst=10.244.5.0 sport=80 dport=48480 [ASSURED] mark=0 zone=0 use=2
根据etcd学习到的 10.244.3.0的mac地址为ee:d6:38:55:d5:c7 ,封装vxlan , 包格式: vni| 10.244.5.0的mac , 10.244.3.0的mac | 原始ip包 。 (称为:vxlan包) # 10.244.3.0 ether ee:d6:38:55:d5:c7 CM flannel.1
根据etcd学习到 10.244.3.0在172.16.20.121节点, 封装udp包, udp端口 8472. 包格式: udp封装部分 | xvxlan包 。
121机器收到包,过程也一样,目标为121,接收,端口为 8472 ,接收 , 解封装, 目标mac为3.0的,接收,解封装,目标为 3.32 ,到达目的地。 反包这里就不再抒写了。
120接到回包解封装后,为10.243.3.32:80 -> 10.244.5.0:48480 ,寻找NAT标, 转发给 10.243.21.14L48480, curl进程接收,
结束。
在121节点, flannel.1抓包, 看到的是10.244.3.10:59528 (busybox) -> 10.244.5.23:80
在121节点,查看nat表
在120节点,eth0抓包,172.16.20.121.50813 > 172.16.20.120.8472 , 有一层udp封装
这里只做了目标地址转换, 因为10.244.3.10在各节点是可达的(通过flannel网络可达)
文章标题:kubernetes系列之 service代理模式ipvs
文章链接:http://soscw.com/essay/55273.html