作者：Francesco Romani（红帽）
podresources API 是由节点本地 kubelet 提供的 API，它公开专门分配给容器的计算资源。随着 Kubernetes 1.28 的发布，该 API 现已正式可用。
它解决什么问题？
kubelet 可以向容器（例如 CPU）分配独占资源，授予对完整核心或内存（区域或大页）的独占访问权限。需要高性能或低延迟（或两者）的工作负载利用这些功能。 kubelet 还可以将设备分配给容器。总的来说，这些支持独占分配的功能被称为“资源管理器”。
如果没有像 podresources 这样的 API，了解资源分配的唯一可能选择是读取资源管理器使用的状态文件。虽然这样做是出于必要，但这种方法的问题是这些文件的路径和格式都是内部实现细节。尽管非常稳定，但项目保留自由更改它们的权利。因此，使用状态文件的内容是脆弱且不受支持的，建议执行此操作的项目考虑迁移到 podresources API 或其他受支持的 API。
API 概述
podresources API 最初是为了实现设备监控而提出的。为了启用监控代理，一个关键的先决条件是启用由 kubelet 执行的设备分配自省。 API 的最初目标就是服务于此目的。 API 的第一次迭代仅实现了一个函数 List ，用于返回有关设备分配给容器的信息。该 API 由 multus CNI 和 GPU 监控工具使用。
自推出以来，podresources API 扩大了其范围，涵盖了除设备管理器之外的其他资源管理器。从 Kubernetes 1.20 开始， List API 还报告 CPU 核心和内存区域（包括大页）； API 还报告设备的 NUMA 位置，同时可以从系统推断 CPU 和内存的位置。
在 Kubernetes 1.21 中，API 获得了 GetAllocatableResources 功能。这个较新的 API 补充了现有的 List API，并使监控代理能够确定未分配的资源，从而启用构建在 podresources API 之上的新功能，例如 NUMA 感知调度程序插件。
最后，在 Kubernetes 1.27 中，引入了另一个功能 Get ，以便与 CNI 元插件更加友好，从而更简单地访问分配给特定 pod 的资源，而不必过滤所有资源节点上的 Pod。 Get 函数当前处于 alpha 级别。
Consuming the API 使用 API
podresources API 由本地 kubelet 提供服务，位于运行的同一节点上。在 Unix 风格上，端点通过 Unix 域套接字提供服务；默认路径是 /var/lib/kubelet/pod-resources/kubelet.sock。在 Windows 上，端点通过命名管道提供服务；默认路径是 npipe://\.\pipe\kubelet-pod-resources 。
为了让容器化监控应用程序使用 API，套接字应安装在容器内。一个好的做法是挂载 podresources 套接字端点所在的目录，而不是直接挂载套接字。这将确保 kubelet 重新启动后，容器化监视器应用程序将能够重新连接到套接字。
假设的监控代理使用 podresources API 并部署为 DaemonSet 的示例清单可能如下所示：
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: podresources-monitoring-app
namespace: monitoring
spec:
selector:
matchLabels:
name: podresources-monitoring
template:
metadata:
labels:
name: podresources-monitoring
spec:
containers:
- args:
- --podresources-socket=unix:///host-podresources/kubelet.sock
command:
- /bin/podresources-monitor
image: podresources-monitor:latest # just for an example
volumeMounts:
- mountPath: /host-podresources
name: host-podresources
serviceAccountName: podresources-monitor
volumes:
- hostPath:
path: /var/lib/kubelet/pod-resources
type: Directory
name: host-podresources我希望您发现以编程方式使用 podresources API 很简单。 kubelet API包提供了协议文件和go类型定义；但是，该项目尚未提供客户端包，并且不应直接使用现有代码。推荐的方法是在您的项目中重新实现客户端，复制并粘贴相关功能，例如 multus 项目正在执行的操作。
在操作使用 podresources API 的容器化监控应用程序时，有几点值得强调，以防止出现“陷阱”：
- 尽管 API 仅公开数据，并且在设计上不允许客户端改变 kubelet 状态，但 gRPC 请求/响应模型需要对 podresources API 套接字进行读写访问。换句话说，不可能将容器挂载限制为 ReadOnly 。
- 允许多个客户端连接到 podresources 套接字并使用 API，因为它是无状态的。
- kubelet 具有内置的速率限制，以减轻行为不当或恶意消费者造成的本地拒绝服务攻击。 API 的使用者必须容忍服务器返回的速率限制错误。速率限制目前是硬编码的和全局的，因此行为不当的客户端可能会消耗所有配额，并可能导致行为正确的客户端挨饿。
Future enhancements 未来的增强功能
由于历史原因，podresources API 的规范不如典型的 kubernetes API（例如 Kubernetes HTTP API 或容器运行时接口）精确。这会导致在极端情况下出现未指定的行为。我们正在努力纠正这种状态并制定更精确的规范。
动态资源分配（DRA）基础设施是对资源管理的重大改革。与 podresources API 的集成已经在进行中。
我们正在努力推荐或创建可供使用的参考客户端包。
Getting involved
此功能由 SIG 节点驱动。请加入我们，与社区建立联系，并分享您对上述功能及其他功能的想法和反馈。我们期待您的回音！
