Shulou(Shulou.com)05/31 Report--

Today, I will talk to you about how to better set up Request and Limit in the deployment of Kubernetes services. Many people may not know much about it. In order to make you understand better, the editor has summarized the following for you. I hope you can get something from this article.

How do I configure Request and Limit for the container? This is a common and thorny problem, which varies according to the type of service, requirements and scenarios, and there is no fixed answer. Here are some best practices based on production experience.

Request should be set for all containers

The value of request does not refer to the actual size of resources allocated to the container, it is just for the scheduler, which "observes" how many resources each node can use for allocation and knows how many resources have been allocated to each node. The size of the allocated resource is the sum of the container request defined in all the Pod on the node, which can calculate how many remaining resources of the node can be allocated (allocatable resources minus the sum of allocated request). If it is found that the size of the remaining allocable resources of the node is smaller than the reuqest of the Pod to be scheduled, then scheduling to this node will not be considered, otherwise, scheduling will be possible. Therefore, if you do not configure request, then the scheduler cannot know how many resources the node has been allocated, and the scheduler cannot get accurate information, and it will not be able to make reasonable scheduling decisions, which can easily lead to unreasonable scheduling. Some nodes may be idle, while some nodes may be busy or even NotReady.

Therefore, the suggestion is to set request for all containers to make the scheduler aware of how many resources are allocated to the nodes, so as to make reasonable scheduling decisions, so that the resources of the cluster nodes can be reasonably allocated and used, so as to avoid some accidents caused by uneven resource allocation.

What if I keep forgetting to set it?

Sometimes we forget to set request and limit for some containers. In fact, we can use LimitRange to set the default request and limit values of namespace, and it can also be used to limit the minimum and maximum request and limit. Example:

ApiVersion: v1kind: LimitRangemetadata: name: mem-limit-range namespace: testspec: limits:-default: memory: 512Mi cpu: 500m defaultRequest: memory: 256Mi cpu: 100m type: Container important online applications how to set up

When the node is short of resources, automatic eviction will be triggered, and some low-priority Pod will be deleted to release resources for the node to heal itself. The Pod without setting request,limit has the lowest priority and is easy to be expelled; the request is not equal to the second of limit; and the Pod with request equals limit has higher priority and is not easily expelled. Therefore, if it is an important online application, and you do not want to be expelled in the event of a node failure and the online business will be affected, it is recommended to make request and limit consistent.

How to set up to improve the utilization of resources

If you set a high request value for your application, and the actual resource consumption is far less than its request value for a long time, the overall resource utilization of the node is low. Of course, this is except for the service which is very sensitive to the delay, because the sensitive service itself does not expect the node utilization to be too high, which will affect the speed of sending and receiving network packets. Therefore, for some non-core applications that do not occupy resources for a long time, we can appropriately reduce request to improve resource utilization.

If your service supports horizontal expansion, the request value of a single copy can generally be set to no more than 1 core, except for CPU-intensive applications. For example, coredns can be set to 0.1 core, that is, 100m.

Try to avoid using too large request and limit

If your service uses a single copy or a small number of copies, give a large request and limit, and allocate enough resources to support the business, then a replica failure may have a greater impact on the business, and because the request is larger, when the resource allocation in the cluster is more fragmented, if the node where the Pod is located dies, and the other node does not have enough remaining allocable resources to meet the request of the Pod This Pod will not be able to achieve drift, it will not be able to heal itself, aggravating the impact on the business.

On the contrary, it is recommended to minimize request and limit and expand your service support capacity horizontally by adding replicas to make your system more flexible and reliable.

Avoid consuming too many resources in testing namespace to affect production business

If the production cluster has a namespace for testing, if it is not restricted, the cluster load may be too high, thus affecting the production business. You can use ResourceQuota to limit the total size of request and limit for testing namespace. Example:

ApiVersion: v1kind: ResourceQuotametadata: name: quota-test namespace: testspec: hard: requests.cpu: "1" requests.memory: 1Gi limits.cpu: "2" limits.memory: 2Gi after reading the above, do you have any further understanding of how to better set up Request and Limit in Kubernetes service deployment? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.