管理大頁
在叢集中配置和管理大頁作為可排程資源。
功能狀態:
Kubernetes v1.14 [stable]
(預設啟用:true)Kubernetes 支援 Pod 中應用程式對預分配大頁的分配和使用。本頁描述了使用者如何使用大頁。
準備工作
Kubernetes 節點必須預分配大頁,以便節點報告其大頁容量。
節點可以預分配多種大小的大頁,例如,/etc/default/grub
中的以下行分配 2*1GiB
的 1 GiB 大頁和 512*2 MiB
的 2 MiB 大頁。
GRUB_CMDLINE_LINUX="hugepagesz=1G hugepages=2 hugepagesz=2M hugepages=512"
節點將自動發現並報告所有大頁資源作為可排程資源。
當您描述節點時,您應該在 Capacity
和 Allocatable
部分看到類似以下內容:
Capacity:
cpu: ...
ephemeral-storage: ...
hugepages-1Gi: 2Gi
hugepages-2Mi: 1Gi
memory: ...
pods: ...
Allocatable:
cpu: ...
ephemeral-storage: ...
hugepages-1Gi: 2Gi
hugepages-2Mi: 1Gi
memory: ...
pods: ...
注意
對於動態分配的頁面(啟動後),Kubelet 需要重新啟動以反映新的分配。API
大頁可以透過容器級資源需求來使用,使用資源名稱 hugepages-<size>
,其中 <size>
是特定節點支援的最緊湊的二進位制表示的整數值。例如,如果一個節點支援 2048KiB 和 1048576KiB 的頁面大小,它將暴露可排程資源 hugepages-2Mi
和 hugepages-1Gi
。與 CPU 或記憶體不同,大頁不支援超額使用。請注意,請求大頁資源時,也必須請求記憶體或 CPU 資源。
一個 Pod 可以在單個 Pod 規約中消費多種大頁大小。在這種情況下,它必須為所有卷掛載使用 medium: HugePages-<hugepagesize>
標記。
apiVersion: v1
kind: Pod
metadata:
name: huge-pages-example
spec:
containers:
- name: example
image: fedora:latest
command:
- sleep
- inf
volumeMounts:
- mountPath: /hugepages-2Mi
name: hugepage-2mi
- mountPath: /hugepages-1Gi
name: hugepage-1gi
resources:
limits:
hugepages-2Mi: 100Mi
hugepages-1Gi: 2Gi
memory: 100Mi
requests:
memory: 100Mi
volumes:
- name: hugepage-2mi
emptyDir:
medium: HugePages-2Mi
- name: hugepage-1gi
emptyDir:
medium: HugePages-1Gi
一個 Pod 只有在請求一種大小的大頁時才可以使用 medium: HugePages
。
apiVersion: v1
kind: Pod
metadata:
name: huge-pages-example
spec:
containers:
- name: example
image: fedora:latest
command:
- sleep
- inf
volumeMounts:
- mountPath: /hugepages
name: hugepage
resources:
limits:
hugepages-2Mi: 100Mi
memory: 100Mi
requests:
memory: 100Mi
volumes:
- name: hugepage
emptyDir:
medium: HugePages
- 大頁請求必須等於限制。如果指定了限制但未指定請求,則這是預設行為。
- 大頁在容器範圍內隔離,因此每個容器在自己的 cgroup 沙箱中都有一個限制,正如容器規約中請求的那樣。
- 由大頁支援的 EmptyDir 卷不能消耗超過 Pod 請求的大頁記憶體。
- 透過
shmget()
和SHM_HUGETLB
使用大頁的應用程式必須使用與proc/sys/vm/hugetlb_shm_group
匹配的補充組執行。 - 名稱空間中的大頁使用可以透過 ResourceQuota 控制,類似於使用
hugepages-<size>
令牌的其他計算資源(如cpu
或memory
)。
最後修改於 2024 年 6 月 6 日太平洋標準時間上午 12:21:修復功能狀態 (53da5f74ab)