资源配额通过控制应用程序可以消耗多少CPU
或内存来防止资源争用和抢占。
背景
当有人提到需要管理Kubernetes
计算资源(尤其是CPU
和内存)时,就会想到控制
这个词。之所以提出控制资源使用,大都是在Kubernetes
平台部署了一段时间、开发人员正在广泛使用该集群、经常因为资源争用出现问题。
当部署Kubernetes
应用时而未考虑集群的未来增长,那么就会出现资源问题。还可能与团队的部署和管理Kubernetes
集群的经验水平有关。
没有进行资源控制,一个流氓
应用程序或开发人员就可能会破坏业务。当几个开发人员共享具有固定数量节点的群集时,会无意间发生这种情况。这些资源限制可能会引起开发人员之间对可用资源的分歧,互相指责、抢占。对于集群管理员和开发人员而言,这些问题都是非常糟糕的情况。
有几种方法可以限制应用程序如何在Kubernetes
环境中利用计算资源。在大多数情况下,资源配额和限制范围就足够了。请注意,在Kubernetes
中,存储管理通过使用Persistent Volume
插件方法,其中定义了用于解决和控制不同存储需求的属性。
Kubernetes
资源配额是一种控制使用计算资源的方式。本文将向您展示如何使用此功能来管理开发人员的行为并控制应用程序资源的消耗。
什么是资源配额?
简而言之,资源配额提供了限制每个命名空间资源消耗的约束。它们只能应用于命名空间级别,这意味着它们可以应用于计算资源并限制命名空间内的对象数量。
Kubernetes
资源配额由ResourceQuota
对象定义。当应用于命名空间时,它可能会限制计算资源(例如CPU
和内存)以及以下对象的创建:
- Pods
- Services
- Secrets
- Persistent Volume Claims (PVCs)
- ConfigMaps
Kubernetes
支持两种类型的CPU
和内存配额来管理计算资源。如LimitRange
文档所述,主要时通过限制和请求两种方式来控制的。
简而言之,请求
为容器定义了保证的CPU
或内存资源,而限制
是容器可以使用的内存或CPU
阈值,具体取决于其它容器资源使用情况。
该图说明了Kubernetes
资源配额中请求和限制之间的差异。
下文演示了如何使用资源配额来创建约束,这些约束根据已定义的阈值将应用程序限制为只能使用特定资源。它还显示了通过实现资源配额可以有效限制Kubernetes Pod
资源占用。
先决条件
开始之前,请确保已在本地计算机中部署了Kubernetes
。如下是我的配置:
- Minikube v1.14.2
- linux 7
- 可联网
设置资源配额
本示例创建了CPU
配额,但是内存配额或两者的组合过程相似。
在实际的生产场景中,为了避免抢占,CPU
资源通常是需要优先管理的资源。每当服务器(计算)上运行多个应用程序时,都是如此。
首先创建一个新的名称空间,您将设置CPU
配额:
$ kubectl create namespace quota-test
namespace/quota-test created
创建一个名为的文件cpu-quota.yaml
,并将以下配额(演示创建)放入其中:
apiVersion: v1
kind: ResourceQuota
metadata:
name: test-cpu-quota
spec:
hard:
requests.cpu: "100m"
limits.cpu: "200m"
通过以下方式将配额应用于您的Kubernetes
集群:
$ kubectl apply -f cpu-qouta.yaml
resourcequota/test-cpu-quota created
验证是否使用以下kubectl describe
命令创建的配额:
$ kubectl describe resourcequota/test-cpu-quota --namespace quota-test
Name: test-cpu-quota
Namespace: quota-test
Resource Used Hard
-------- ---- ----
limits.cpu 0 200m
requests.cpu 0 100m
注意该Used resources Used
列,当部署Pod
时,此值将更改。
现在您已经定义了配额,请对其进行测试。对于此示例,在同一名称空间中部署三个不同的Pod
,以查看是否可以根据定义的限制来控制资源的使用。这三个Pod
是:
PodA
:该Pod
,第一个实例化,将使用50%
的可用CPU
。
PodB
:此Pod
将使用可用CPU
的另外50%
;它将是第二个实例化的pod
。
PodC
:定义的配额应防止部署第三个Pod
。现在您已经了解了场景,请开始部署Pod
。
部署 Pod
PodA
代码语言:javascript复制$ kubectl create -n quota-test -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
name: poda
spec:
containers:
- name: quota-test
image: busybox
imagePullPolicy: IfNotPresent
command: ['sh', '-c', 'echo Pod is Running ; sleep 5000']
resources:
requests:
cpu: "50m"
limits:
cpu: "100m"
restartPolicy: Never
EOF
通过再次查看配额并记录Used CPU
值限制和请求来验证CPU
使用情况:
$ kubectl describe resourcequota/test-cpu-quota --namespace quota-test
Name: test-cpu-quota
Namespace: quota-test
Resource Used Hard
-------- ---- ----
limits.cpu 100m 200m
requests.cpu 50m 100m
PodB:
代码语言:javascript复制$ kubectl create -n quota-test -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
name: podb
spec:
containers:
- name: quota-test
image: busybox
imagePullPolicy: IfNotPresent
command: ['sh', '-c', 'echo Pod is Running ; sleep 5000']
resources:
requests:
cpu: "50m"
limits:
cpu: "100m"
restartPolicy: Never
EOF
再次检查CPU
资源使用情况。如预期的那样,可以调度PodB
,因为配额允许:
$ kubectl describe resourcequota/test-cpu-quota --namespace quota-test
Name: test-cpu-quota
Namespace: quota-test
Resource Used Hard
-------- ---- ----
limits.cpu 200m 200m
requests.cpu 100m 100m
PodC:
现在,即使您知道PodA
和PodB
最大化了您定义的CPU
配额阈值,尝试实例化第三个Pod
:
$ kubectl create -n quota-test -f- <<EOF
apiVersion: v1
kind: Pod
metadata:
name: podc
spec:
containers:
- name: quota-test
image: busybox
imagePullPolicy: IfNotPresent
command: ['sh', '-c', 'echo Pod is Running ; sleep 5000']
resources:
requests:
cpu: "5m"
limits:
cpu: "10m"
restartPolicy: Never
EOF
如预期的那样,第三个Pod
将不会实例化,因为已经定义的配额会阻止创建Pod
:
Error from server (Forbidden): error when creating "STDIN": pods "podc" is forbidden: exceeded quota: test-cpu-quota, requested: limits.cpu=10m,requests.cpu=5m, used: limits.cpu=200m,requests.cpu=100m, limited: limits.cpu=200m,requests.cpu=100m
如该示例所示,正确定义的资源配额是Kubernetes
管理员可以用来管理开发人员行为的强大工具。
清理
删除您创建的名称空间(在本例中为quota-test
):
$ kubectl delete -n quota-test
规划配额
有很多方法可以控制用户如何部署应用程序,从而避免在Kubernetes
集群中资源抢占。合理地实施配额、限制资源使用范围和其它本机服务,这有助于集群的稳定。
在计算资源上实现资源配额是您需要仔细考虑的重要设计决策,尤其是在部署Kubernetes
以运行关键业务应用程序时。
在定义配额时,在计划中包括开发人员应用资源消耗很重要。由于他们对自己的应用资源占用情况最清楚,他们是您估计所需资源的最佳选择。