云原生容器运行时【免费下载链接】kata-containersKata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载Kata Containers 通过轻量级虚拟机提供容器级隔离其基于 Cloud Hypervisor 的运行时clh依赖一套由 OpenAPI 生成器产出的 Go 客户端库与 VMM 本地 HTTP API 交互。RateLimiterConfig正是这套客户端模型中负责 I/O 限速的核心数据结构它通过独立的字节速率bytes/s与操作速率ops/s两个令牌桶TokenBucket为虚拟机的磁盘与网络设备配置带宽上限和突发能力。本文以 RateLimiterConfig 模型文档 为主线完整解析该模型的字段、方法并结合 Kata Containers 源码clh.go、configuration-clh.toml.in与单元测试讲透从 TOML 配置到 VMM API 请求的完整链路让读者既能读懂模型 API也能直接在 Kata 配置文件中落地磁盘/网络限速。一、模型概览一个限速器、两个独立令牌桶RateLimiterConfig的定位在源码注释中有明确说明见 model_rate_limiter_config.goDefines an IO rate limiter with independent bytes/s and ops/s limits. Limits are defined by configuring each of thebandwidthandopstoken buckets.即这是一个同时具备带宽维度bytes/s与操作维度ops/s的 I/O 限速器两个维度彼此独立分别由一个令牌桶描述。其 JSON 序列化字段名与 Go 结构体定义如下来源model_rate_limiter_config.gotype RateLimiterConfig struct { Bandwidth *TokenBucket json:bandwidth,omitempty Ops *TokenBucket json:ops,omitempty }对应 OpenAPI 规范api/openapi.yaml中的属性定义如下属性类型必填说明BandwidthPointer to TokenBucket可选带宽维度令牌桶限制字节/秒吞吐OpsPointer to TokenBucket可选操作维度令牌桶限制 IO 操作次数/秒两者均为可选字段omitempty意味着一个限速器可以只限制带宽、只限制操作数或两者同时限制。在 Kata Containers 的实际构建逻辑中只有当对应的MaxRate配置为非零时对应的令牌桶才会被创建详见下文源码分析。二、底层基石TokenBucket 令牌桶模型RateLimiterConfig的两个字段都指向 TokenBucket 模型因此理解令牌桶的语义是掌握限速器行为的前提。TokenBucket 的 OpenAPI 定义api/openapi.yaml包含三个属性属性类型必填说明Sizeint64是桶可容纳的令牌总数total number of tokens this bucket can holdOneTimeBurstPointer to int64否令牌桶的初始大小initial size of a token bucketRefillTimeint64是桶完成一次补充所需的毫秒数amount of milliseconds it takes for the bucket to refillGo 结构体model_token_bucket.go与 JSON 字段一一对应type TokenBucket struct { Size int64 json:size OneTimeBurst *int64 json:one_time_burst,omitempty RefillTime int64 json:refill_time }2.1 令牌桶的工作机制源码注释model_token_bucket.go对令牌桶的行为给出了精确描述可以提炼为以下四条规则补充速率由派生值决定refill-rate补充速率由Size与RefillTime共同推导即每RefillTime毫秒补充的令牌数 Size / RefillTime这是令牌持续补充的恒定速率补充延迟启动补充过程只有在初始突发预算OneTimeBurst提供的初始令牌被消耗殆尽之后才开始消耗速率无上限、允许突发从桶中消耗令牌的速度不受限制因此只要桶内还有令牌就可以爆发式消费突发大小受可用令牌数量约束空桶后收敛为补充速率一旦桶被耗尽消费速度就被 refill-rate 锁死形成稳定的限速效果。这种设计同时兼顾了两类需求OneTimeBurst允许工作负载在启动瞬间完成一次冲刺例如大文件预读、TCP 慢启动窗口而Size RefillTime则保证长期平均速率被严格限制在目标值以内且初始突发额度不会抬高整体限速上限。三、模型 API 方法全景构造与访问器RateLimiterConfig.md 列出了该模型提供的全部方法它们是客户端代码操作限速器配置的入口对应实现集中在 model_rate_limiter_config.go。3.1 构造函数NewRateLimiterConfig()—— 实例化一个空的RateLimiterConfig对象func NewRateLimiterConfig() *RateLimiterConfig该构造函数会为已定义默认值的属性赋值并确保 API 必需的属性被设置当必需属性集合变化时参数列表也会随之调整。当前模型中两个字段均为可选因此返回的是一个Bandwidth、Ops均为nil的空对象见 model_rate_limiter_config.go。NewRateLimiterConfigWithDefaults()—— 同样实例化新对象但不保证API 必需属性一定被设置只对已定义默认值的属性赋值func NewRateLimiterConfigWithDefaults() *RateLimiterConfig两者的区别在 Kata 场景下并不显著因为该模型无必填字段但保留了 OpenAPI 生成代码的通用语义供属性未来扩展为必填时使用。3.2 带宽字段Bandwidth访问器GetBandwidth() TokenBucket返回Bandwidth字段值若字段为nil返回零值TokenBucket实现见 model_rate_limiter_config.goGetBandwidthOk() (*TokenBucket, bool)返回(字段值, 是否已设置)二元组若未设置则返回(nil, false)L51-L56SetBandwidth(v TokenBucket)将传入的TokenBucket以指针引用方式赋给Bandwidth字段L68-L70HasBandwidth() bool返回布尔值指示字段是否已被设置非 nilL59-L65。3.3 操作数字段Ops访问器GetOps() TokenBucket返回Ops字段值nil时返回零值L73-L79GetOpsOk() (*TokenBucket, bool)返回(字段值, 是否已设置)二元组L83-L88SetOps(v TokenBucket)以指针引用方式设置Ops字段L100-L102HasOps() bool判断Ops是否已被设置L91-L97。此外模型还配套了MarshalJSON序列化方法仅序列化非 nil 字段见 L104-L113以及NullableRateLimiterConfig可空包装类型L115-L149用于在 API 响应中区分字段缺失与字段为 null两种状态。四、Kata 运行时中的实际应用网络与磁盘限速RateLimiterConfig在 Cloud Hypervisor 客户端模型中被NetConfig网络设备与DiskConfig磁盘设备共同引用见 NetConfig.md 与 DiskConfig.md这意味着每个虚拟网卡和虚拟磁盘都可以拥有独立的限速器。在 Kata Containers 的 Cloud Hypervisor 实现中限速器配置的构建集中在 clh.go。4.1 核心构建函数 getRateLimiterConfigclh.go 的 getRateLimiterConfig 是整套机制的枢纽其逻辑清晰体现了可选字段 零值即无限速的设计func (clh *cloudHypervisor) getRateLimiterConfig(bwSize, bwOneTimeBurst, opsSize, opsOneTimeBurst int64) *chclient.RateLimiterConfig { if bwSize 0 opsSize 0 { return nil } rateLimiterConfig : chclient.NewRateLimiterConfig() if bwSize ! 0 { bwTokenBucket : chclient.NewTokenBucket(bwSize, int64(utils.DefaultRateLimiterRefillTimeMilliSecs)) if bwOneTimeBurst ! 0 { bwTokenBucket.SetOneTimeBurst(bwOneTimeBurst) } rateLimiterConfig.SetBandwidth(*bwTokenBucket) } if opsSize ! 0 { opsTokenBucket : chclient.NewTokenBucket(opsSize, int64(utils.DefaultRateLimiterRefillTimeMilliSecs)) if opsOneTimeBurst ! 0 { opsTokenBucket.SetOneTimeBurst(opsOneTimeBurst) } rateLimiterConfig.SetOps(*opsTokenBucket) } return rateLimiterConfig }从这段代码可以提炼出以下行为规则带宽与操作数都为 0 时直接返回nil——不会向 VMM 下发任何限速配置对应不限速语义带宽令牌桶与操作令牌桶独立构建互不影响每个桶的RefillTime统一取utils.DefaultRateLimiterRefillTimeMilliSecsOneTimeBurst仅在非零时设置零值表示不启用初始突发额度。DefaultRateLimiterRefillTimeMilliSecs定义于 utils/utils.go值为1000毫秒即默认每个令牌桶的补充周期为 1 秒。4.2 网络与磁盘限速的入口网络限速与磁盘限速分别通过getNetRateLimiterConfig与getDiskRateLimiterConfig组装入参clh.gofunc (clh *cloudHypervisor) getNetRateLimiterConfig() *chclient.RateLimiterConfig { return clh.getRateLimiterConfig( int64(utils.RevertBytes(uint64(clh.config.NetRateLimiterBwMaxRate/8))), int64(utils.RevertBytes(uint64(clh.config.NetRateLimiterBwOneTimeBurst/8))), clh.config.NetRateLimiterOpsMaxRate, clh.config.NetRateLimiterOpsOneTimeBurst) } func (clh *cloudHypervisor) getDiskRateLimiterConfig() *chclient.RateLimiterConfig { return clh.getRateLimiterConfig( int64(utils.RevertBytes(uint64(clh.config.DiskRateLimiterBwMaxRate/8))), int64(utils.RevertBytes(uint64(clh.config.DiskRateLimiterBwOneTimeBurst/8))), clh.config.DiskRateLimiterOpsMaxRate, clh.config.DiskRateLimiterOpsOneTimeBurst) }两点值得注意带宽单位换算配置文件中的带宽单位为bits/sec而令牌桶的Size以令牌数此处对应字节计量因此代码先除以 8 将比特换算为字节再经utils.RevertBytes辅助函数定义于 utils/utils.go做进一步换算后传入ops 参数直传操作数速率ops/sec与突发值无需单位换算直接透传给令牌桶。4.3 下发到设备配置构建好的限速器通过SetRateLimiterConfig挂接到设备配置对象上。以网络为例addNet 中netRateLimiterConfig : clh.getNetRateLimiterConfig() net : chclient.NewNetConfig() net.Mac mac if netRateLimiterConfig ! nil { net.SetRateLimiterConfig(*netRateLimiterConfig) }磁盘设备则同时出现在创建磁盘与热插拔磁盘两条路径上clh.go 与 clh.go保证冷启动与运行时热插拔的磁盘都遵守同样的限速策略。五、实战配置configuration-clh.toml 限速参数详解Kata Containers 为 Cloud Hypervisor 运行时提供了两套配置文件模板configuration-clh.toml.in通用与 configuration-clh-azure.toml.inAzure 专用两者均包含 8 个限速相关参数默认全部为0即不限速。这些参数与hypervisor结构体字段的映射定义于 katautils/config.goTOML 标签一一对应。5.1 网络限速参数配置项单位默认值说明net_rate_limiter_bw_max_ratebits/sec0网络 I/O 带宽上限进出方向inbound/outbound使用同一数值0 表示不限速net_rate_limiter_bw_one_time_burstbits0初始突发额度提升初始最大速率仅当net_rate_limiter_bw_max_rate非零时生效net_rate_limiter_ops_max_rateops/sec0网络 I/O 操作速率上限进出方向同一数值0 表示不限速net_rate_limiter_ops_one_time_burstops0操作维度初始突发额度仅当net_rate_limiter_ops_max_rate非零时生效5.2 磁盘限速参数配置项单位默认值说明disk_rate_limiter_bw_max_ratebits/sec0磁盘 I/O 带宽上限进出方向同一数值0 表示不限速disk_rate_limiter_bw_one_time_burstbits0磁盘带宽初始突发额度仅当disk_rate_limiter_bw_max_rate非零时生效disk_rate_limiter_ops_max_rateops/sec0磁盘 I/O 操作速率上限0 表示不限速disk_rate_limiter_ops_one_time_burstops0磁盘操作维度初始突发额度仅当disk_rate_limiter_ops_max_rate非零时生效模板注释还特别强调这些选项基于 Cloud Hypervisor 的 I/O throttling 机制默认禁用建议参考 Cloud Hypervisor 官方 I/O throttling 文档理解内部细节见 configuration-clh.toml.in。5.3 配置校验逻辑突发值不能脱离上限单独生效katautils/config.go在读取配置时对突发值依赖上限值这一约束做了显式校验。以磁盘带宽为例config.gofunc (h hypervisor) getDiskRateLimiterBwOneTimeBurst() int64 { if h.DiskRateLimiterBwOneTimeBurst ! 0 h.getDiskRateLimiterBwMaxRate() 0 { kataUtilsLogger.Warn(The DiskRateLimiterBwOneTimeBurst is set but DiskRateLimiterBwMaxRate is not set, this option will be ignored.) h.DiskRateLimiterBwOneTimeBurst 0 } return h.DiskRateLimiterBwOneTimeBurst }网络带宽、网络 ops、磁盘 ops 的突发值都有完全对称的校验逻辑config.go一旦发现突发值非零但对应上限为零运行时会记录告警并将突发值强制归零——这与上文getRateLimiterConfig中只依据 MaxRate 决定是否创建令牌桶的行为互为印证限速只由 MaxRate 驱动OneTimeBurst 只是附属修饰。5.4 一个可落地的配置示例假设需要对某工作负载的虚拟磁盘限制为 100 MB/s 带宽、允许 50 MB 初始突发同时限制网络为 10k ops/s# 磁盘带宽限速100 MB/sbits/sec初始突发 50 MBbits disk_rate_limiter_bw_max_rate 838860800 disk_rate_limiter_bw_one_time_burst 419430400 # 网络操作数限速10000 ops/s net_rate_limiter_ops_max_rate 10000修改配置后需重启 kata-runtime 相关服务或重建沙箱使其生效保持参数为0即完全关闭对应维度的限速。六、单元测试验证限速器行为矩阵Kata Containers 为网络限速逻辑提供了覆盖完整的单元测试TestCloudHypervisorNetRateLimiterclh_test.go。测试以 11 组用例构成行为矩阵同时验证HasRateLimiterConfig、HasBandwidth、HasOps、GetBandwidth、GetOps等模型方法场景bwMaxRatebwOneTimeBurstopsMaxRateopsOneTimeBurst预期结果仅带宽 突发10001000000有限速器含带宽桶、无 ops 桶仅带宽、无突发1000000有限速器含带宽桶、无 ops 桶仅突发、无带宽上限01000000无限速器突发被忽略全零0000无限速器仅 ops 突发00100010000有限速器无带宽桶、含 ops 桶仅 ops、无突发0010000有限速器无带宽桶、含 ops 桶仅 ops 突发、无上限00010000无限速器带宽 ops 同时配置100010000100010000有限速器两个桶均存在带宽 ops 均无突发1000010000有限速器两个桶均存在双突发、无双上限010000010000无限速器测试对令牌桶字段值也做了精确断言clh_test.go带宽桶的Size与OneTimeBurst均经utils.RevertBytes(bwMaxRate/8)换算后比较而 ops 桶的Size与OneTimeBurst直接与配置值相等。这组测试从行为层面再次确认了前文总结的全部语义MaxRate 是限速的开关OneTimeBurst 是可选修饰两者必须配套才生效。七、关联模型RateLimitGroupConfig 与按组限速除直接挂在单设备上的RateLimiterConfig外客户端模型还提供RateLimitGroupConfigRateLimitGroupConfig.md用于多设备共享同一限速策略的场景属性类型必填说明Idstring是限速组标识RateLimiterConfigRateLimiterConfig是该组共享的限速配置DiskConfig中对应的引用字段为RateLimitGroupstring 类型见 DiskConfig.md通过组 ID 将磁盘挂入预设的限速组。这种组级限速适合需要对同一 VMM 内的多个磁盘实施统一 I/O 预算的场景与RateLimiterConfig直接内联到设备配置的方式互为补充。八、小结一条完整的限速链路从配置到生效Kata Containers 的 I/O 限速走过了这样一条链路配置层用户在configuration-clh.toml.in中填写net_/disk_rate_limiter_*共 8 个参数单位 bits/sec、ops/sec校验层katautils/config.go 的 getter 方法校验突发值必须有上限值配套否则告警并归零构建层clh.go 的 getRateLimiterConfig 依据 MaxRate 是否为零决定是否创建RateLimiterConfig并分别构建带宽/操作两个TokenBucketRefillTime统一为 1000ms挂载层通过SetRateLimiterConfig挂到NetConfig/DiskConfig随设备创建或热插拔请求发给 Cloud Hypervisor执行层VMM 侧的 I/O throttling 依据令牌桶的Size、OneTimeBurst、RefillTime实施限速允许初始突发、长期按 refill-rate 收敛。RateLimiterConfig虽只是一个两字段的轻量模型但它在 Kata Containers 中承载了独立控制字节速率与操作速率 支持初始突发的完整 I/O 治理语义。无论是为共享存储的多租户沙箱设置磁盘预算还是为网络密集型 Pod 限制出口带宽理解该模型及其与配置项的映射关系都是精准实施虚拟机 I/O 限速的第一步。赞分享云原生容器运行时【免费下载链接】kata-containersKata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs. https://katacontainers.io/项目地址https://gitcode.com/gh_mirrors/ka/kata-containers点击查看免费下载相关推荐Cloud Hypervisor I/O 限流深度指南virtio-block / virtio-net 令牌桶限速与速率组配置Cloud Hypervisor I/O 限流深度指南virtio block / virtio net 令牌桶限速与速率组配置 本文基于 Cloud Hyp云原生Cloud Hypervisor I/O Throttling 深度解析virtio-blk/virtio-net 令牌桶限流原理与实战配置Cloud Hypervisor I/O Throttling 深度解析virtio blk/virtio net 令牌桶限流原理与实战配置 本文档基于仓库内Agent 沙箱虚拟化云原生人工智能后端容器运行时amis Table2 表格怎么实现行选择并在已选择区域展示已选数据amis Table2 表格怎么实现行选择并在已选择区域展示已选数据 在 amis 中用 JSON Schema 配置页面时如果要用 table2 类型的表格云原生容器运行时上一篇gh_mirrors/re/remote-working远程办公数据备份终极指南下一篇【亲测免费】 Pinyin4NET 项目教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考