Network QoS

[l1b0k]

User Story

Story 1

集群管理员希望大带宽的容器，调度到不同节点上，避免单节点/机框拥塞。

Story 2

集群管理员希望提高资源利用率，在节点上同时部署在线、离线业务。

当网络资源空闲时，让离线业务尽可能使用节点带宽。

当网络资源争抢时，可以优先保证在线业务网络资源，同时也照顾离线业务不被饿死。

Story 3

当节点容器出现严重带宽争抢，管理员可以在不重建 Pod 情况下，临时调整单个 Pod 带宽限制。

Proposal

Koordinator 通过 QoS 策略，实现网络资源的优先级管理。具体包含：

• 调度方面，感知网络带宽，避免单节点/机框拥塞。
• 配置定义，定义网络优先级，以及带宽限制。
• 运行时，实时感知网络带宽，根据 QoS 策略，限制 Pod 带宽。支持plugin 方式，使用不同插件实现限速。

带宽限制的考虑

带宽限制考虑两个场景

• 整机带宽限制
• Pod带宽限制

整机带宽限制

混部场景下，节点上流量具备不同的优先级，我们假定有三个优先级，分别为 L0, L1, L2，优先级依次降低。
对一个节点，当机器带宽达到底层限制时，将会产生丢包、重传，影响整体网络性能，我们将这种状态称为争抢。

具体的：争抢场景定义： 当 L0 + L1 + L2 总流量大于整机带宽

由此我们可以定义一种限制策略：

L0 最大带宽依据 L1， L2 实时流量而动态调整。最大为整机带宽，最小为 整机带宽- L1 最小带宽- L2 最小带宽。
任何情况下，L1、L2 其带宽不超过各自带宽上限。
争抢场景下， L1、L2 其带宽不会低于各自带宽下限。
争抢场景下，将按照 L2 、L1 、L0 的顺序对带宽进行限制。

Pod 带宽限制

Pod 带宽限制只对该 Pod 有效，只设置 Pod 所对应的上限、下限。

依据QoS实现的不同，HostNetwork Pod 可能无法支持。

流量分类

一般的场景下，我们流量限制的维度是 Pod，特殊场景下，需要对 Pod 内流量做进一步的限制，比如对某个 Pod 的某个端口做限制。又比如对特定的流量做 DSCP 打标。

网络QoS 接口

• 网络优先级

网络优先级

设计了三个网络优先级,可以使用默认的 Koordinator QoS 等级或者为 pod 单独指定网络优先级
默认的QoS 等级关系如下：

Koordinator QoS	Kubernetes QoS	Koordinator Net QoS
SYSTEM	--	L0
LSE	Guaranteed	L1
LSR	Guaranteed	L1
LS	Guaranteed/Burstable	L1
BE	BestEffort	L2

定义下面的 Pod annotation

Koordinator Net QoS	annotations
L0	koordinator.sh/net-qos-class: l0
L1	koordinator.sh/net-qos-class: l1
L2	koordinator.sh/net-qos-class: l2

caseinsensitive

Pod 带宽限制

整Pod 维度的带宽限制

pod bandwidth
koordinator.sh/ingress-bandwidth
koordinator.sh/egress-bandwidth

节点混部带宽配置

在 NodeSLO 中，为每个节点定义机器带宽限制，以及各个优先级的带宽上下限。

apiVersion: slo.koordinator.sh/v1alpha1
kind: NodeSLO
metadata:
  name: test-node
spec:
  networkQOSStrategy:
    enable: true
    nodeBandwidthLimit:
      hw:
        tx: 1000
        rx: 1000
      l0:
        tx: 1000
        rx: 1000
      l1:
        tx: 1000
        rx: 1000
      l2:
        tx: 1000
        rx: 1000

Pod 配置

Pod 配置目标能提供Pod内细粒度的带宽控制能力，通过 pod annotation 来定义。

配置内容包含

• matchs: 匹配规则
• actions: 匹配规则命中后，执行的动作

pod bandwidth
koordinator.sh/qos-config

{
    "ingress": [
        {
            "matchs": [{
                "type": "ip"
            }],
            "actions": [
                {
                    "action": "qos-class",
                    "value": "l1",
                }
            ],
        }
    ],
    "egress": [
         {
            "matchs": [{
                "type": "port",
                "expr": "=80"
            }],
            "actions": [
                {
                    "action": "qos-class",
                    "value": "l1",
                },
                {
                    "action": "dscp",
                    "value": "",
                },
                {
                    "action": "bandwidth_min",
                    "value": "1000",
                },
                {
                    "action": "bandwidth_max",
                    "value": "1000",
                }
            ],
        }
    ]
}

koorlet 配置同步

• QoS 实现各异，koordlet 将提供一种统一的  API 界面，由各组件自行实现 QoS 细节

// /var/run/koordinator/net/pods
{
  "cgroup":"/sys/fs/cgroup/xxxx",
  "priority":0,
  "pod":"namespacedname",
  "podUID":"xxx",
  "qos-config": {}
}

• 节点混部 QoS 配置:

// /var/run/koordinator/net/node
{
  "hw_tx_bps_max": 0,
  "hw_rx_bps_max": 0,
  "l1_tx_bps_min": 0,
  "l1_tx_bps_max": 0,
  "l2_tx_bps_min": 0,
  "l2_tx_bps_max": 0,
  "l1_rx_bps_min": 0,
  "l1_rx_bps_max": 0,
  "l2_rx_bps_min": 0,
  "l2_rx_bps_max": 0
}

[l1b0k]

hi , i would like to discuee the qos api @lucming

[lucming]

wow, it's awesome !

[lucming]

Recently, i've been verifying some of the functionality of terway-qos on our test machine, i just meet some issues, and i will try to fix them, maybe we should make sure terway-qos works well first, WDYT?

[zwzhang0107]

that sounds great! I'd like join you guys anytime once the meeting set up

[zwzhang0107]

关于koordinator的配置有几个建议可以参考：

1. 整机/QoS等级的配置，可以直接参考现在NodeSLO的ResourceQoS和SystemStrategy做扩展

比如在NetworkQOS里为LS/BE定义网络的request/limit（和cpu/memory的描述类似），对应到底层的min/max实现。

type NetworkQOS struct {
// 入
IngressBpsRequest *intOrString(percent)
IngressBpsLimit *intOrString(percent)
// 出..
// DSCPVal *int64 json:"DSCPVal,omitempty"
}

整机级别的可以在SystemStrategy里定义
type SystemStrategy struct {
TotalBandwidth string
}

2. pod级别的细粒度配置可以支持两种
   a. 不使用默认的QoS配置，指定bpsReq/Limit：koordinator.sh/networkQOS: {"IngressBpsLimit": ""}，这里是不是只能允许填limit了，不然单个pod会影响L0的可用量，ingress-bandwidth/egress-bandwidth这种作为简单一点的“语法糖”，后续的扩展放都放到结构化的协议里。
   b. 端口级别的可以作为远期规划
   networkQoS的等级直接和qosClass=LS/BE映射，pod级别先不对外提供修改的能力吧（比如qosClass=BE，networkQOSClass=LS这种）

3. /var/run/koordinator/net/pods里，priority对应的是l0/l1/l2的意思么，有些配置是不是可以忽略的（比如podname，uid），感觉只配cgroup和priority好像就可以了，qos-config指的是pod级别细粒度的limit限制吧。
   "cgroup":"/sys/fs/cgroup/xxxx",
   "priority":0,
   "pod":"namespacedname",
   "podUID":"xxx",
   "qos-config": {}

[l1b0k]

我描述下设计的考虑

2. Pod 维度的配置
   考虑了几种情况，以比较通用方式来做配置
   a. 仅限制 Pod 整体带宽（ 最为常见） ，可配置 matchs (type=ip) + actions ( bandwidth_max ) 这样的配置
   b. 对于容器内细粒度扩展（修改 dscp ，修改优先级，匹配端口）， 也可通过这种 matchs + actions 方式来做

为什么把结构化内容放到 Pod annotations 中 ？
将 anno 中这个字段作为 API，是直观、直接的，可具备直接修改能力。 当然这个结构也带来了复杂性，若用户仅配置Pod 带宽，则不那么直观。

[zwzhang0107]

我也赞同annotation里用结构化的形式，actions的格式可以和struct NetworkQOS对齐。
那看起来独立的annnotation就不需要支持了koordinator.sh/egress-bandwidth。

[zwzhang0107]

1212
1、Koordiantor QoS：System、LS、BE；network level：L0/L1/L2。
不开启网络QoS时，表现是各Koordiantor QoS的Pod不限速，出现争抢时按默认的平均公平性。在实现上，需要默认将Pod的level等级都映射到L0？
开启网络QoS时，表现如上所述，按网络“request/limit”限速和保障。在实现上，默认将System=>L0, LS=>L1, BE=>L2，也可以修改默认的映射关系为其他形式，比如System=>L0，LS=>L0, BE=>L2。
Pod单独开启网络QoS时，可以对自己单独限速（只有limit），koordlet插件不用理解merge，直接透传到底层配置文件。

2、System/LS/BE的默认值，整机带宽
整机带宽：默认值从默认路由读取（待确定？），可以自定义配置（TotalBandwidth string）
System/LS/BE
type NetworkQOS struct {
// 入
IngressBpsRequest *intOrString(percent) System:40%,LS:30%,BE:30%
IngressBpsLimit *intOrString(percent) 100%
}

3. koordlet->terway qos配置
   参考定义设计一下配置。

接下来的工作：
1、社区proposal @lucming
2、terway qos的研发 @l1b0k ：改为直接读本地文件
3、功能研发
a、api定义 @lucming
b、koordlet插件适配 @l1b0k

后续远期规划：
1、网络感知的调度/重调度
2、基于网络水位的驱逐策略
3、内置的基于tc实现的network qos插件

双周会：周二3-4点，下次26号

[zwzhang0107]

接下来的工作：
1、社区proposal @lucming ：端口级别的设计可以放到远期规划，第一版先不包括。下周社区周会时介绍一下。
2、terway qos的研发 @l1b0k ：改为直接读本地文件，先基于目前的设计开始内部研发；配置文件读写部分待proposal合入后研发 doing
3、功能研发
a、api定义 @lucming 包括proposal中
b、koordlet插件适配 @l1b0k TODO，runtimehooks里增加一个插件networkqos

后续远期规划：
1、网络感知的调度/重调度
2、基于网络水位的驱逐策略
3、内置的基于tc实现的network qos插件，评估一下研发复杂度 @lucming

双周会：周二3-4点，下次26号

[zwzhang0107]

接下来的工作：
1、社区proposal @lucming ：社区周会宣讲完成，部分章节的结构需要调整下（有些配置的描述和terway qos混在一起了）
2、terway qos的研发 @l1b0k ：改为直接读本地文件，配置文件读写部分研发完成，待测试
3、功能研发
a、api定义 @lucming 包括proposal中，已提交review中
b、koordlet插件适配 @l1b0k，runtimehooks里增加一个插件networkqos，研发中，本周可以测试，可以先发出来review下
c、api相关的validate需要考虑单位、格式等等 @lucming
4、测试相关
下周开始进入整体测试阶段

TODO：
1、文档结构的调整 @lucming
2、terway qos和korodlet插件的测试，初版代码 @l1b0k

后续远期规划：
1、网络感知的调度/重调度
2、基于网络水位的驱逐策略
3、内置的基于tc实现的network qos插件，评估一下研发复杂度 @lucming

双周会：周二3-4点，下次23号

[zwzhang0107]

1. 社区proposal @lucming ：已合入
2. terway qos的研发 @l1b0k ：改为直接读本地文件，配置文件读写部分研发完成，待测试
3. 功能研发

• api定义 @lucming 已合入
• koordlet插件适配 @l1b0k，runtimehooks里增加一个插件networkqos，研发中（LS/BE）；<os/host process->相当于L0的效果、L0（Pod System）、L1（/LSE/LSR/LS）、L2（BE）>
• api相关的validate需要考虑单位、格式等等 @lucming，已经提交，PR中

4. 测试相关

下两周重点事项：

1. 文档结构的调整 @lucming done
2. terway qos和korodlet插件的测试，初版代码，大概年前发PR @l1b0k
3. 基于tc实现的network qos插件，对接到新的api @lucming

后续远期规划：
1、网络感知的调度/重调度
2、基于网络水位的驱逐策略
3、pod级别通过annotation指定in/egress的limit限制，terway qos支持通过配置文件为pod设定

双周会：周二3-4点，下次2.21号

[zwzhang0107]

1. terway qos的研发 @l1b0k ：改为直接读本地文件，配置文件读写部分研发完成，测试完成
2. 功能研发

• koordlet插件适配 @l1b0k，runtimehooks里增加一个插件networkqos，研发中（LS/BE）；<os/host process->相当于L0的效果、L0（Pod System）、L1（/LSE/LSR/LS）、L2（BE）>，PR中
• api相关的validate需要考虑单位、格式等等 @lucming，已经合入1个，另一在PR中

3. 测试相关

下两周重点事项：

1. terway qos和korodlet插件的测试中，UT覆盖率补充 @l1b0k
2. 基于tc实现的network qos插件，对接到新的api，研发中 @lucming
3. terway qos插件监控指标：internal_metrics.go

后续远期规划：
1、网络感知的调度/重调度
2、基于网络水位的驱逐策略
3、pod级别通过annotation指定in/egress的limit限制，terway qos支持通过配置文件为pod设定（目前已经支持pod级别，端口等细节暂不支持）

最佳实践讨论：

1. terway 插件 + 高版本内核 => terway qos
2. flannel 插件 + 低版本内核 => TC方案
3. flannel 插件 + 高版本内核 => 待定（TC？）

双周会：周二3-4点，下次3.5号

[zwzhang0107]

1、terway qos的研发 @l1b0k ：改为直接读本地文件，配置文件读写部分研发完成，已经合入 close

2、koordinator功能研发
a. koordlet插件适配 @l1b0k，runtimehooks里增加一个插件networkqos，研发中（LS/BE）；<os/host process->相当于L0的效果、L0（Pod System）、L1（/LSE/LSR/LS）、L2（BE）>，已合入
b. api相关的validate需要考虑单位、格式等等 @lucming，已经合入1个（单个），另一在PR中（总量不超），已合入

3、测试相关，terway qos + koordlet自测完成

4、terway qos和korodlet插件的测试中，UT覆盖率补充 @l1b0k 已合入

下两周重点事项：

1、基于tc实现的network qos插件，对接到新的api，研发中，proposal和代码拆分一下 @lucming
2、terway qos插件监控指标：internal_metrics.go 待研发
3、最佳实践文档《使用terway qos和koordiantor实现Network QoS机制》 @l1b0k https://koordinator.sh/zh-Hans/docs/

后续远期规划：
1、网络感知的调度/重调度
2、基于网络水位的驱逐策略
3、pod级别通过annotation指定in/egress的limit限制，terway qos支持通过配置文件为pod设定（目前已经支持pod级别，端口等细节暂不支持）

最佳实践讨论：整理一下放到最佳实践的文档里
terway 插件 + 高版本内核 => terway qos
flannel 插件 + 低版本内核 => TC方案
flannel 插件 + 高版本内核 => 待定（TC？）

其他议题：

双周会：周二3-4点，下次3.26号

[zwzhang0107]

上下行带宽互相影响

[zwzhang0107]

1、基于tc实现的network qos插件，对接到新的api，研发中，proposal更新完成，代码修改中 @lucming
2、terway qos插件监控指标：internal_metrics.go 待研发
3、最佳实践文档《使用terway qos和koordiantor实现Network QoS机制》 @l1b0k https://koordinator.sh/zh-Hans/docs/

• koordiantor helm chart更新完成，待提交PR
• website文档中文版本完成，待提交
• 内核版本和插件类型的最佳介绍
  4、上下行带宽区别，总量应该一致，全双工情况应该互不影响（云上云下都是这样）

后续远期规划：
1、网络感知的调度/重调度
2、基于网络水位的驱逐策略
3、pod级别通过annotation指定in/egress的limit限制，terway qos支持通过配置文件为pod设定（目前已经支持pod级别，端口等细节暂不支持）

其他议题：

双周会：周二3-4点，下次4.9号

[zwzhang0107]

1、基于tc实现的network qos插件，对接到新的api，研发中，proposal更新完成，代码修改完成，待补充UT，自测ok @lucming
2、terway qos插件监控指标：internal_metrics.go 待研发
3、最佳实践文档《使用terway qos和koordiantor实现Network QoS机制》 @l1b0k https://koordinator.sh/zh-Hans/docs/，社区周会简单介绍一下
4、koordiantor helm chart更新完成，PR提交，待发版本时统一整合
5、tc支持通过pod annotation指定in/egress的limit限制（terway已经支持）

后续远期规划：
1、网络感知的调度/重调度
2、基于网络水位的驱逐策略
3、terway qos支持通过配置文件为pod设定（目前已经支持pod级别，端口等细节暂不支持）
4、tc对于入方向的network qos支持（terway已经支持）

其他议题：

双周会：周二3-4点，下次4.23号

[zwzhang0107]

1、基于tc实现的network qos插件，对接到新的api，研发中，待补充UT，有三个comments需要修复一下啊 @lucming
2、terway qos插件监控指标：internal_metrics.go 待研发
3、tc支持通过pod annotation指定in/egress的limit限制，研发完成，待review

后续远期规划：
1、网络感知的调度/重调度
2、基于网络水位的驱逐策略
3、terway qos支持通过配置文件为pod设定（目前已经支持pod级别，端口等细节暂不支持）
4、tc对于入方向的network qos支持（terway已经支持）

其他议题：pod annotation指定时的handle id持久化问题，放在cgroup文件里

双周会：周二3-4点，下次5.7号

[zwzhang0107]

1、基于tc实现的network qos插件，对接到新的api，研发中，待补充UT，新增了4个review意见 @lucming
2、terway qos插件监控指标：internal_metrics.go 待研发
3、tc支持通过pod annotation指定egress的limit限制，研发完成，待review

后续远期规划：
1、网络感知的调度/重调度
2、基于网络水位的驱逐策略
3、terway qos支持通过配置文件为pod设定（目前已经支持pod级别，端口等细节暂不支持）
4、tc对于入方向的network qos支持（terway已经支持）

其他议题：pod annotation指定时的handle id持久化问题，放在cgroup文件里，待review

双周会：周二3-4点，下次5.21号