不知你是否已清楚，Kubernetes 是支持 Docker 和 rkt（当前是这两种）的容器调度系统。除了下面这些优美的特性，比如简易部署，配置管理，服务发现，等等，它还允许我们以一种更高效的方式来管理计算资源。本文将阐述如下问题，Kubernetes 资源模型如何工作，为什么你应该总是限制容器资源，以及如何才能正确做到。
资源管理的必要性
Kubernetes 出现之前，运行容器的普遍方式是，把应用容器丢到一个实例上，并且满怀希望地建立一个监控系统，当容器退出时自动重启。这个模型的问题是，你在该实例上的应用，可能只使用了 10% 的可用 CPU。你完全浪费了 90% 的可用 CPU。而 Kubernetes 会把那些互不相连的实例整合成一个计算资源池，多个应用可以被调度到一个物理实例上。它就像“取一大堆木块（容器或任务）——各种形状和大小的木块——并找到一种方法把所有这些木块压缩到木桶里（服务器）”（1）。如果你可以非常仔细得安排这些块（任务），那么你将使用更少的桶（服务器）。
然而，当许多容器运行在同一个实例上时，就会出现资源耗尽的新风险。如果你的容器突然尝试使用 100% 的 CPU，没有什么能阻止它耗尽其它所有容器的 CPU。这里就是 Kubernetes 资源模型起作用的地方了。既然我已用财务激励和资源耗尽风险来引你上钩，那就允许我解释一下资源模型是如何工作的。
资源模型
Kubernetes 中资源到底是什么？
资源指的是可以被 pod 或容器“请求”,“分配”,“或消费”的那些东西。例如，CPU，内存，网络带宽。
它们可以是可压缩的（容易节流）或不可压缩的（不容易节流）。内存是不可压缩的，而 CPU 和网络是可压缩的，因为它们很容易被节流。
这些资源可以被分成两种不同的情形：期望情形（规格）和当前情形（状态）。资源需求和资源容量可被认为是规格（期望情形），资源使用可被认为是状态（当前情形）。Kubernetes 调度器可以利用这两种情形来推断节点容量，资源需求等。
我们可以用术语“限额”和“请求”来描述资源的规格。
当容器的请求数忽略的情况下，它默认等于限额。如果限额没设置，那么它默认是0（无限额）。正如你看到的，请求是对资源的软性限制，而限额是对容器能使用多少资源的硬性限制。因此实际中把容器的请求设成限额的一部分才是有意义的。
资源调度
当一个容器准备启动的时候，Kubernetes 调度器会选择一个实例来为它运行。调度器确保对每种资源类型，资源请求的和不会超出该节点上整个资源容量。换句话说，资源的超额提供是不允许的，但是有证据显示它可能会在将来提供。如果一个实例的容量校验失败，那么调度器不会把容器放到这个实例上去了。
例如，请看下图
如上所示最简单的例子，容器 A 和容器 B 有相同的 CPU 请求，CPU 限额分别是 100m 和 150m。每个容器的请求和限额之间的空间，即 Kubernetes 资源分发算法生存和工作的空间，以确保每个容器能获得它所需的资源。这个例子中，容器 B 请求更多的资源，Kubernetes 压制了容器 A 10m 的资源，因此容器 B 可以使用这些资源。这是非常简单的情况，并且假定没有其它的 CPU 可用。这个资源空间中生存的算法要比这里解释的更复杂一点。
支持的资源
当前有两种资源支持限额。
其它等待实现的资源有存储时间，存储空间，存储操作，网络带宽，网络操作。
此处要注意的一个事是，CPU 总是一个绝对数量，而不是相对数量（比如 40% 的 CPU），比如 0.5 个 CPU。CPU 资源的单位是 millicores，即一个核的 1/1000。在支持的云提供商上，一个核即一个 vCPU。
设置资源限额
有两个极好的理由说明你应该为每个容器设置资源请求和资源限额。
你应该设置资源请求，使 Kubernetes 能更好得在不同实例间调度容器，以使用尽可能多的潜在容量。你应该设置资源限额，以免当有一个流氓容器的时候，它不会吃光实例上的所有资源，影响该实例上运行的其它应用。
这就是为什么你应该总是设置资源请求和资源限额。
容器资源限额
不幸的是，Kubernetes 还没实现动态资源管理，这也是为什么我们不得不为我们的容器设置资源限额。我能想象未来某一时刻 Kubernetes 将开始实现以更少手工的方式来管理资源，但是这就是我们当前所拥有的全部。
通常情况下，当你尝试部署一个新应用的时候，你无法确切知道它将使用多少资源。此时，尝试一个更高的估算，因为如果有必要，你总是可以回拨到一个更低的限额。
下面是为 pod 内的容器设置资源限额的一个例子。它设置了 pod 限额为 1000m，及 256MiB 的内存。它的 pod 请求为 500m 的 CPU 及 128MiB 的内存。pod 的请求及限额总是等于它所包含的所有容器的请求及限额之和。
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: db
image: mysql
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
- name: wp
image: wordpress
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
你可以以 YAML 格式保存文件并设置这个 pod。
kubectl apply -f pod.yaml --namespace=development
命名空间的资源限额
如果你愿意你也可以在命名空间里设置资源限额。例如当你有一个开发和产品命名空间，开发人员正在不带任何资源限额的开发命名空间上测试他们的容器，此时就会有用处。在开发命名空间上设置资源限额将有助你确保，当一个开发人员意外得使用了太多开发命名空间下的资源，不会影响你在生产命名空间下的应用。
apiVersion: v1
kind: ResourceQuota
metadata:
name: quota
spec:
hard:
cpu: "20"
memory: 1Gi
pods: "10"
replicationcontrollers: "20"
resourcequotas: "1"
services: "5"
你可以保存这个 YAML 并把资源配额应用到命名空间下。
kubectl create -f resource-quota.yaml --namespace=development
可能你已注意到，你也可以在 Kubernetes 对象上设置限额，如服务和副本控制器。此处（http://kubernetes.io/docs/admin/resourcequota/）列举了命名空间下你可以限制的所有资源和对象。这里（http://kubernetes.io/docs/admin/resourcequota/walkthrough/）可以找到更高级的关于命名空间配额的介绍。
本文为翻译文章，点击阅读原文链接即可查看原文。
