Kubernetes / Understanding CPU Resource Limits

Question

Of the many years of running node / rails bare metal applications; I used to be able to run as many applications as I wanted on one machine (say, 2Go in the digital ocean can easily process 10 applications without worrying, based on proper optimization or a fairly small amount of traffic).

The thing is, using the kubernets, the game sounds completely different. I installed the "get started" cluster with 2 standard vm (3.75Go).

A deployment constraint has been assigned with the following:

resources: requests: cpu: "64m" memory: "128Mi" limits: cpu: "128m" memory: "256Mi" 

Then the following appears:

 Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits --------- ---- ------------ ---------- --------------- ------------- default api 64m (6%) 128m (12%) 128Mi (3%) 256Mi (6%) 

What does this 6% mean?

I tried to lower the processor limit, for example, 20Mi ... the application starts (obviously, not enough resources). Documents say this is the percentage of CPU. So, 20% of the 3.75Go car? Then where did these 6% come from?

Then the size of node -pool is increased to n1-standard-2, the same block effectively covers 3% of node. This sounds logical, but what does it actually refer to?

Think about which indicators to consider for this part.

When the application starts, a large amount of memory is required, but then it uses only a minimal part of this 6%. Then I feel like I don’t understand something or am misusing it all

Thanks for any expert advice / tips to better understand the Best

Answer 1

6% of the CPU means that 6% (CPU requests) of processor time nodes are reserved for this module. Thus, he guaranteed that he would always get this amount of processor time for rent. It can still fly up to 12% (CPU limits) if CPU time is left.

This means that if the limit is very low, the launch of your application will take longer. Therefore , the viability sensor can kill the pod before it is ready, because the application took too much time. To solve this problem, you may need to increase initialDelaySeconds or timeoutSeconds .

---

Also note that requests and resource limits determine how much resources your module allocates, not actual usage.

• A resource request is what your module is guaranteed to receive on the node. This means that the sum of requested resources should not exceed the total amount of CPU / memory on this node.
• The resource limit is the upper limit of what your module is allowed to use. This means that the sum of these resources may be higher than the actual available processor / memory.

Therefore, percentages tell you how much CPU and memory your module allocates from shared resources.

Link to documents: https://kubernetes.io/docs/user-guide/compute-resources/

Some other noteworthy things:

• If your module uses more memory than defined in the limit, it gets OOMKilled (not enough memory).
• If your module uses more memory than specified in the requests, and the node uses our memory, the module can get OOMKilled to guarantee the survival of other modules that use less requested memory.
• If your application requires more processor resources than requested, it can reach the limit.
• Your module will never be killed because it uses too much processor.

Answer 2

According to docs, CPU requests (and restrictions) are always fractions of the available processor cores on a node, that module (with resources.requests.cpu of "1" means reserving one processor core exclusively for one block). Fractions are allowed, so a CPU request of "0.5" reserve half the processor for one module.

For convenience, Kubernetes allows you to specify requests / limits of CPU resources in millicor:

The expression 0.1 equivalent to the expression 100m , which can be read as “one hundred millikpu” (some may say “one hundred millikors”, and this is understood to be the same when it comes to Kubernet). A query with a decimal point, such as 0.1 , is converted to a 100m API, and accuracy less than 1m not allowed.

As mentioned in another answer, resource requests are guaranteed. This means that Kubernetes will plan the containers so that the sum of all requests does not exceed the number of resources actually available on the node.

So, by requesting 64m processor time in your deployment, you are actually requesting 64/1000 = 0.064 = 6.4% of one of the node processor core time. So where is your 6% come from. When upgrading to a virtual machine with a large number of processor cores, the amount of available CPU resources increases, therefore, on a machine with two available processor cores, a request for 6.4% of one processor time will allocate 3.2% of the processor time to two processors.