Headlamp 中的 KubeResourceQuota 接口ResourceQuota 资源的数据模型与用量可视化实现【免费下载链接】headlampA Kubernetes web UI that is fully-featured, user-friendly and extensible项目地址: https://gitcode.com/GitHub_Trending/he/headlamp导读本文围绕 Headlamp 前端数据层中KubeResourceQuota这一 TypeScript 接口展开深入解析它在 resourceQuota.ts 中的完整定义、与底层KubeObjectInterface的继承关系以及 Headlamp 如何基于该接口构建 ResourceQuota 列表页与详情页的请求/限制展示、用量进度条等核心 UI。读完本文你将掌握 Headlamp 前端如何为 Kubernetes 的 ResourceQuota 资源建模理解spec.hard、status.used等字段在界面上的消费路径并能基于requests、limits、resourceStats等 getter 在插件或二次开发中复用这些能力。KubeResourceQuota 接口概览KubeResourceQuota是 Headlamp 对 KubernetesResourceQuota资源配额对象的 TypeScript 类型抽象位于 frontend/src/lib/k8s/resourceQuota.ts完整定义如下export interface KubeResourceQuota extends KubeObjectInterface { spec: spec; status?: status; }它继承了 Headlamp 中所有 Kubernetes 资源的公共基接口KubeObjectInterface定义于 frontend/src/lib/k8s/KubeObject.ts后者声明了每个 K8s 对象都具备的三个字段kind: stringREST 资源对应的 Kind采用 CamelCase 命名且不可更新apiVersion?: string资源的 API 版本metadata: KubeMetadata对象的元数据名称、命名空间、uid、labels、annotations、creationTimestamp 等。而KubeResourceQuota在基接口之上只追加了两个配额专属字段字段类型说明specspec必选用户声明的配额期望核心是hard硬上限status尚未生成时 spec 仍存在statusstatus可选集群控制器回填的实际用量与配额快照配额对象刚创建时可能缺失接口的层级关系为KubeObjectInterface→KubeResourceQuota在 API 文档中体现为 接口层级说明。spec 与 status配额声明的两个半场Kubernetes 的 ResourceQuota 机制是用户声明 控制器回填的双层结构Headlamp 的接口定义如实反映了这一点。spec与status两个局部接口都定义在同一文件 resourceQuota.ts 中。spec声明配额上限interface spec { hard: { [key: string]: string; }; scopes?: string[]; scopeSelector?: { matchExpressions: { operator: string; scopeName: string; values: string[]; }[]; }; }hard必选配额硬上限的映射表键为资源名称值为 Kubernetes quantity 字符串。常见键包括cpu、memory、requests.cpu、requests.memory、limits.cpu、limits.memory、persistentvolumeclaims、pods、count/deployments.apps等scopes可选配额的作用范围集合例如BestEffort仅限 BestEffort 优先级 Pod、NotTerminating排除终止中 Pod、PriorityClass等scopeSelector可选通过matchExpressionsoperator、scopeName、values实现比scopes更精细的匹配规则。status控制器回填的实时数据interface status { hard: { [key: string]: string; }; used: { [key: string]: string; }; }hard控制器根据当前生效范围计算出的配额值快照可能与spec.hard略有出入例如 scopeSelector 过滤后used当前命名空间内各类资源已经消耗的量。正是status.used与status.hard的对比构成了 Headlamp 界面上已用/上限展示的数据来源。ResourceQuota 类接口的运行时载体KubeResourceQuota接口本身只描述数据结构真正承载 API 交互与派生计算的是同文件中的ResourceQuota类resourceQuota.ts。类与接口共享spec/statusgetter但类的职责更丰富。类级元信息class ResourceQuota extends KubeObjectKubeResourceQuota { static kind ResourceQuota; static apiName resourcequotas; static apiVersion v1; static isNamespaced true; ... }kind、apiName、apiVersion用于构造对 API Server 的请求GET /api/v1/namespaces/{ns}/resourcequotasisNamespaced true表明 ResourceQuota 是命名空间级资源列表页因此受命名空间过滤器约束getBaseObject()会预置spec: { hard: {} }空壳供新建资源的表单初始化使用。三个核心 getterrequests、limits、resourceStats是 Headlamp 界面消费该对象的主要入口三者都遍历spec.hard/status并借助normalizeUnit定义于 frontend/src/lib/util.ts把 Kubernetes quantity如500m、1Gi、2归一化为易读文本Getter返回类型过滤规则输出形态requestsstring[]cpu、memory、requests.*requests.cpu: 100m/500mused/hardlimitsstring[]limits.*limits.memory: 128Mi/512MiresourceStats{name, hard, used}[]status.hard全部键供表格逐行渲染的原始三元组其中requests/limits在status.used缺失时以0兜底保证对象刚创建、控制器尚未回填时界面不会报错。从接口到界面列表页的请求/限制展示列表页组件 frontend/src/components/resourceQuota/List.tsx 使用ResourceQuota.useList()拉取数据并通过ResourceQuotaRenderer渲染列定义包括name、namespace、cluster、requests、limits、labels、age。其中{ id: requests, label: t(translation|Request), getValue: item item.requests.join(, ), render: item { const requests: ReactNode[] []; item.requests.forEach((request: string) { requests.push(PaddedChip label{request} variantoutlined sizesmall /); }); return WrappingBox{requests}/WrappingBox; }, },表格的文本导出getValue直接复用requestsgetter 拼接结果单元格渲染render把每个requests.cpu: 100m/500m形式的字符串渲染成一个个 outlined Chip标签并用可换行的WrappingBox容器包裹避免条目过多时撑破布局limits列的渲染逻辑与requests完全对称对应item.limits列表页标题旁还挂载了CreateResourceButton resourceClass{ResourceQuota}支持直接新建配额对象。详情页用量进度条与归一化单位详情页 frontend/src/components/resourceQuota/Details.tsx 通过DetailsGrid渲染对象元数据并把resourceStats交给ResourceQuotaTable展示Resource / Used / Hard / Usage四列。用量占比计算 getUsageRatioexport function getUsageRatio(name: string, used: string, hard: string): number { const resourceType name.includes(.) ? name.split(.).pop()! : name; ... if (hardNum 0) return 0; return usedNum / hardNum; }该函数按资源类型分支解析数值cpu优先用parseCpu解析带n/u/m后缀的 CPU 量否则按整数核数乘以TO_ONE_CPU换算memory/storage/ephemeral-storage及hugepages-*走parseRam解析字节量其余计数类资源如pods、count/...直接parseInt。返回的比值可能大于 1用量超额hard为 0 时返回 0 避免除零。进度条颜色分级与截断QuotaUsageBar组件把比值换算成百分比并用Math.min(percentage, 100)截断进度条长度超出 100% 时条满但文字仍显示真实百分比占比 ≥ 90%红色error告警超额风险占比 ≥ 80%黄色warning其余绿色success。同时aria-label与aria-valuetext提供了无障碍描述进度条本身由 MUILinearProgress实现。单位归一化显示ResourceQuotaTable的 Used/Hard 列会先调用normalizeUnitfrontend/src/lib/util.ts把 quantity 归一化cpu输出1 core/2 coresmemory按二进制Ki/Mi/Gi/Ti/Pi/Ei与十进制m/u/n/k/M/G/T/P/E后缀换算为字节后自动挑选 KB/MB/GB 等可读单位。若原始值与归一化值数值不同则显示为500m (0.5 cores)的形式兼顾精确与可读。类型消费从 API 文档到实际代码的印证围绕KubeResourceQuota的完整资料链包括接口文档docs/development/api/interfaces/lib_k8s_resourceQuota.KubeResourceQuota.md模块文档docs/development/api/modules/lib_k8s_resourceQuota.md导出ResourceQuota类与KubeResourceQuota接口类文档docs/development/api/classes/lib_k8s_resourceQuota.ResourceQuota.md列出requests、limits、resourceStats、spec、status五个 accessor以及继承自makeKubeObject的useList、useGet、apiList等静态方法基接口KubeObjectInterface的字段语义参见 frontend/src/lib/k8s/KubeObject.ts。这意味着开发者在插件中只需import ResourceQuota from kinvolk/headlamp-plugin/lib/k8s/resourceQuota这类方式引入后即可通过ResourceQuota.useList()订阅配额数据再借助requests、limits、resourceStats三个 getter 快速构建自定义的配额看板而不必自己解析 Kubernetes quantity 字符串。小结KubeResourceQuota是 Headlamp 前端数据模型与 KubernetesResourceQuotaAPI 之间的类型契约spec.hard承载用户声明、status.used承载控制器回填二者经ResourceQuota类的三个 getter 与normalizeUnit/parseCpu/parseRam等工具函数加工后最终呈现为列表页的 Chip 标签和详情页的用量进度条。理解这一数据模型是扩展 Headlamp 配额相关 UI 或编写自定义配额视图的第一步。【免费下载链接】headlampA Kubernetes web UI that is fully-featured, user-friendly and extensible项目地址: https://gitcode.com/GitHub_Trending/he/headlamp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Headlamp 中的 KubeResourceQuota 接口：ResourceQuota 资源的数据模型与用量可视化实现
Headlamp 中的 KubeResourceQuota 接口ResourceQuota 资源的数据模型与用量可视化实现【免费下载链接】headlampA Kubernetes web UI that is fully-featured, user-friendly and extensible项目地址: https://gitcode.com/GitHub_Trending/he/headlamp导读本文围绕 Headlamp 前端数据层中KubeResourceQuota这一 TypeScript 接口展开深入解析它在 resourceQuota.ts 中的完整定义、与底层KubeObjectInterface的继承关系以及 Headlamp 如何基于该接口构建 ResourceQuota 列表页与详情页的请求/限制展示、用量进度条等核心 UI。读完本文你将掌握 Headlamp 前端如何为 Kubernetes 的 ResourceQuota 资源建模理解spec.hard、status.used等字段在界面上的消费路径并能基于requests、limits、resourceStats等 getter 在插件或二次开发中复用这些能力。KubeResourceQuota 接口概览KubeResourceQuota是 Headlamp 对 KubernetesResourceQuota资源配额对象的 TypeScript 类型抽象位于 frontend/src/lib/k8s/resourceQuota.ts完整定义如下export interface KubeResourceQuota extends KubeObjectInterface { spec: spec; status?: status; }它继承了 Headlamp 中所有 Kubernetes 资源的公共基接口KubeObjectInterface定义于 frontend/src/lib/k8s/KubeObject.ts后者声明了每个 K8s 对象都具备的三个字段kind: stringREST 资源对应的 Kind采用 CamelCase 命名且不可更新apiVersion?: string资源的 API 版本metadata: KubeMetadata对象的元数据名称、命名空间、uid、labels、annotations、creationTimestamp 等。而KubeResourceQuota在基接口之上只追加了两个配额专属字段字段类型说明specspec必选用户声明的配额期望核心是hard硬上限status尚未生成时 spec 仍存在statusstatus可选集群控制器回填的实际用量与配额快照配额对象刚创建时可能缺失接口的层级关系为KubeObjectInterface→KubeResourceQuota在 API 文档中体现为 接口层级说明。spec 与 status配额声明的两个半场Kubernetes 的 ResourceQuota 机制是用户声明 控制器回填的双层结构Headlamp 的接口定义如实反映了这一点。spec与status两个局部接口都定义在同一文件 resourceQuota.ts 中。spec声明配额上限interface spec { hard: { [key: string]: string; }; scopes?: string[]; scopeSelector?: { matchExpressions: { operator: string; scopeName: string; values: string[]; }[]; }; }hard必选配额硬上限的映射表键为资源名称值为 Kubernetes quantity 字符串。常见键包括cpu、memory、requests.cpu、requests.memory、limits.cpu、limits.memory、persistentvolumeclaims、pods、count/deployments.apps等scopes可选配额的作用范围集合例如BestEffort仅限 BestEffort 优先级 Pod、NotTerminating排除终止中 Pod、PriorityClass等scopeSelector可选通过matchExpressionsoperator、scopeName、values实现比scopes更精细的匹配规则。status控制器回填的实时数据interface status { hard: { [key: string]: string; }; used: { [key: string]: string; }; }hard控制器根据当前生效范围计算出的配额值快照可能与spec.hard略有出入例如 scopeSelector 过滤后used当前命名空间内各类资源已经消耗的量。正是status.used与status.hard的对比构成了 Headlamp 界面上已用/上限展示的数据来源。ResourceQuota 类接口的运行时载体KubeResourceQuota接口本身只描述数据结构真正承载 API 交互与派生计算的是同文件中的ResourceQuota类resourceQuota.ts。类与接口共享spec/statusgetter但类的职责更丰富。类级元信息class ResourceQuota extends KubeObjectKubeResourceQuota { static kind ResourceQuota; static apiName resourcequotas; static apiVersion v1; static isNamespaced true; ... }kind、apiName、apiVersion用于构造对 API Server 的请求GET /api/v1/namespaces/{ns}/resourcequotasisNamespaced true表明 ResourceQuota 是命名空间级资源列表页因此受命名空间过滤器约束getBaseObject()会预置spec: { hard: {} }空壳供新建资源的表单初始化使用。三个核心 getterrequests、limits、resourceStats是 Headlamp 界面消费该对象的主要入口三者都遍历spec.hard/status并借助normalizeUnit定义于 frontend/src/lib/util.ts把 Kubernetes quantity如500m、1Gi、2归一化为易读文本Getter返回类型过滤规则输出形态requestsstring[]cpu、memory、requests.*requests.cpu: 100m/500mused/hardlimitsstring[]limits.*limits.memory: 128Mi/512MiresourceStats{name, hard, used}[]status.hard全部键供表格逐行渲染的原始三元组其中requests/limits在status.used缺失时以0兜底保证对象刚创建、控制器尚未回填时界面不会报错。从接口到界面列表页的请求/限制展示列表页组件 frontend/src/components/resourceQuota/List.tsx 使用ResourceQuota.useList()拉取数据并通过ResourceQuotaRenderer渲染列定义包括name、namespace、cluster、requests、limits、labels、age。其中{ id: requests, label: t(translation|Request), getValue: item item.requests.join(, ), render: item { const requests: ReactNode[] []; item.requests.forEach((request: string) { requests.push(PaddedChip label{request} variantoutlined sizesmall /); }); return WrappingBox{requests}/WrappingBox; }, },表格的文本导出getValue直接复用requestsgetter 拼接结果单元格渲染render把每个requests.cpu: 100m/500m形式的字符串渲染成一个个 outlined Chip标签并用可换行的WrappingBox容器包裹避免条目过多时撑破布局limits列的渲染逻辑与requests完全对称对应item.limits列表页标题旁还挂载了CreateResourceButton resourceClass{ResourceQuota}支持直接新建配额对象。详情页用量进度条与归一化单位详情页 frontend/src/components/resourceQuota/Details.tsx 通过DetailsGrid渲染对象元数据并把resourceStats交给ResourceQuotaTable展示Resource / Used / Hard / Usage四列。用量占比计算 getUsageRatioexport function getUsageRatio(name: string, used: string, hard: string): number { const resourceType name.includes(.) ? name.split(.).pop()! : name; ... if (hardNum 0) return 0; return usedNum / hardNum; }该函数按资源类型分支解析数值cpu优先用parseCpu解析带n/u/m后缀的 CPU 量否则按整数核数乘以TO_ONE_CPU换算memory/storage/ephemeral-storage及hugepages-*走parseRam解析字节量其余计数类资源如pods、count/...直接parseInt。返回的比值可能大于 1用量超额hard为 0 时返回 0 避免除零。进度条颜色分级与截断QuotaUsageBar组件把比值换算成百分比并用Math.min(percentage, 100)截断进度条长度超出 100% 时条满但文字仍显示真实百分比占比 ≥ 90%红色error告警超额风险占比 ≥ 80%黄色warning其余绿色success。同时aria-label与aria-valuetext提供了无障碍描述进度条本身由 MUILinearProgress实现。单位归一化显示ResourceQuotaTable的 Used/Hard 列会先调用normalizeUnitfrontend/src/lib/util.ts把 quantity 归一化cpu输出1 core/2 coresmemory按二进制Ki/Mi/Gi/Ti/Pi/Ei与十进制m/u/n/k/M/G/T/P/E后缀换算为字节后自动挑选 KB/MB/GB 等可读单位。若原始值与归一化值数值不同则显示为500m (0.5 cores)的形式兼顾精确与可读。类型消费从 API 文档到实际代码的印证围绕KubeResourceQuota的完整资料链包括接口文档docs/development/api/interfaces/lib_k8s_resourceQuota.KubeResourceQuota.md模块文档docs/development/api/modules/lib_k8s_resourceQuota.md导出ResourceQuota类与KubeResourceQuota接口类文档docs/development/api/classes/lib_k8s_resourceQuota.ResourceQuota.md列出requests、limits、resourceStats、spec、status五个 accessor以及继承自makeKubeObject的useList、useGet、apiList等静态方法基接口KubeObjectInterface的字段语义参见 frontend/src/lib/k8s/KubeObject.ts。这意味着开发者在插件中只需import ResourceQuota from kinvolk/headlamp-plugin/lib/k8s/resourceQuota这类方式引入后即可通过ResourceQuota.useList()订阅配额数据再借助requests、limits、resourceStats三个 getter 快速构建自定义的配额看板而不必自己解析 Kubernetes quantity 字符串。小结KubeResourceQuota是 Headlamp 前端数据模型与 KubernetesResourceQuotaAPI 之间的类型契约spec.hard承载用户声明、status.used承载控制器回填二者经ResourceQuota类的三个 getter 与normalizeUnit/parseCpu/parseRam等工具函数加工后最终呈现为列表页的 Chip 标签和详情页的用量进度条。理解这一数据模型是扩展 Headlamp 配额相关 UI 或编写自定义配额视图的第一步。【免费下载链接】headlampA Kubernetes web UI that is fully-featured, user-friendly and extensible项目地址: https://gitcode.com/GitHub_Trending/he/headlamp创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
