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（实际上就是defaultLimit，不懂为什么Kubernetes不用这个名称😵）：

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