kubernetes 大页的单位是页面,而不是等效的内存字节,

irtuqstp  于 6个月前  发布在  Kubernetes
关注(0)|答案(5)|浏览(64)

发生了什么?
在处理大页资源时,资源的单位是整个页面(通常是2Mi或1Gi的大小)。资源的单位不是内存字节的数量。使用大页资源的用户请求X个页面,而不是X字节的内存。
在我们使用resource-topology-exporter和NUMA感知调度插件的情况下,我们看到了关于大页资源的不准确报告。例如,我们的计算工作节点有两个NUMA单元,每个NUMA单元有256Gi的RAM。其中256Gi RAM中,我们创建了224个1Gi的大页,这些大页可以分配给节点上的工作负载。
不幸的是,当我们查看每个NUMA单元报告的数量时,我们得到的是:

root@b37dev07c2mg01 [ ~ ]# kubectl get noderesourcetopologies/b37dev07c1co02 -ojsonpath='{.zones}' | jq
[
  {
    "costs": [
      {
        "name": "node-0",
        "value": 10
      },
      {
        "name": "node-1",
        "value": 20
      }
    ],
    "name": "node-0",
    "resources": [
      {
        "allocatable": "58",
        "available": "45",
        "capacity": "58",
        "name": "mellanox.com/mlnx_sriov_vfio"
      },
      {
        "allocatable": "52",
        "available": "44",
        "capacity": "56",
        "name": "cpu"
      },
      {
        "allocatable": "240518168576",
        "available": "201863462912",
        "capacity": "240518168576",
        "name": "hugepages-1Gi"
      },
      {
        "allocatable": "28606324736",
        "available": "25636757503",
        "capacity": "269661364224",
        "name": "memory"
      },
      {
        "allocatable": "6",
        "available": "6",
        "capacity": "6",
        "name": "mellanox.com/mlnx_sriov"
      }
    ],
    "type": "Node"
  },
  {
    "costs": [
      {
        "name": "node-0",
        "value": 20
      },
      {
        "name": "node-1",
        "value": 10
      }
    ],
    "name": "node-1",
    "resources": [
      {
        "allocatable": "6",
        "available": "6",
        "capacity": "6",
        "name": "mellanox.com/mlnx_sriov"
      },
      {
        "allocatable": "58",
        "available": "58",
        "capacity": "58",
        "name": "mellanox.com/mlnx_sriov_vfio"
      },
      {
        "allocatable": "52",
        "available": "52",
        "capacity": "56",
        "name": "cpu"
      },
      {
        "allocatable": "240518168576",
        "available": "240518168576",
        "capacity": "240518168576",
        "name": "hugepages-1Gi"
      },
      {
        "allocatable": "29461528576",
        "available": "29461528576",
        "capacity": "270516568064",
        "name": "memory"
      }
    ],
    "type": "Node"
  }
]

在resource-topology-exporter中,它们通过计算页面总数所代表的总字节数来计算大页资源的数量。
他们这样做是因为上游Kubernetes使用字节作为单位,而不是页面,我不确定上游为什么这样做......大页应该更像不可分割的CPU,分配给特定的消费者,不能在多个消费者之间共享。将大页的单位等于内存量a)使大页看起来就像内存资源(可以在消费者之间共享),并且b)对于消耗大页资源的应用程序来说令人困惑,因为这些应用程序通常请求X个大页,而不是Y字节的数量。
你期望发生什么?
将大页资源视为页面,而不是内存字节。
我们如何尽可能精确地重现它?
n/a
我们需要了解其他信息吗?

  • 无响应*

Kubernetes版本
支持大页的所有版本...
云提供商
n/a
操作系统版本
Linux
安装工具

  • 无响应*

容器运行时(CRI)和版本(如适用)

  • 无响应*

相关插件(CNI、CSI等)和版本(如适用)

hec6srdp

hec6srdp2#

感谢这个精彩的报告!这涉及到非树组件(它们的共同作者发言),所以我们需要检查这个bug是在这些组件中还是在核心k8s中。我将开始审查核心k8s如何处理巨页(我在这里有点生疏)-调度插件和RTE(顺便说一下,还有NFD)应该像核心k8s一样处理巨页。

0vvn1miw

0vvn1miw3#

/triage已接受
数据点:kubelet确实将巨页报告为内存(大小*数量),而不是它们的数量。因此,上述第三方工具(正确地)正在执行与kubelet相同的操作。
这是我拥有16个1GI巨页的节点的一段摘录。资源被报告为内存,而不是计数。

status:
  addresses:
  - address: A.B.C.D
    type: InternalIP
  - address: hostA.lab.fromani.io
    type: Hostname
  allocatable:
    cpu: "96"
    ephemeral-storage: "430526257257"
    hugepages-1Gi: 16Gi
    hugepages-2Mi: "0"
    memory: 79631188Ki
    pods: "250"
  capacity:
    cpu: "104"
    ephemeral-storage: 468315972Ki
    hugepages-1Gi: 16Gi
    hugepages-2Mi: "0"
    memory: 97534804Ki
    pods: "250"

我也同意报告页面计数更准确:工作负载不能请求页面的一部分。问题是:这是一个长期确立的行为,因此更改它很复杂。

0pizxfdo

0pizxfdo4#

/kind feature
/remove-kind bug

相关问题