后端云原生容器编排【免费下载链接】pythonOfficial Python client library for kubernetes项目地址https://gitcode.com/gh_mirrors/python1/python点击查看免费下载本篇技术指南以官方 Python 客户端kubernetes-python-client中 DRADynamic Resource Allocation相关的V1beta2NodeAllocatableMapping模型为研究对象完整讲解该模型在 DRA 设备资源与节点可分配资源如cpu、memory之间的换算规则、全部字段语义与典型配置示例并结合仓库源码剖析其序列化、反序列化与关联模型的实现细节。读完本文你将能够准确理解 DRA 驱动如何声明设备到节点可分配资源的映射并能在自己的 Python 客户端代码中正确构造、解析和校验这类配置对象。模型文档定位一个由 Sphinxautomodule生成的 API 文档入口本文对应的关联文档是仓库中的 doc/source/kubernetes.aio.client.models.v1beta2_node_allocatable_resource_mapping.rst它本身是一个典型的 Sphinxautomodule文档桩用于生成kubernetes.aio.client.models.v1beta2_node_allocatable_resource_mapping模块的 API 参考页kubernetes.aio.client.models.v1beta2\_node\_allocatable\_resource\_mapping module .. automodule:: kubernetes.aio.client.models.v1beta2_node_allocatable_resource_mapping :members: :show-inheritance: :undoc-members:该桩文件本身不含正文其全部技术内容来自它所指派的源码模块:members:、:show-inheritance:、:undoc-members:三个选项会展开类成员、继承关系与未文档化成员。仓库中对应的实际实现文件是 kubernetes/aio/client/models/v1beta2_node_allocatable_mapping.py异步版与 kubernetes/client/models/v1beta2_node_allocatable_mapping.py同步版类名为V1beta2NodeAllocatableMapping。模块声明基于 Kubernetesrelease-1.37的 OpenAPI 规范生成因此下文所有字段名、类型与默认值均以当前仓库源码为准。背景DRA 驱动如何把设备资源换算成节点可分配资源Kubernetes 的 DRADynamic Resource Allocation动态资源分配允许资源驱动DRA driver通过ResourceSlice发布设备再由 Pod 通过ResourceClaim声明式地申请设备。传统 DRA 只负责把设备挂到容器上但设备消耗的节点级资源例如 GPU 占用的内存、每个 CPU 核心带来的 CPU 配额却无法被调度器和 kubelet 正确计入。仓库 CHANGELOG.md 记录了对应的 alpha 特性DRANodeAllocatableResources它引入ResourceSlice.Spec.Devices[*].NodeAllocatableResourceMappings字段让 DRA 驱动声明设备资源如何映射到节点可分配的 Kubernetes 资源如cpu、memory随后 kubelet 会依据该映射把资源量计入 Pod 级与容器级 cgroup 的 requests/limits。在当前源码中该能力的具体承载者是V1beta2NodeAllocatableMapping、V1beta2NodeAllocatableResource与V1beta2NodeAllocatableOverhead三个模型。核心模型V1beta2NodeAllocatableMapping的字段语义V1beta2NodeAllocatableMapping定义的是一次 DRA 分配如何直接换算为节点可分配资源数量的规则。源码中的类文档kubernetes/aio/client/models/v1beta2_node_allocatable_mapping.py#L96-L108明确指出映射可以来自被分配设备的数量通过deviceMultiplier也可以来自被消耗的具体容量通过capacityKey与capacityMultiplier这两种方式互斥。kubelet 会把换算出的资源量加入 Pod 级 cgroup 的 requests 和 limits并加入每个引用该 claim 的容器级 cgroup 的 limits。该模型是pydantic.BaseModel子类共声明三个可选字符串字段Python 属性OpenAPI 序列化名类型默认值互斥约束capacity_keycapacityKeystrNone与deviceMultiplier互斥capacity_multipliercapacityMultiplierstrNone仅在设置capacityKey时有效device_multiplierdeviceMultiplierstrNone仅在capacityKey、capacityMultiplier均未设置时有效下面逐一展开三个字段的完整语义与官方示例。capacityKey按已消耗容量换算capacityKey引用一个容量名该名字是spec.devices[*].capacity映射中的一个 key。当设置该字段后status.allocation.devices.results[*].consumedCapacity映射针对某个具体 claim 分配中对应 key 的值就是节点可分配资源的基础数量若同时设置allocationMultiplier/capacityMultiplier则与之相乘得到最终数量。源码给出如下示例若spec.devices[*].capacity中存在条目dra.example.com/memory: 128Gi并把capacityKey设为dra.example.com/memory那么当一个 claim 分配消耗了{ dra.example.com/memory: 4Gi }时该映射的基础数量即为4Gi最终节点可分配资源量 consumedCapacity[capacityKey] * capacityMultiplier。capacityMultiplier容量基础数量的乘数capacityMultiplier作为已消耗容量的乘数仅在capacityKey已设置时合法。源码示例设备容量dra.example.com/cores被消耗且每个core提供 2 个cpu则映射可写为{ resourceName: cpu, capacityKey: dra.example.com/cores, capacityMultiplier: 2 }若某 claim 消耗了 8 个dra.example.com/cores则 CPU 占用为8 * 2 16。deviceMultiplier按设备数量换算deviceMultiplier作为 claim 中被分配设备数量的乘数最终节点可分配资源量 deviceCount * deviceMultiplier。它仅在capacityKey与capacityMultiplier都未设置时合法。源码示例一个 DRA 驱动把每个缓存簇CCXcache complex建模为一个设备并在其nodeAllocatableResources中声明{ resourceName: cpu, deviceMultiplier: 8 }若某 claim 被分配 2 个设备CCX则按2 * 8 16个 CPU 计入已分配资源。组合模型V1beta2NodeAllocatableResourcemapping overheadV1beta2NodeAllocatableMapping本身不会单独出现在ResourceSlice中而是作为V1beta2NodeAllocatableResource的一个子字段被引用。查看 kubernetes/aio/client/models/v1beta2_node_allocatable_resource.py#L97-L118该类定义的是DRA 设备/容量单位与节点可分配资源数量之间的换算mappingOptional[V1beta2NodeAllocatableMapping]即本文核心模型的实例overheadOptional[V1beta2NodeAllocatableOverhead]描述分配设备时产生的辅助资源开销。类文档强调mapping与overhead至少需要指定一个两者都不指定即为非法配置。而V1beta2NodeAllocatableResource又作为V1beta2Device.node_allocatable_resourcesOpenAPI 名nodeAllocatableResources的字典值出现其类型为Dict[str, V1beta2NodeAllocatableResource]见 kubernetes/aio/client/models/v1beta2_device.py#L121。该字段的语义是DRA 驱动通过它声明本设备所管理的节点资源映射涵盖当前v1.Node的status.allocatable中除扩展资源之外的部分例如cpu、memory、ephemeral-storage和 hugepages。补充V1beta2NodeAllocatableOverhead的两种开销模式作为对照overhead分支对应的V1beta2NodeAllocatableOverheadkubernetes/aio/client/models/v1beta2_node_allocatable_overhead.py#L96-L107支持两种开销perPodper_pod每个引用该 claim 的 Pod 一次性摊付的固定开销perContainerper_container按引用该 claim 的容器数量线性增长的开销。当两者同时指定时每个 Pod 的总开销 PerPod PerContainer * NumReferences。kubelet 在 Pod 级 cgroup 计入PerPod (PerContainer * NumReferences)在容器级 cgroup仅 limits为每个引用容器计入PerPod PerContainer从而保证 Pod 级父 cgroup 对总量封顶的同时单个容器也能访问到 Pod 级开销。这段实现说明有助于把mapping与overhead两种换算路径放在同一框架下理解。在 Python 客户端中如何使用该模型随kubernetes包一起发布同步版与异步版均有对应实现# 同步版 from kubernetes.client.models.v1beta2_node_allocatable_mapping import V1beta2NodeAllocatableMapping from kubernetes.client.models.v1beta2_node_allocatable_resource import V1beta2NodeAllocatableResource # 异步版aio from kubernetes.aio.client.models.v1beta2_node_allocatable_mapping import V1beta2NodeAllocatableMapping from kubernetes.aio.client.models.v1beta2_node_allocatable_resource import V1beta2NodeAllocatableResource两个版本的模块都已在各自的__init__.py中注册导出见 kubernetes/aio/client/models/init.py#L1661-L1663 与 #L2511-L2513因此也可以直接写from kubernetes.aio.client.models import V1beta2NodeAllocatableMapping。构造一个按设备数量映射的配置以下代码构造每分配 1 个设备即计入 8 个 CPU的映射并将其挂到V1beta2NodeAllocatableResource上以异步版为例from kubernetes.aio.client.models import ( V1beta2NodeAllocatableMapping, V1beta2NodeAllocatableResource, ) mapping V1beta2NodeAllocatableMapping( resource_namecpu, device_multiplier8, ) node_allocatable V1beta2NodeAllocatableResource(mappingmapping)构造一个按已消耗容量换算的配置mapping V1beta2NodeAllocatableMapping( resource_namecpu, capacity_keydra.example.com/cores, capacity_multiplier2, )注意两个字段均声明为StrictStr严格字符串因此乘数等数值应使用字符串形式传入如2而非2最终换算遵循 Kubernetes 的资源数量Quantity运算规则。序列化与反序列化该模型继承自pydantic.BaseModel并复用了 openapi-generator 生成的通用序列化框架。每个实例都提供to_dict(serializeFalse)返回模型字段字典serializeTrue时使用 OpenAPI 线上的驼峰名capacityKey、capacityMultiplier、deviceMultiplier否则使用 Python 属性名见 kubernetes/aio/client/models/v1beta2_node_allocatable_mapping.py#L186-L192to_json()输出按别名的 JSON 字符串from_json(json_str)/from_dict(obj)从 JSON 字符串或字典还原模型实例。反序列化时from_dict内部会先调用__preprocess_input_names做输入名归一化既接受 OpenAPI 驼峰名capacityKey也接受 Python 风格下划线名capacity_key二者都会被统一到驼峰名后再交给 pydantic 校验见 kubernetes/aio/client/models/v1beta2_node_allocatable_mapping.py#L122-L148。模型配置启用了validate_by_name、validate_by_alias、validate_assignment与extraforbid意味着未知字段会被拒绝赋值时会实时校验这有助于在构造ResourceSlice配置时尽早发现拼写错误。一个完整的从 JSON 还原映射的示例import json raw { resourceName: cpu, capacityKey: dra.example.com/cores, capacityMultiplier: 2, } mapping V1beta2NodeAllocatableMapping.from_json(json.dumps(raw)) assert mapping.capacity_key dra.example.com/cores assert mapping.capacity_multiplier 2 assert mapping.device_multiplier is None注意事项与 API 演进字段互斥校验需自行保证源码文档明确deviceMultiplier与capacityKey/capacityMultiplier互斥但生成代码并未在模型内部强制互斥断言extraforbid只拒绝未知字段因此在构造配置时应在业务层保证不出现既按设备数量又按容量换算的非法组合。命名存在版本演进当前仓库源码基于release-1.37使用V1beta2NodeAllocatableMapping与capacityMultiplier/deviceMultiplier两个乘数字段而仓库内 doc/html/kubernetes.aio.client.models.v1beta2_node_allocatable_resource_mapping.html 中构建于release-1.36的旧版文档显示当时该模块的类名为V1beta2NodeAllocatableResourceMapping仅含allocationMultiplier与capacityKey两个字段。如果你的集群/驱动使用旧版本 API字段名与换算规则请以对应版本的实际规范为准。这是 alpha 特性DRANodeAllocatableResources在 CHANGELOG.md 中被标注为 alpha 特性相关字段NodeAllocatableResourceMappings等仍可能随 Kubernetes 演进调整生产环境使用前请确认集群版本对该特性的支持情况。同步 / 异步 API 一致kubernetes.client与kubernetes.aio.client下的模型在字段、校验规则与序列化行为上保持一致两者可对照阅读同步实现见 kubernetes/client/models/v1beta2_node_allocatable_mapping.py 与 kubernetes/client/models/v1beta2_node_allocatable_resource.py。小结V1beta2NodeAllocatableMapping是 DRA 生态中把设备级分配桥接到节点级可分配资源的关键模型。通过deviceMultiplier按设备数量与capacityKeycapacityMultiplier按消耗容量两种互斥换算路径DRA 驱动可以让 kubelet 精确地把设备占用折算为cpu、memory等节点资源并落实到 cgroup 限额中。结合本文给出的字段语义、源码级序列化细节与构造示例你可以在基于本仓库官方 Python 客户端编写 DRA 驱动或资源调度工具时正确构建和解析这类配置对象。赞分享后端云原生容器编排【免费下载链接】pythonOfficial Python client library for kubernetes项目地址https://gitcode.com/gh_mirrors/python1/python点击查看免费下载相关推荐Kubernetes Python 客户端深入解析V1ContainerExtendedResourceRequest 模型与 DRA 设备请求映射Kubernetes Python 客户端深入解析V1ContainerExtendedResourceRequest 模型与 DRA 设备请求映射 导读 本后端云原生容器编排Kubernetes Python Client 深度解析V1PodResourceClaimStatus 模型与动态资源分配DRA状态跟踪Kubernetes Python Client 深度解析V1PodResourceClaimStatus 模型与动态资源分配DRA状态跟踪 本篇技术指南后端云原生容器编排Kubernetes Python Client 深度解析V1DeviceRequestAllocationResult 与 DRA 设备分配结果模型Kubernetes Python Client 深度解析V1DeviceRequestAllocationResult 与 DRA 设备分配结果模型 导读后端云原生容器编排上一篇gh_mirrors/sh1/sh的发布版本策略长期支持与滚动发布下一篇字段级限流监控用TypeGraphQL守护API稳定性创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考