Original: Kubernetes - Understanding Resources
Author: Ben Visser
Translation: Chi Jianfeng
Source: DockOne.io
Original link: http://www.noqcks.io/note/kubernetes-resources-limits/index.html
Translation link: http://www.dockone.io/article/1977
I don't know if you already know, Kubernetes is a container scheduling system that supports Docker and rkt (currently these two). Besides these nice features like easy deployment, configuration management, service discovery, etc., it also allows us to manage computing resources in a more efficient way. This article will address questions like how the Kubernetes resource model works, why you should always limit container resources, and how to do it right.
The need for resource management
Before Kubernetes, the common way to run containers was to drop the application container onto an instance, and hopefully set up a monitoring system that automatically restarts when the container exits. The problem with this model is that your application on that instance may only be using 10% of the available CPU. You completely waste 90% of the available CPU. Kubernetes will integrate those disconnected instances into a computing resource pool, and multiple applications can be scheduled to a physical instance. It's like "take a whole bunch of wood blocks (containers or tasks) - all shapes and sizes - and find a way to compress all of them into barrels (servers)" (1). If you can schedule these chunks (tasks) very carefully, then you will use fewer buckets (servers).
However, when many containers run on the same instance, a new risk of resource exhaustion arises. If your container suddenly tries to use 100% of the CPU, nothing stops it from using up the CPU of every other container. This is where the Kubernetes resource model comes into play. Now that I've hooked you up with financial incentives and resource depletion risk, allow me to explain how the resource model works.
resource model
What exactly are resources in Kubernetes? Resources are those things that can be "requested", "allocated", "or consumed" by a pod or container. For example, CPU, memory, network bandwidth.
They can be compressible (easy to throttle) or incompressible (not easy to throttle). Memory is incompressible, while CPU and network are compressible because they are easily throttled.
These resources can be divided into two different situations: the desired situation (specification) and the current situation (state). Resource requirements and resource capacities can be thought of as specifications (desired scenarios), and resource usage can be thought of as states (current scenarios). The Kubernetes scheduler can use these two scenarios to infer node capacity, resource requirements, etc.
We can use the terms "quota" and "request" to describe the specification of a resource.
-
Requests : The number of resources requested by a container. If a container exceeds its resource requests, it may be pinned back to its request count.
-
Quota : The upper limit of resources that the container can use. When a container tries to exceed its quota, if Kubernetes decides that another container needs the resource, the current container will be terminated. It generally makes sense to keep the sum of the resource limits of all containers equal to the entire resource capacity of your cluster (but in practice for incompressible resources such as memory, this is a bit harder to do).
When the container's request count is ignored, it defaults to the limit. If the limit is not set, then it defaults to 0 (no limit). As you can see, requests are soft limits on resources, while quotas are hard limits on how much resources a container can use. So in practice it makes sense to make container requests part of the quota.
Resource Scheduling
When a container is ready to start, the Kubernetes scheduler chooses an instance to run for it. The scheduler ensures that for each resource type, the sum of resource requests does not exceed the entire resource capacity on that node. In other words, over-provisioning of a resource is not allowed, but there is evidence that it may be provided in the future. If an instance's capacity check fails, the scheduler will not place the container on that instance.
For example, look at the image below:
The simplest example shown above, container A and container B have the same CPU request, and the CPU quota is 100m and 150m respectively. The space between each container's request and the quota is the space where the Kubernetes resource distribution algorithm lives and works to ensure that each container gets the resources it needs. In this example, container B requests more resources, and Kubernetes suppresses container A's 10m resources, so container B can use these resources. This is a very simple case and assumes that no other CPUs are available. The algorithms that live in this resource space are a bit more complicated than explained here.
Supported Resources
There are currently two resource support limits.
Other resources waiting to be implemented are storage time, storage space, storage operations, network bandwidth, and network operations.
One thing to note here is that CPUs are always an absolute amount, not a relative amount (like 40% of CPUs), like 0.5 CPUs. The unit of CPU resource is millicores, which is 1/1000 of a core. On supported cloud providers, a core is a vCPU.
Set resource limits
There are two excellent reasons why you should set resource requests and resource quotas per container.
You should set up resource requests so that Kubernetes can better schedule containers across instances to use as much potential capacity as possible. You should set resource limits so that when there is a rogue container, it won't eat up all the resources on the instance, affecting other applications running on that instance.
This is why you should always set resource requests and resource quotas.
Container resource quota
Unfortunately, Kubernetes does not yet implement dynamic resource management, which is why we had to set resource limits for our containers. I can imagine that at some point in the future Kubernetes will start to implement a less manual way to manage resources, but that's all we have right now.
Often, when you try to deploy a new application, you have no way of knowing exactly how many resources it will use. At this point, try a higher estimate, as you can always dial back to a lower limit if necessary.
Below is an example of setting resource quotas for containers within a pod. It sets a pod limit of 1000m and 256MiB of memory. Its pod request is 500m of CPU and 128MiB of memory. A pod's requests and quotas are always equal to the sum of the requests and quotas of all the containers it contains.
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: db
image: mysql
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
- name: wp
image: wordpress
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
You can save the file in YAML format and set up this pod.
kubectl apply -f pod.yaml --namespace=development
http://m.sanwen8.cn/p/6f0EaqR.html
Resource quotas for namespaces
You can also set resource limits in the namespace if you wish. This is useful for example when you have a dev and prod namespace and developers are testing their containers on the dev namespace without any resource quotas. Setting resource limits on the development namespace will help you ensure that if a developer accidentally uses too many resources in the development namespace, it will not affect your application in the production namespace.
apiVersion: v1
kind: ResourceQuota
metadata:
name: quota
spec:
hard:
cpu: "20"
memory: 1Gi
pods: "10"
replicationcontrollers: "20"
resourcequotas: "1"
services: "5"
You can save this YAML and apply resource quotas to the namespace.
kubectl create -f resource-quota.yaml --namespace=development
As you may have noticed, you can also set quotas on Kubernetes objects, such as services and replica controllers. All resources and objects under the namespace you can restrict are listed here. A more advanced introduction to namespace quotas can be found here.
References
（1）John Wilkes - https://www.wired.com/2013/03/ ... esos/