k8s – 测试一下flannel vxlan性能
K8S网络插件的性能损耗到底有多大呢？网上据说损耗30%+，不如亲手验证一下。
云主机配置是ucloud的4核8G普通机器N台，已搭建K8S集群，网络插件flannel vxlan。
确认网络插件
首先确认一下集群的网络插件是不是flannel vxlan：
|
1 2 3 4 5 6 7 8 |
[root@node01 ~]# kubectl get nodes node01 -o yaml apiVersion: v1 kind: Node metadata: annotations: flannel.alpha.coreos.com/backend-data: '{"VtepMAC":"de:95:3c:79:30:36"}' flannel.alpha.coreos.com/backend-type: vxlan flannel.alpha.coreos.com/kube-subnet-manager: "true" |
测试命令
需要大家yum install qperf，这个工具能同时测试带宽和延时，很容易使用。
需要在其中一端开启服务端监听：
|
1 |
qperf |
在另一端开启客户端压测：
|
1 |
qperf -t 10 10.42.158.21 tcp_bw tcp_lat |
这个命令是意思是：
- 运行10秒
- 服务端IP：10.42.158.21
- 测试TCP协议的极限带宽：tcp_bw
- 测试TCP协议的延迟：tcp_lat
接下来，我要测几个场景：
- 宿主机 -> 宿主机
- 宿主机 -> POD
- POD -> 宿主机
- POD -> POD
- POD -> Service
宿主机->宿主机
|
1 2 3 4 |
tcp_bw: bw = 470 MB/sec tcp_lat: latency = 61.4 us |
带宽470MB/秒，延迟61微秒。
延迟可能受到云主机网络环境影响，仅能拿来大概参考。
宿主机->POD
在node02上启动一个POD运行qperf服务端，这是通过nodeName参数指定调度到node02的：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
apiVersion: apps/v1 kind: Deployment metadata: name: qperf-server labels: app: qperf-server spec: replicas: 1 selector: matchLabels: app: qperf-server template: metadata: labels: app: qperf-server spec: nodeName: node02 containers: - name: centos image: centos:latest command: ["/bin/sh","-c","while true;do sleep 1;done"] |
进入qperf-server：
|
1 |
kubectl exec -it qperf-server-5745f97ccc-cf8sm sh |
然后启动qperf服务端：
|
1 |
qperf |
然后在node01宿主机上发起到POD的测试：
|
1 2 3 4 5 |
[root@node01 ~]# qperf -t 10 10.244.1.96 tcp_bw tcp_lat tcp_bw: bw = 302 MB/sec tcp_lat: latency = 77 us |
网络性能损耗：36%。
POD到宿主机
在node01宿主机上启动服务端：qperf，在node02的POD内发起测试。
|
1 2 3 4 5 |
sh-4.2# qperf -t 10 10.42.48.58 tcp_bw tcp_lat tcp_bw: bw = 530 MB/sec tcp_lat: latency = 71 us |
网络性能损耗：12%，应该是因为只需要在宿主机走NAT即可，不需要做flannel vxlan，同样的目标宿主机看到的对端IP是物理IP而不是POD IP。
POD到POD
再启动一个POD，让它运行到node03：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
apiVersion: apps/v1 kind: Deployment metadata: name: qperf-client labels: app: qperf-client spec: replicas: 1 selector: matchLabels: app: qperf-client template: metadata: labels: app: qperf-client spec: nodeName: node03 containers: - name: centos image: centos:latest command: ["/bin/sh","-c","while true;do sleep 1;done"] |
现在的布局是：
|
1 2 |
qperf-client-854d7b7c6d-qdq54 1/1 Running 0 129m 10.244.2.13 node03 <none> <none> qperf-server-5745f97ccc-cf8sm 1/1 Running 0 3h21m 10.244.1.96 node02 <none> <none> |
然后一个POD做服务端，一个发压。
|
1 2 3 4 5 |
sh-4.2# qperf 10.244.1.96 tcp_bw tcp_lat tcp_bw: bw = 299 MB/sec tcp_lat: latency = 81.8 us |
网络性能损耗：36%。
POD到service
创建到qperf-server的service：
|
1 2 3 4 5 6 7 8 9 10 11 |
kind: Service apiVersion: v1 metadata: name: qperf-service spec: selector: app: qperf-server ports: - protocol: TCP port: 19765 targetPort: 19765 |
qperf监听的默认端口就是19765。
然后从qperf-client的POD压这个service，结果发现压测报错，可能与qperf的工作原理有关，无法在有负载均衡的情况下正常工作。
|
1 |
failed to receive port: timed out |
结论
隧道方案损耗30~40%网络性能的结论准确。
如果文章帮助您解决了工作难题，您可以帮我点击屏幕上的任意广告，或者赞助少量费用来支持我的持续创作，谢谢~
