The website uses cookies to optimize your user experience. Using this website grants us the permission to collect certain information essential to the provision of our services to you, but you may change the cookie settings within your browser any time you wish. Learn more
I agree
Text direction?

Manage HugePages

Configure and manage huge pages as a schedulable resource in a cluster.
FEATURE STATE: Kubernetes v1.18 [stable]

Kubernetes supports the allocation and consumption of pre-allocated huge pages by applications in a Pod. This page describes how users can consume huge pages.

Before you begin

  1. Kubernetes nodes must pre-allocate huge pages in order for the node to report its huge page capacity. A node can pre-allocate huge pages for multiple sizes.

The nodes will automatically discover and report all huge page resources as schedulable resources.


Huge pages can be consumed via container level resource requirements using the resource name hugepages-<size>, where <size> is the most compact binary notation using integer values supported on a particular node. For example, if a node supports 2048KiB and 1048576KiB page sizes, it will expose a schedulable resources hugepages-2Mi and hugepages-1Gi. Unlike CPU or memory, huge pages do not support overcommit. Note that when requesting hugepage resources, either memory or CPU resources must be requested as well.

A pod may consume multiple huge page sizes in a single pod spec. In this case it must use medium: HugePages-<hugepagesize> notation for all volume mounts.

apiVersion:v1kind:Podmetadata:name:huge-pages-examplespec:containers:- name:exampleimage:fedora:latestcommand:- sleep- infvolumeMounts:- mountPath:/hugepages-2Miname:hugepage-2mi- mountPath:/hugepages-1Giname:hugepage-1giresources:limits:hugepages-2Mi:100Mihugepages-1Gi:2Gimemory:100Mirequests:memory:100Mivolumes:- name:hugepage-2miemptyDir:medium:HugePages-2Mi- name:hugepage-1giemptyDir:medium:HugePages-1Gi

A pod may use medium: HugePages only if it requests huge pages of one size.

apiVersion:v1kind:Podmetadata:name:huge-pages-examplespec:containers:- name:exampleimage:fedora:latestcommand:- sleep- infvolumeMounts:- mountPath:/hugepagesname:hugepageresources:limits:hugepages-2Mi:100Mimemory:100Mirequests:memory:100Mivolumes:- name:hugepageemptyDir:medium:HugePages
  • Huge page requests must equal the limits. This is the default if limits are specified, but requests are not.
  • Huge pages are isolated at a container scope, so each container has own limit on their cgroup sandbox as requested in a container spec.
  • EmptyDir volumes backed by huge pages may not consume more huge page memory than the pod request.
  • Applications that consume huge pages via shmget() with SHM_HUGETLB must run with a supplemental group that matches proc/sys/vm/hugetlb_shm_group.
  • Huge page usage in a namespace is controllable via ResourceQuota similar to other compute resources like cpu or memory using the hugepages-<size> token.
  • Support of multiple sizes huge pages is feature gated. It can be enabled with the HugePageStorageMediumSize feature gate on the kubeletAn agent that runs on each node in the cluster. It makes sure that containers are running in a pod. and kube-apiserverControl plane component that serves the Kubernetes API. (--feature-gates=HugePageStorageMediumSize=true).
Related Notes
Get a free MyMarkup account to save this article and view it later on any device.
Create account

End User License Agreement

Summary | 7 Annotations
pre-allocate huge pages
2020/06/18 12:59
huge page capacity
2020/06/18 12:59
pre-allocate huge pages for multiple sizes
2020/06/18 13:00
discover and report all huge page resources as schedulable resources
2020/06/18 13:01
huge pages do not support overcommit
2020/06/18 13:02
2020/06/18 13:02
2020/06/18 13:03