Kubernetes 1.2 新功能介绍：Limit Range和Resource Quota

什么是资源的限制范围和使用配额

Docker或者说以Docker发轫的新一代云计算，很大程度上的目标是实现更轻量、更便捷、更高效、更低成本的资源共享和隔离。使用kubernetes，一方面是实现DevOps，实现运维的自动化，另一方面是提高资源的利用率，实现软件定义的计算。对kubernetes集群中的计算资源超卖，来提高资源的使用率，但是这样也会带来另一个问题，资源使用者会无节制的申请甚至浪费资源，这与我们的初衷相悖，所以我们需要为每个资源的申请者设立资源使用上线和配额，kubernetes1.2版本中发布这一新功能：Limit Range和Resource Quota

激活资源配额特性

在kubernetes API Server的配置–admission-control中开启ResourceQuota即可：

申请资源配额和限制

我们将分几个步骤来演示如何为一个Kubernetes Namespace创建资源配额和限制

步骤1：创建一个namespace

使用kubectl命令创建一个namespace

创建成功后，可以通过kubectl get命令来查看namespace的信息：

步骤2：为一个namespace申请配额

在默认的情况下，一个运行中的Pod可以无限制的使用Node上的CPU和内存，这意味着任意一个Pod都可以无节制的使用宿主Node上的计算资源，Pod可能给Node上的CPU/Memory资源耗尽。

用户可能会想去限制一个Namespace在计算集群中的使用，来控制namespace下的Pod进而管理计算集群的资源利用。为了达到这个目的，用户需要为每个namespace申请配额。Quota让每个用户设置计算资源（CPU/Memory）总量和API资源（Pod，Services， etc.）上的硬限制(hard limits)。以资源的角度来看，kubernetes将同一namespace下的所有的资源请求总量与资源配额比较，而不是所有该namespace下的所有资源上限的总量与资源配额进行比较。

编写资源配额yaml文件：

创建资源配额：

查看配额的细节：

步骤3：申请默认的资源请求和限制（{pod.spec.template.resourcelimits cpu/memory request/limits）

一般说来，pod的创建者很少为他们的pod设置资源请求量和使用上限。

由于我们为我们的工程（namespace)申请了资源使用配额，所以我们的用户在创建一个pod时可以使用无边界（不受限制的）的CUP和内存（当然，在配额总量的限制下），为演示这种情形，我们发布一个nginx的Deployment为例：

刚刚我们创建了一个带有潜在（默认）资源需求的’nginx’ Deployment，一个Replica Set（Replication Set的下一代），它可以删除/创建Pod。现在看看我们刚刚创建的Pods：

为什么没有Pod？？？为什么？让我们来描述（kubectl describe）一下nginx Deployment的ReplicaSet中到底发生了什么：

Kubernetes的API Server拒绝了没有指定CUP/Memory需求和上线的ReplicaSet的创建请求。

我们将为每个Pod创建一个默认使用的CPU/Memory请求量限制,下面是LimitRange文件描述：

使用kubectl命令创建并查看：

现在我们再查看刚刚’nginx’ Deployment的Pod情况，它已经创建成功了

1.2版本还能查看我们的配额使用率：

资源配额的意义

在实际的生产环境中，不同事业部或部门，甚至是每个项目可以申请一个资源配额，这个配额就是部门的年度硬件的预算，使用者可以可以根据资源使用率和下一年的计划来调整下一年的预算。对于那些基于容器的云计算厂商，可以根据用户的实际使用情况收费，丰富盈利模式，提高资源的利用率，节能环保，另外一种“共享经济模式”。

推荐阅读：

Kubernetes 1.2 新功能介绍：ConfigMap

Kubernetes 1.2 新功能介绍：自动扩容算法