第三方设备指标达到 GA

随着 Kubernetes 1.20 的发布，管理大规模 Kubernetes 集群的基础架构团队将看到两个令人兴奋且期待已久的特性正式发布

• Pod Resources API（于 1.13 引入）最终正式发布 (GA)。这使得 Kubernetes 插件能够获取节点的资源使用和分配信息；例如：哪个 Pod/容器正在使用哪个设备。
• DisableAcceleratorMetrics 特性（于 1.19 引入）正在晋升至 Beta，并将默认启用。这会移除 kubelet 报告的设备指标，转而支持新的插件架构。

许多与基础设备支持相关的特性（设备发现、插件和监控）正在达到高度稳定水平。Kubernetes 用户应将这些特性视为开启更复杂用例（网络、调度、存储等）的基石！

一个这样的例子是非均匀内存访问 (NUMA) 放置，在选择设备时，应用通常希望确保 CPU 内存和设备内存之间的数据传输尽可能快。在某些情况下，不正确的 NUMA 放置会抵消将计算卸载到外部设备的益处。

如果您对这些话题感兴趣，可以考虑加入 Kubernetes Node 特殊兴趣小组 (SIG) 讨论所有与 Kubernetes 节点相关的话题，或加入 COD (容器编排设备) 工作组讨论与运行时相关的话题，或加入资源管理论坛讨论与资源管理相关的话题！

Pod Resources API - 它为何需要存在？

Kubernetes 是一个供应商中立的平台。如果我们要支持设备监控，在 Kubernetes 代码库中添加供应商特定的代码并非理想解决方案。最终，设备是需要深厚专业知识的领域，最适合在该领域添加和维护代码的人是设备供应商本身。

Pod Resources API 是解决此问题的方案。每个供应商都可以构建和维护自己的树外监控插件。这个监控插件通常作为集群内的单独 Pod 部署，然后可以将设备发出的指标与正在使用该设备的 Pod 关联起来。

例如，使用 NVIDIA GPU dcgm-exporter 抓取 Prometheus 格式的指标

$ curl -sL http://127.0.01:8080/metrics


# HELP DCGM_FI_DEV_SM_CLOCK SM clock frequency (in MHz).
# TYPE DCGM_FI_DEV_SM_CLOCK gauge
# HELP DCGM_FI_DEV_MEM_CLOCK Memory clock frequency (in MHz).
# TYPE DCGM_FI_DEV_MEM_CLOCK gauge
# HELP DCGM_FI_DEV_MEMORY_TEMP Memory temperature (in C).
# TYPE DCGM_FI_DEV_MEMORY_TEMP gauge
...
DCGM_FI_DEV_SM_CLOCK{gpu="0", UUID="GPU-604ac76c-d9cf-fef3-62e9-d92044ab6e52",container="foo",namespace="bar",pod="baz"} 139
DCGM_FI_DEV_MEM_CLOCK{gpu="0", UUID="GPU-604ac76c-d9cf-fef3-62e9-d92044ab6e52",container="foo",namespace="bar",pod="baz"} 405
DCGM_FI_DEV_MEMORY_TEMP{gpu="0", UUID="GPU-604ac76c-d9cf-fef3-62e9-d92044ab6e52",container="foo",namespace="bar",pod="baz"} 9223372036854775794

每个 Agent 都应遵守节点监控指南。换句话说，插件应生成 Prometheus 格式的指标，并且新指标不应直接依赖于 Kubernetes 基本组件。

这使得指标消费者可以使用兼容的监控管道来收集和分析来自各种 Agent 的指标，即使这些 Agent 由不同的供应商维护。

禁用 NVIDIA GPU 指标 - 警告

随着插件监控系统的正式发布，Kubernetes 正在废弃由 kubelet 报告的 NVIDIA GPU 指标。

随着 DisableAcceleratorMetrics 特性在 Kubernetes 1.20 中默认启用，NVIDIA GPU 在 Kubernetes 中不再是特殊公民。这符合供应商中立的精神，并使最适合的人员能够按照自己的发布计划维护其插件，这是一件好事！

用户现在需要安装 NVIDIA GDGM exporter 或使用 绑定 来收集更准确和完整的 NVIDIA GPU 指标。此废弃意味着您不再能够依赖 kubelet 报告的指标，例如用于收集 NVIDIA GPU 内存利用率的 container_accelerator_duty_cycle 或 container_accelerator_memory_used_bytes。

这意味着过去依赖 kubelet 报告的 NVIDIA GPU 指标的用户，将需要更新其参考并部署 NVIDIA 插件。具体来说，Kubernetes 报告的不同指标映射到以下指标：

您可能还对其他指标感兴趣，例如 DCGM_FI_DEV_GPU_TEMP（GPU 温度）或 DCGM_FI_DEV_POWER_USAGE（功耗）。默认集可在 Nvidia 的 Data Center GPU Manager 文档中找到。

请注意，在此版本中，您仍然可以将 DisableAcceleratorMetrics 功能门 设置为 false，从而有效重新启用 kubelet 报告 NVIDIA GPU 指标的功能。

与 Pod Resources API 的正式发布相结合，这些工具可用于生成 GPU 遥测数据，可在可视化仪表板中使用，如下所示为示例：

Pod Resources API - 我能用它做什么？

该接口一经引入，许多供应商便开始将其用于各种不同的用例！列举几个例子：

kuryr-kubernetes CNI 插件与 intel-sriov-device-plugin 协同工作。这使得 CNI 插件能够知道 kubelet 分配了哪些 SR-IOV 虚拟功能 (VF)，并利用这些信息正确设置容器网络命名空间以及使用具有相应 NUMA 节点的设备。我们还期望此接口用于跟踪已分配和可用资源，并提供有关工作节点 NUMA 拓扑的信息。

另一个用例是 GPU 遥测，其中 GPU 指标可以与分配给 GPU 的容器和 Pod 相关联。一个这样的例子是 NVIDIA 的 dcgm-exporter，但也可以轻松构建其他遵循相同范例的工具。

Pod Resources API 是一个简单的 gRPC 服务，它通知客户端 kubelet 已知的 Pod。信息涉及 kubelet 分配的设备以及 CPU 的分配。这些信息分别来自 kubelet Device Manager 和 CPU Manager 的内部状态。

您可以在下面看到一个 API 示例，以及 Go 客户端如何在几行代码中利用这些信息：

service PodResourcesLister {
    rpc List(ListPodResourcesRequest) returns (ListPodResourcesResponse) {}
    rpc GetAllocatableResources(AllocatableResourcesRequest) returns (AllocatableResourcesResponse) {}

    // Kubernetes 1.21
    rpc Watch(WatchPodResourcesRequest) returns (stream WatchPodResourcesResponse) {}
}

func main() {
	ctx, cancel := context.WithTimeout(context.Background(), connectionTimeout)
	defer cancel()

	socket := "/var/lib/kubelet/pod-resources/kubelet.sock"
	conn, err := grpc.DialContext(ctx, socket, grpc.WithInsecure(), grpc.WithBlock(),
		grpc.WithDialer(func(addr string, timeout time.Duration) (net.Conn, error) {
			return net.DialTimeout("unix", addr, timeout)
		}),
	)

	if err != nil {
		panic(err)
	}

    client := podresourcesapi.NewPodResourcesListerClient(conn)
    resp, err := client.List(ctx, &podresourcesapi.ListPodResourcesRequest{})
	if err != nil {
		panic(err)
	}
	net.Printf("%+v\n", resp)
}

最后，请注意，您可以通过查看 kubelet 的 /metrics 端点上名为 pod_resources_endpoint_requests_total 的新 kubelet 指标，来监控对 Pod Resources 端点的请求次数。

设备监控是否适合生产环境？我可以扩展它吗？我可以贡献代码吗？

是的！此功能于 1.13 版本发布，距今已近两年，已被广泛采用，已被不同的云托管服务使用，并且随着其在 Kubernetes 1.20 中正式发布 (G.A)，它已经达到了生产就绪水平！

如果您是设备供应商，今天就可以开始使用它！如果您只是想监控集群中的设备，请获取您的监控插件的最新版本！

如果您对这个领域充满热情，请加入 Kubernetes 社区，帮助改进 API 或贡献设备监控插件！

致谢

我们感谢为该功能做出贡献或提供反馈的社区成员，包括 WG-Resource-Management、SIG-Node 和资源管理论坛的成员！

• ←上一篇
• 下一篇→