From 4759a9f652603cd83de75420969bd5571da66019 Mon Sep 17 00:00:00 2001 From: nonylene Date: Thu, 21 Apr 2022 16:08:38 +0900 Subject: [PATCH] scheduling-eviction/pod-overhaed.md: Fix a typo Bustrable -> Burstable --- content/en/docs/concepts/scheduling-eviction/pod-overhead.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/scheduling-eviction/pod-overhead.md b/content/en/docs/concepts/scheduling-eviction/pod-overhead.md index d5db85dadf..b0fd8e97b4 100644 --- a/content/en/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/en/docs/concepts/scheduling-eviction/pod-overhead.md @@ -113,7 +113,7 @@ requests and the overhead, then looks for a node that has 2.25 CPU and 320 MiB o Once a Pod is scheduled to a node, the kubelet on that node creates a new {{< glossary_tooltip text="cgroup" term_id="cgroup" >}} for the Pod. It is within this pod that the underlying container runtime will create containers. -If the resource has a limit defined for each container (Guaranteed QoS or Bustrable QoS with limits defined), +If the resource has a limit defined for each container (Guaranteed QoS or Burstable QoS with limits defined), the kubelet will set an upper limit for the pod cgroup associated with that resource (cpu.cfs_quota_us for CPU and memory.limit_in_bytes memory). This upper limit is based on the sum of the container limits plus the `overhead` defined in the PodSpec.