CN112073330A

CN112073330A - 一种云平台容器网络限流方法

Info

Publication number: CN112073330A
Application number: CN202010908624.9A
Authority: CN
Inventors: 王博学; 李彦君; 胡章丰; 任秋峥
Original assignee: Inspur Cloud Information Technology Co Ltd
Current assignee: Inspur Cloud Information Technology Co Ltd
Priority date: 2020-09-02
Filing date: 2020-09-02
Publication date: 2020-12-11

Abstract

本发明特别涉及一种云平台容器网络限流方法。该云平台容器网络限流方法，使用Open vSwitch插件实现流量限制及流量整形，通过CNI插件为创建的Pod设置不同级别的限流措施，对单一Pod的Policing管制和Shaping整形进行配置，以支持不同网络插件的情景。该云平台容器网络限流方法，提供了公有云平台下容器网络的租户级别的流量限制，根据本身网络类型及特性，通过统一的组件进行配置，符合CNI接口标准，同时还根据需求定义了多种admission webhook，具备良好的健壮性和可扩展性。

Description

一种云平台容器网络限流方法

技术领域

本发明涉及容器和计算机网络技术领域，特别涉及一种云平台容器网络限流方法。

背景技术

虚拟化技术已经成为一种被大家广泛认可的服务器资源共享方式，它可以在按需构建操作系统实例的过程当中为系统管理员提供极大的灵活性。由于hypervisor虚拟化技术仍然存在一些性能和资源使用效率方面的问题，因此出现了一种称为容器(Container)的新型虚拟化技术来帮助解决这些问题。

容器的出现使网络拓扑变得更加动态和复杂，用户需要专门的解决方案来管理容器与容器，容器与其他实体之间的连通性和隔离性。Docker network是Docker原生的网络解决方案。除此之外，还可以采用第三方开源解决方案，例如flannel、weave和calico。不同的方案设计和实现方式不同，各有优势和特定，可以根据实际需要来选型。

无论目标是搭建公有云的容器云平台还是为客户提供容器平台的私有部署或解决方案，用户都会面临一个问题：容器网络限流的问题。在实验环境下，如果没有对容器带宽进行限制，单Pod使用的最大吞吐量将可以独占整个带宽，从而导致其他应用不能被访问。

如今，生产环境下需要为“上云”的应用提供流量带宽保证，使其不受到其他应用或其他用户的应用的影响。因此用户需要提供租户级别或者应用级别的有效隔离。通常情况下，可以根据VNID实现租户间的网络隔离，同时还可以根据Network policy网络策略提供更细粒度的网络隔离，从而实现Pod之间、跨Name space的网络访问控制。

综上所述，网络限流现已成为容器网络的一个重要环节，为数据中心网络资源的公平使用、保障用户业务质量、保护用户权益等方面具有极其重要的意义。目前云计算平台的实现机制缺乏足够的灵活性和可扩展性，不能针对租户级别为其添加限流配置，存在单一Pod独占带宽、网络阻塞的风险。

针对目前在容器平台网络限流的问题，本发明提出了一种云平台容器网络限流方法。

发明内容

本发明为了弥补现有技术的缺陷，提供了一种简单高效的云平台容器网络限流方法。

本发明是通过如下技术方案实现的：

一种云平台容器网络限流方法，其特征在于：使用Open vSwitch插件实现流量限制及流量整形，通过CNI(Container Network Interface，集群网络接口)插件为创建的Pod设置不同级别的限流措施，对单一Pod的Policing管制和Shaping整形进行配置，以支持不同网络插件的情景。

在Kubernetes上，使用Open vSwitch CNI插件，创建Pod资源时在iperf-pod.yaml中为其配置速率限制，通过Admission webhook组件实现租户层级控制。

所述Admission webhook组件根据公有云平台中的租户等级，为创建的Pod设置不同级别的流量限制。

该云平台容器网络限流方法，包括以下步骤：

S1.Pod.yaml包含限流配置请求到达Kubernetes API Server；

S2.Kubernetes API Server将具体配置转发到Kbelet的CNI network driver；

S3.CNI network driver生成一份Network plugin configlist；

S4.调用CNI API唤起CNI plugin；

S5.最终通过Linux内核自带的Linux TC(Traffic-Control)机制进行流量控制。

所述步骤S2中，通过自研组件bandwidth-inject-webhook对网络限流配置进行管理。

所述Linux TC(Traffic-Control)机制进行流量控制，包括Policing管制和Shaping整形两种实现方式：

所述Policing管制用于控制接口上接收分组(ingress)的速率，是一种简单的QoS(Quality of Service，服务质量)的功能，通过简单的丢包机制实现接口速率的限制，既可以作用于物理接口，也可以作用于虚拟接口；

所述Shaping整形是作用于接口上的出口流量(egress)策略，可以实现多个QoS队列，在不同队列里面处理不同策略。

所述Policing管制在Open vSwitch中采用ingress_policing_rate(最大收包速率)和ingress_policing_burst(最大突发流量大小)两个字段完成ingress入口限速功能，所述ingress_policing_rate字段和ngress_policing_burst字段放在Interface表中。

所述Shaping整形用于实现出口流量的控制，使用队列queue缓存和调度数据包发送顺序，比policing管制更加精确和有效，在Open vSwitch的数据表中使用QoS和Queue两张表。

本发明的有益效果是：该云平台容器网络限流方法，提供了公有云平台下容器网络的租户级别的流量限制，根据本身网络类型及特性，通过统一的组件进行配置，符合CNI接口标准，同时还根据需求定义了多种admission webhook(主要应用于验证及修改)，具备良好的健壮性和可扩展性。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

附图1为本发明云平台容器网络限流方法示意图。

具体实施方式

为了使本技术领域的人员更好的理解本发明中的技术方案，下面将结合本发明实施例，对本发明实施例中的技术方案进行清楚，完整的描述。显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

该云平台容器网络限流方法，使用Open vSwitch插件实现流量限制及流量整形，通过CNI(Container Network Interface，集群网络接口)插件为创建的Pod设置不同级别的限流措施，对单一Pod的Policing管制和Shaping整形进行配置，以支持不同网络插件的情景。

Kubernetes(简称K8S)是开源的容器集群管理系统，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。

该云平台容器网络限流方法，包括以下步骤：

S1.Pod.yaml包含限流配置请求到达Kubernetes API Server；

S2.Kubernetes API Server将具体配置转发到Kbelet的CNI network driver；

S3.CNI network driver生成一份Network plugin configlist；

S4.调用CNI API唤起CNI plugin；

Open vSwitch本身不实现QoS，它使用Linux内核自带的traffic-control机制进行流量控制。

命令示例如下：

#ovs-vsctl set interface eth1 ingress_policing_rate＝1000

#ovs-vsctl set interface eth1 ingress_policing_burst＝100

通过命令ovs-vsctl list interface eth1可以查看配置

具体执行流程如下：

1)QoS创建命令

#ovs-vsctl set port eth1 qos＝@newqos--

--id＝@newqoscreate qos type＝linux-htb queues＝0＝@q0--

--id＝@q0create queue other-config:max-rate＝100000000

2)创建Queue

--id＝@q0 create queue other-config:max-rate＝100000000

3)创建Qos规则

--id＝@newqos create qos type＝linux-htb queues＝0＝@q0

在Kubernetes上，使用Open vSwitch CNI插件，在创建Pod资源的时候为其配置速率限制，具体执行流程如下：

1)创建iperf-pod.yaml，并为其配置速率限制:

cat<<EOF>iperf-pod.yaml

apiVersion:v1

kind:Pod

metadata:

name:iperf

annotations:

kubernetes.io/ingress-bandwidth:3M

kubernetes.io/egress-bandwidth:3M

spec:

containers:

-name:iperf

image:yadu/hello-openshift-iperf

imagePullPolicy:IfNotPresent

nodeSelector:

zone:default

EOF

2)流入测试：

pod容器里启动iperf server

#iperf -s -p 12345 -i 1

Server listening on TCP port 12345

TCP window size:85.3 KByte(default)

在任意节点向iperf server产生流量

#iperf -c 10.130.2.103 -p 12345 -i 1 -t 10 -w 5m

Client connecting to 10.130.2.103,TCP port 12345

TCP window size:416 KByte(WARNING:requested 4.77 MByte)

[3]local 10.130.2.1 port 58162 connected with 10.130.2.103 port 12345

[ID]Interval Transfer Bandwidth

[3]0.0-1.0sec 773KBytes 6.33Mbits/sec

[3]1.0-2.0sec 316KBytes 2.59Mbits/sec

[3]2.0-3.0sec 314KBytes 2.57Mbits/sec

(omitted)

查看pod里流入的日志

#iperf -s -p 12345 -i 1

Server listening on TCP port 12345

TCP window size:85.3KByte(default)

[4]local 10.130.2.103port 12345 connected with 10.130.2.1 port 58162

[ID]Interval Transfer Bandwidth

[4]0.0-1.0sec 354KBytes 2.90Mbits/sec

[4]1.0-2.0sec 351KBytes 2.87Mbits/sec

[4]2.0-3.0sec 349KBytes 2.86Mbits/sec

(omitted)

3)流出测试：

在任意节点上启动iperf server作为测试

#iperf -s -p 12345 -i 1

Server listening on TCP port 12345

TCP window size:85.3KByte(default)

pod中用iperf client进行测试

#iperf -c 172.18.143.117 -p 12345 -i 1-t 10 -w 5m

Client connecting to 172.18.143.117,TCP port 12345

TCP window size:416KByte(WARNING:requested 5.00MByte)

[3]local 10.130.2.103port 44602 connected with 172.18.143.117 port12345

[ID]Interval Transfer Bandwidth

[3]0.0-1.0sec 1.62MBytes 13.6Mbits/sec

[3]1.0-2.0sec 384KBytes 3.15Mbits/sec

[3]2.0-3.0sec 384KBytes 3.15Mbits/sec

(omitted)

查看node4上流入的日志

#iperf -s -p 12345 -i 1

Server listening on TCP port 12345

TCP window size:85.3KByte(default)

[4]local 172.18.143.117 port 12345 connected with 10.130.2.103 port44602

[ID]Interval Transfer Bandwidth

[4]0.0-1.0sec 1.28MBytes 10.7Mbits/sec

[4]1.0-2.0sec 373KBytes 3.05Mbits/sec

[4]2.0-3.0sec 380KBytes 3.11Mbits/sec

(omitted)

查看tc的配置

#tc-s-d class show dev vethddb66bac

class htb 1:1 parent 1:fffe prio 0 quantum 1450 rate 11600bit ceil3000Kbit burst 1513b/1mpu 0b overhead 0b cburst 1513b/1 mpu 0b overhead 0blevel 0

Sent 0 bytes 0pkt(dropped 0,overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended:0 borrowed:0 giants:0

tokens:16314655 ctokens:63083

class htb 1:fffe root rate 3000Kbit ceil 3000Kbit burst 1449b/1mpu 0boverhead 0b cburst1449b/1 mpu 0b overhead 0b level 7

Sent 4187548 bytes 2872 pkt(dropped 0,overlimits 0 requeues 0)

rate 0bit 0pps backlog 0b 0p requeues 0

lended:998 borrowed:0 giants:0

tokens:60416 ctokens:6041

最后，通过组件bandwidth-inject-webhook，完成以上创建流程，增加网络限流配置。

组件架构：getAdmissionDecision

patchConfig

以上所述的实施例，只是本发明具体实施方式的一种，本领域的技术人员在本发明技术方案范围内进行的通常变化和替换都应包含在本发明的保护范围内。

Claims

1.一种云平台容器网络限流方法，其特征在于：使用Open vSwitch插件实现流量限制及流量整形，通过CNI插件为创建的Pod设置不同级别的限流措施，对单一Pod的Policing管制和Shaping整形进行配置，以支持不同网络插件的情景。

2.根据权利要求1所述的云平台容器网络限流方法，其特征在于：在Kubernetes上，使用Open vSwitch CNI插件，创建Pod资源时在iperf-pod.yaml中为其配置速率限制，通过Admission webhook组件实现租户层级控制。

3.根据权利要求2所述的云平台容器网络限流方法，其特征在于：所述Admissionwebhook组件根据公有云平台中的租户等级，为创建的Pod设置不同级别的流量限制。

4.根据权利要求2或3所述的云平台容器网络限流方法，其特征在于，包括以下步骤：

S1.Pod.yaml包含限流配置请求到达Kubernetes API Server；

S2.Kubernetes API Server将具体配置转发到Kbelet的CNI network driver；

S3.CNI network driver生成一份Network plugin configlist；

S4.调用CNIAPI唤起CNI plugin；

S5.最终通过Linux内核自带的Linux TC机制进行流量控制。

5.根据权利要求4所述的云平台容器网络限流方法，其特征在于：所述步骤S2中，通过自研组件bandwidth-inject-webhook对网络限流配置进行管理。

6.根据权利要求5所述的云平台容器网络限流方法，其特征在于：所述Linux TC机制进行流量控制，包括Policing管制和Shaping整形两种实现方式：

所述Policing管制用于控制接口上接收分组的速率，是一种简单的QoS的功能，通过简单的丢包机制实现接口速率的限制，既可以作用于物理接口，也可以作用于虚拟接口；

所述Shaping整形是作用于接口上的出口流量策略，可以实现多个QoS队列，在不同队列里面处理不同策略。

7.根据权利要求6所述的云平台容器网络限流方法，其特征在于：所述Policing管制在Open vSwitch中采用ingress_policing_rate和ingress_policing_burst两个字段完成ingress入口限速功能，所述ingress_policing_rate字段和ngress_policing_burst字段放在Interface表中。

8.根据权利要求6所述的云平台容器网络限流方法，其特征在于：所述Shaping整形用于实现出口流量的控制，使用队列queue缓存和调度数据包发送顺序，比policing管制更加精确和有效，在Open vSwitch的数据表中使用QoS和Queue两张表。