Kubernetes资源管理

通过前面的学习我们知道,我们可以通过requests和limits给Pod指定资源配置,但如果每个Pod都要指定的话略显繁琐,我们可以使用LimitRange指定一个全局的默认配置;此外通过ResourceQuota对象,我们可以定义资源配额,这个资源配额可以为每个命名空间都提供一个总体的资源使用的限制:它可以限制命名空间中某种类型的对象的总数目上限,也可以设置命名空间中Pod可以使用的计算资源的总上限。

LimitRange

在使用LimitRange之前先创建一个命名空间:

1
2
3
4
apiVersion: v1
kind: Namespace
metadata:
name: test-resource

然后定义LimitRange配置(limit-range.yml):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
apiVersion: v1
kind: LimitRange
metadata:
name: limit-range-example
spec:
limits:
- max:
cpu: 2
memory: 2Gi
min:
cpu: 200m
memory: 6Mi
maxLimitRequestRatio:
cpu: 3
memory: 2
type: Pod
- default:
cpu: 300m
memory: 200Mi
defaultRequest:
cpu: 200m
memory: 100Mi
max:
cpu: 2
memory: 1Gi
min:
cpu: 100m
memory: 3Mi
maxLimitRequestRatio:
cpu: 5
memory: 4
type: Container

创建该LimitRange:

QQ截图20191112092850.png

可以看到配置已经生效了。下面介绍下这些配置的含义:

上面配置分为Pod和Container配置,Container资源配置对应每个Docker容器的资源配置,Pod资源配置对应一个Pod中所有容器资源的总和。其中Pod和Container都可以指定minmaxmaxLimitRequestRatio

  1. min:指定资源的下限,即最低资源配置不能低于这个值;

  2. max:指定资源的上限,即最高资源使用不能高于这个值;

  3. maxLimitRequestRatio:该值用于指定requests和limits值比例的上限。

相较于Pod,Container还可以指定defaultRequestdefault(实际上就是defaultLimit,不懂为什么Kubernetes不用这个名称😵):

  1. defaultRequest:全局容器的默认requests值;

  2. default:全局容器的默认limits值。

下面我们举几个例子,看看我们创建的LimitRange是否生效。

定义一个Pod配置文件(test-default.yml):

1
2
3
4
5
6
7
8
9
10
apiVersion: v1
kind: Pod
metadata:
name: test-default
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80

创建该Pod:

QQ截图20191112094923.png

QQ截图20191112094959.png

可以看到我们在test-default.yml中并没有定义requests和limits配置,但是通过Pod实例的yaml可以看到它已经指定了这两个值,而这些正是上面我们在LimitRange中定义的默认值。

接着定义一个新的Pod配置(test-max.yml):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
apiVersion: v1
kind: Pod
metadata:
name: test-max
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
resources:
limits:
cpu: 3
memory: 500Mi

创建该Pod:

QQ截图20191112095603.png

可以看到在创建的时候就报错了,因为上面的cpu配置即超过了LimtRange中定义的Container的cpu最高配置,也超过了Pod的cpu的最高配置。

再创建一个Pod配置(test-ratio.yml):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
apiVersion: v1
kind: Pod
metadata:
name: test-ratio
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
resources:
limits:
cpu: 2
memory: 500Mi
requests:
cpu: 300m
memory: 50Mi

创建该Pod:

QQ截图20191112100308.png

可以看到也报错了,因为requests和limits的比例不符合LimitRange的maxLimitRequestRatio配置。

LimitRange的测试先到这里吧,通过上面三个例子大体也能感受到LimitRange的作用了。

ResourceQuota

ResourceQuota用于管理资源配额,这个资源配额可以为每个命名空间都提供一个总体的资源使用的限制。资源配额主要分为以下几个类型:

计算资源配额

资源名称说明
Cpu所有非终止状态的Pod,CPU Requests的总和不能超过该值
limits.cpu所有非终止状态的Pod, CPU Limits的总和不能超过该值
limits.memory所有非终止状态的Pod,内存 Limits的总和不能超过该值
Memory所有非终止状态的Pod, 内存 Requests的总和不能超过该值
requests.cpu所有非终止状态的Pod,CPU Requests的总和不能超过该值
requests.memory所有非终止状态的Pod, 内存Requests的总和不能超过该值

存储资源配额

资源名称说明
requests.storage所有PVC,存储请求总量不能超过此值
PersistentVolumeclaims在该命名空间中能存在的持久卷的总数上限
.storageclass.storage.k8s.io/requests.storage和该存储类关联的所有PVC,存储请求总和不能超过此值
.storageclass.storage.k8s.io/persistentvolumeclaims和该存储类关联的所有PVC的总和

对象数量配额

资源名称说明
Configmaps在该命名空间中能存在的ConfigMap的总数上限

Pods

在该命名空间中能存在的非终止状态Pod的总数上限,Pod终止状态等价于Pod的

status.phase in(Failed, Succeeded) = true

Replicationcontrollers在该命名空间中能存在的RC的总数上限
Resourcequtas在该命名空间中能存在的资源配额项的总数上限
Services在该命名空间中能存在的Service的总数上限
service.loadbalancers在该命名空间中能存在的负载均衡的总数上限
services.nodeports在该命名空间中能存在的NodePort的总数上限
Secrets在该命名空间中能存在的Secret的总数上限

测试

在测试ResourceQuota之前我们也先创建一个命名空间:

1
2
3
4
apiVersion: v1
kind: Namespace
metadata:
name: quota-ns

创建个简单的ResourceQuota配置(test-quota.yml):

1
2
3
4
5
6
7
apiVersion: v1
kind: ResourceQuota
metadata:
name: test-quota
spec:
hard:
pods: "4"

创建该ResourceQuota:

QQ截图20191112104240.png

接着定义一个RC配置(nginx-rc.yml):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: v1
kind: ReplicationController
metadata:
name: nginx-rc
spec:
replicas: 3
selector:
name: nginx
template:
metadata:
labels:
name: nginx
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80

创建该RC:

QQ截图20191112104507.png

可以看到,已经有3个Pod实例了,如果将Pod数量扩大到5,看看会怎样:

QQ截图20191112104655.png

最终也只会有4个Pod实例,因为我们在上面ResourceQuota中指定的最大Pod数量为4。

《Kubernetes权威指南(第4版)》读书笔记

请作者喝瓶肥宅水🥤

0