Replies: 13 comments 5 replies
-
hi , i would like to discuee the qos api @lucming |
Beta Was this translation helpful? Give feedback.
-
关于koordinator的配置有几个建议可以参考:
比如在NetworkQOS里为LS/BE定义网络的request/limit(和cpu/memory的描述类似),对应到底层的min/max实现。 type NetworkQOS struct { 整机级别的可以在SystemStrategy里定义
|
Beta Was this translation helpful? Give feedback.
-
1212 2、System/LS/BE的默认值,整机带宽
接下来的工作: 后续远期规划: 双周会:周二3-4点,下次26号 |
Beta Was this translation helpful? Give feedback.
-
接下来的工作: 后续远期规划: 双周会:周二3-4点,下次26号 |
Beta Was this translation helpful? Give feedback.
-
接下来的工作: TODO: 后续远期规划: 双周会:周二3-4点,下次23号 |
Beta Was this translation helpful? Give feedback.
-
下两周重点事项:
后续远期规划: 双周会:周二3-4点,下次2.21号 |
Beta Was this translation helpful? Give feedback.
-
下两周重点事项:
后续远期规划: 最佳实践讨论:
双周会:周二3-4点,下次3.5号 |
Beta Was this translation helpful? Give feedback.
-
1、terway qos的研发 @l1b0k :改为直接读本地文件,配置文件读写部分研发完成,已经合入 close 2、koordinator功能研发 3、测试相关,terway qos + koordlet自测完成 4、terway qos和korodlet插件的测试中,UT覆盖率补充 @l1b0k 已合入 下两周重点事项: 1、基于tc实现的network qos插件,对接到新的api,研发中,proposal和代码拆分一下 @lucming 后续远期规划: 最佳实践讨论:整理一下放到最佳实践的文档里 其他议题: 双周会:周二3-4点,下次3.26号 |
Beta Was this translation helpful? Give feedback.
-
上下行带宽互相影响 |
Beta Was this translation helpful? Give feedback.
-
1、基于tc实现的network qos插件,对接到新的api,研发中,proposal更新完成,代码修改中 @lucming
后续远期规划: 其他议题: 双周会:周二3-4点,下次4.9号 |
Beta Was this translation helpful? Give feedback.
-
1、基于tc实现的network qos插件,对接到新的api,研发中,proposal更新完成,代码修改完成,待补充UT,自测ok @lucming 后续远期规划: 其他议题: 双周会:周二3-4点,下次4.23号 |
Beta Was this translation helpful? Give feedback.
-
1、基于tc实现的network qos插件,对接到新的api,研发中,待补充UT,有三个comments需要修复一下啊 @lucming 后续远期规划: 其他议题:pod annotation指定时的handle id持久化问题,放在cgroup文件里 双周会:周二3-4点,下次5.7号 |
Beta Was this translation helpful? Give feedback.
-
1、基于tc实现的network qos插件,对接到新的api,研发中,待补充UT,新增了4个review意见 @lucming 后续远期规划: 其他议题:pod annotation指定时的handle id持久化问题,放在cgroup文件里,待review 双周会:周二3-4点,下次5.21号 |
Beta Was this translation helpful? Give feedback.
-
User Story
Story 1
集群管理员希望大带宽的容器,调度到不同节点上,避免单节点/机框拥塞。
Story 2
集群管理员希望提高资源利用率,在节点上同时部署在线、离线业务。
当网络资源空闲时,让离线业务尽可能使用节点带宽。
当网络资源争抢时,可以优先保证在线业务网络资源,同时也照顾离线业务不被饿死。
Story 3
当节点容器出现严重带宽争抢,管理员可以在不重建 Pod 情况下,临时调整单个 Pod 带宽限制。
Proposal
Koordinator 通过 QoS 策略,实现网络资源的优先级管理。具体包含:
带宽限制的考虑
带宽限制考虑两个场景
整机带宽限制
混部场景下,节点上流量具备不同的优先级,我们假定有三个优先级,分别为 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 等级关系如下:
定义下面的 Pod annotation
Pod 带宽限制
整Pod 维度的带宽限制
节点混部带宽配置
在 NodeSLO 中,为每个节点定义机器带宽限制,以及各个优先级的带宽上下限。
Pod 配置
Pod 配置目标能提供Pod内细粒度的带宽控制能力,通过 pod annotation 来定义。
配置内容包含
koorlet 配置同步
Beta Was this translation helpful? Give feedback.
All reactions