Hello Henryk, at 14:04 you are clearly confusing requests and limits. Limits are defined at the container runtime level by the kubelet when creating the pod, they are written to control groups definitions, and then managed by the kernel. That causes slowness if cpu-sets are too low, and OOMkills if memory limmit is set too low. Request only affects the kube-scheduler, and defines how the pod is scheduled amongst available worker nodes, regarding available requested resources on each node. That means best-effort QoS class is not seen by the scheduler, and it can cause issues when lots of best-effort pods are running on a node
@isitobservable
2 жыл бұрын
Hi Serge, i guess i was unclear. If the request are not well defined then our workload does not have enough CPU cycle or memory to start properly....my mistake . Thanks for sharing your feedback. Merry Xmas
@sergehartmann
2 жыл бұрын
Actually, your workloads will have enough cpu and memory whatever you set for requests.cpu and requests.memory, unless you reach the node's saturation, or the workload reaches limits.cpu or limits.memory. That's why it is important to set low defaults in every namespace - that enforces explicit resources. Something like this : $ kubectl describe limitrange mem-min-max Name: mem-min-max Namespace: iam Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio ---- -------- --- --- --------------- ------------- ----------------------- Container cpu 50m 2 150m 500m - Container memory 16Mi 4Gi 32Mi 64Mi -
Пікірлер: 3