k8s – 测试一下flannel vxlan性能

K8S网络插件的性能损耗到底有多大呢？网上据说损耗30%+，不如亲手验证一下。

云主机配置是ucloud的4核8G普通机器N台，已搭建K8S集群，网络插件flannel vxlan。

确认网络插件

首先确认一下集群的网络插件是不是flannel vxlan：

[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，这个 工具 能同时测试带宽和延时，很容易使用。

需要在其中一端开启服务端监听：

qperf

在另一端开启客户端压测：

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

宿主机->宿主机

tcp_bw:
    bw  =  470 MB/sec
tcp_lat:
    latency  =  61.4 us

带宽470MB/秒，延迟61微秒。

延迟可能受到云主机网络环境影响，仅能拿来大概参考。

宿主机->POD

在node02上启动一个POD运行qperf服务端，这是通过nodeName参数指定调度到node02的：

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：

kubectl exec -it qperf-server-5745f97ccc-cf8sm sh

然后启动qperf服务端：

qperf

然后在node01宿主机上发起到POD的测试：

[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内发起测试。

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：

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"]

现在的布局是：

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做服务端，一个发压。

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：

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的工作原理有关，无法在有负载均衡的情况下正常工作。

failed to receive port: timed out

结论

隧道方案损耗30~40%网络性能的结论准确。

博主无私的分享着知识，你愿意送他一顿热腾腾的早餐吗？