这是我参与11月更文挑战的第9天，活动详情查看：2021最后一次更文挑战。
Kubernetes资源管理
我们可以通过requests和limits给Pod指定资源配置，但如果每个Pod都要指定的话略显繁琐，我们可以使用LimitRange指定一个全局的默认配置；此外通过ResourceQuota对象，我们可以定义资源配额，这个资源配额可以为每个命名空间都提供一个总体的资源使用的限制：它可以限制命名空间中某种类型的对象的总数目上限，也可以设置命名空间中Pod可以使用的计算资源的总上限。
LimitRange
在使用LimitRange之前先创建一个命名空间：
apiVersion: v1
kind: Namespace
metadata:
name: test-resource
然后定义LimitRange配置（limit-range.yml）:
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：
可以看到配置已经生效了。下面介绍下这些配置的含义：
上面配置分为Pod和Container配置，Container资源配置对应每个Docker容器的资源配置，Pod资源配置对应一个Pod中所有容器资源的总和。其中Pod和Container都可以指定min，max和maxLimitRequestRatio：
min：指定资源的下限，即最低资源配置不能低于这个值；max：指定资源的上限，即最高资源使用不能高于这个值；maxLimitRequestRatio：该值用于指定requests和limits值比例的上限。
相较于Pod，Container还可以指定defaultRequest和default：
defaultRequest：全局容器的默认requests值；default：全局容器的默认limits值。
下面我们举几个例子，看看我们创建的LimitRange是否生效。 定义一个Pod配置文件（test-default.yml）：
apiVersion: v1
kind: Pod
metadata:
name: test-default
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
创建该Pod：
可以看到我们在test-default.yml中并没有定义requests和limits配置，但是通过Pod实例的yaml可以看到它已经指定了这两个值，而这些正是上面我们在LimitRange中定义的默认值。
接着定义一个新的Pod配置（test-max.yml）:
apiVersion: v1
kind: Pod
metadata:
name: test-max
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
resources:
limits:
cpu: 3
memory: 500Mi
创建该Pod：
可以看到在创建的时候就报错了，因为上面的cpu配置即超过了LimtRange中定义的Container的cpu最高配置，也超过了Pod的cpu的最高配置。
再创建一个Pod配置（test-ratio.yml）：
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：
可以看到也报错了，因为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之前我们也先创建一个命名空间：
apiVersion: v1
kind: Namespace
metadata:
name: quota-ns
创建个简单的ResourceQuota配置（test-quota.yml）：
apiVersion: v1
kind: ResourceQuota
metadata:
name: test-quota
spec:
hard:
pods: "4"
创建该ResourceQuota：
接着定义一个RC配置（nginx-rc.yml）：
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:
可以看到，已经有3个Pod实例了，如果将Pod数量扩大到5，看看会怎样：
最终也只会有4个Pod实例，因为我们在上面ResourceQuota中指定的最大Pod数量为4。
