148422597X Kubernetes Management Design Patterns [Vohra 2017-01-29] {E559F6BB}
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
- Page 203 and 204: Chapter 8 ■ Using Rolling Updates
- Page 205 and 206: Chapter 8 ■ Using Rolling Updates
- Page 207 and 208: Chapter 8 ■ Using Rolling Updates
- Page 209 and 210: Chapter 8 ■ Using Rolling Updates
- Page 211 and 212: Chapter 8 ■ Using Rolling Updates
- Page 213 and 214: Chapter 8 ■ Using Rolling Updates
- Page 215 and 216: Chapter 9 ■ Scheduling Pods on No
- Page 217 and 218: Chapter 9 ■ Scheduling Pods on No
- Page 219 and 220: Chapter 9 ■ Scheduling Pods on No
- Page 221 and 222: Chapter 9 ■ Scheduling Pods on No
- Page 223 and 224: Chapter 9 ■ Scheduling Pods on No
- Page 225 and 226: Chapter 9 ■ Scheduling Pods on No
- Page 227 and 228: Chapter 9 ■ Scheduling Pods on No
- Page 229 and 230: Chapter 9 ■ Scheduling Pods on No
- Page 231 and 232: Chapter 9 ■ Scheduling Pods on No
- Page 233 and 234: Chapter 9 ■ Scheduling Pods on No
- Page 235 and 236: Chapter 9 ■ Scheduling Pods on No
- Page 237 and 238: Chapter 9 ■ Scheduling Pods on No
- Page 239 and 240: Chapter 9 ■ Scheduling Pods on No
- Page 241 and 242: Chapter 9 ■ Scheduling Pods on No
- Page 243 and 244: Chapter 9 ■ Scheduling Pods on No
- Page 245 and 246: Chapter 9 ■ Scheduling Pods on No
- Page 247 and 248: Chapter 9 ■ Scheduling Pods on No
- Page 249 and 250: Chapter 9 ■ Scheduling Pods on No
- Page 251 and 252: Chapter 9 ■ Scheduling Pods on No
- Page 253: Chapter 10 ■ Configuring Compute
- Page 257 and 258: Chapter 10 ■ Configuring Compute
- Page 259 and 260: Chapter 10 ■ Configuring Compute
- Page 261 and 262: Chapter 10 ■ Configuring Compute
- Page 263 and 264: Chapter 10 ■ Configuring Compute
- Page 265 and 266: Chapter 10 ■ Configuring Compute
- Page 267 and 268: Chapter 10 ■ Configuring Compute
- Page 269 and 270: Chapter 10 ■ Configuring Compute
- Page 271 and 272: Chapter 10 ■ Configuring Compute
- Page 273 and 274: Chapter 11 ■ Using ConfigMapsIn t
- Page 275 and 276: Chapter 11 ■ Using ConfigMapsFigu
- Page 277 and 278: Chapter 11 ■ Using ConfigMapsNext
- Page 279 and 280: Chapter 11 ■ Using ConfigMapsThe
- Page 281 and 282: Chapter 11 ■ Using ConfigMapsCrea
- Page 283 and 284: Chapter 11 ■ Using ConfigMapsFigu
- Page 285 and 286: Chapter 11 ■ Using ConfigMapsCrea
- Page 287 and 288: Chapter 11 ■ Using ConfigMapsFigu
- Page 289 and 290: Chapter 11 ■ Using ConfigMapsCons
- Page 291 and 292: Chapter 11 ■ Using ConfigMapsmoun
- Page 293 and 294: CHAPTER 12Using Resource QuotasIn C
- Page 295 and 296: Chapter 12 ■ Using Resource Quota
- Page 297 and 298: Chapter 12 ■ Using Resource Quota
- Page 299 and 300: Chapter 12 ■ Using Resource Quota
- Page 301 and 302: Chapter 12 ■ Using Resource Quota
- Page 303 and 304: Chapter 12 ■ Using Resource Quota
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