148422597X Kubernetes Management Design Patterns [Vohra 2017-01-29] {E559F6BB}

marco.cirilli
from marco.cirilli More from this publisher
19.06.2021 Views

Types of Compute ResourcesChapter 10 ■ Configuring Compute ResourcesKubernetes provides two types of compute resources, CPUs and memory, as shown in Figure 10-3.Compute ResourcesCPUsMemoryFigure 10-3. Types of compute resourcesA compute resource is also referred to simply as a “resource,” and each resource type is a distinctlymeasurable quantity at the container level. By default a pod’s compute resources are unbounded, onlylimited by the node capacity. A pod’s container could optionally specify resource request and limit levels foreach type of resource, as discussed in the next section. Specifying explicit values for resource request andlimit is recommended for the following reasons:Doing so makes it easier for the Scheduler to assign pods on a node.It makes it easier for a Scheduler to handle excess resources and contention ofresources.Available node capacity could make some pods non-schedulable on thenode if the pod’s containers require more capacity than the node capacity.Specifying resource requests and limits makes feasible a better design of the podscheduling.Separate namespaces could be created for development and productionworkloads with separate resource requests and limits, the resource consumptionbeing different for different types of workloads.More efficient utilization of a cluster’s resources is made feasible by specifyingexplicit requests and limits for resources. While exceeding a node’s capacity isone issue, a node could be underutilized if a pod that consumes only a fraction ofthe node’s capacity is scheduled on the node, with the remaining node capacityneither suitable for scheduling another pod nor used by the pod scheduled.239

Chapter 10 ■ Configuring Compute ResourcesCPUs are the processor cycles and measured in units of CPU cores (or just “CPUs”); one CPU core couldbe one AWS vCPU, one GCP core, one Azure vCore, or one hyperthread on a bare-metal Intel processor withhyperthreading. A value of 1 in the cpu field is 1000 millicpu. The value can be multiples of 1 such as 2, 3, or4. Fractional CPU values can also be specified and translate to x1000 millicpu. For example, a value of .001 is1 millicpu, which is the lowest value that can be specified; a finer precision is not feasible.The memory field unit is bytes and may be set as a plain integer such as 134217728 or 135e6, a fixed-pointinteger with an SI suffix such as 135M, or the binary multiple of bytes equivalent 128Mi.Resource Requests and LimitsIn addition to the limits imposed by a node capacity, a container may request a specific amount of aresource and also impose a limit on the maximum amount of resource a container can be allowed to use.These are called the container request and limit. A container request is the quantity of resource a container isguaranteed; a scheduler won’t assign a pod on a node if the node cannot provide the total of the containers’requests for each of the resource types. A container limit is the maximum quantity of a resource thesystem allows a container to use. While the total of allocated resource requests cannot exceed the nodecapacity limit for the resource, the total of resource limits may exceed the node capacity limit—assumingthat each of the containers on a node won’t be using the maximum resource limit concurrently. Whenthe total of resource limits of all pods running on a node exceeds the node capacity, the node is said to beovercommitted. Each container may exceed the guaranteed resource allocated to it via the resource request,up to the resource limit as long as the total resource consumption on a node does not exceed the nodecapacity. But if due to contention of resources the total of resource consumption by containers on a nodeexceeds the node capacity, or tends to exceed the node capacity, some pods may have to be terminated; andif the restartPolicy is set to Always the pod may be restarted.Resource guarantees are either compressible or incompressible. CPU resource guarantees arecompressible and memory resource guarantees are incompressible. A compressible CPU resource guaranteeimplies that pods or more specifically containers are throttled if they exceed their CPU limit. A containercould be throttled back to its guaranteed CPU level if the excess memory allocated to it is requested byanother process such as a newly started pod or a system task or daemon. If extra CPU is available after allthe pods on the node have been allocated, the minimum requested (guaranteed) CPU and the system tasksand daemons are getting the CPU they need, the extra CPU is distributed among the pods in the proportionof their minimum CPU requests (the guaranteed CPU). For example, if a node has three pods with oneallocated a guaranteed CPU of 150m, the second a guaranteed CPU of 300m, and the third a guaranteedCPU of 450m, the extra CPU is distributed in the same proportion 1:2:3 up to the limit of each container.CPU resource is an elastic resource allocated within the range of the minimum request guarantee and theresource limit. Memory resource guarantee is elastic in one direction only; a container or pod can use morememory than the minimum requested (guaranteed) up to the limit, but if a container consumes morethan the request level memory, the pod could be terminated if another pod that was consuming less thanthe minimum guaranteed level starts to consume more memory or if a system task or daemon requestsmore memory. A container consuming less than and up to the request level guaranteed memory is neverterminated unless some system task or daemon has requested more memory. And a container consumingmore memory than the limit is terminated regardless of excess memory availability.When referring to node capacity, what is implied is node allocable, as some resources must be reservedfor system components and Kubernetes components. The resource request and limit define a range 0 <=request <=Node Allocatable and request <= limit.Pod specification provides the fields shown in Table 10-1 for resource requests and limits.240

Types of Compute Resources

Chapter 10 ■ Configuring Compute Resources

Kubernetes provides two types of compute resources, CPUs and memory, as shown in Figure 10-3.

Compute Resources

CPUs

Memory

Figure 10-3. Types of compute resources

A compute resource is also referred to simply as a “resource,” and each resource type is a distinctly

measurable quantity at the container level. By default a pod’s compute resources are unbounded, only

limited by the node capacity. A pod’s container could optionally specify resource request and limit levels for

each type of resource, as discussed in the next section. Specifying explicit values for resource request and

limit is recommended for the following reasons:

Doing so makes it easier for the Scheduler to assign pods on a node.

It makes it easier for a Scheduler to handle excess resources and contention of

resources.

Available node capacity could make some pods non-schedulable on the

node if the pod’s containers require more capacity than the node capacity.

Specifying resource requests and limits makes feasible a better design of the pod

scheduling.

Separate namespaces could be created for development and production

workloads with separate resource requests and limits, the resource consumption

being different for different types of workloads.

More efficient utilization of a cluster’s resources is made feasible by specifying

explicit requests and limits for resources. While exceeding a node’s capacity is

one issue, a node could be underutilized if a pod that consumes only a fraction of

the node’s capacity is scheduled on the node, with the remaining node capacity

neither suitable for scheduling another pod nor used by the pod scheduled.

239

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!