Kubernetes：理解资源的概念

原文：Kubernetes - Understanding Resources

作者：Ben Visser

翻译：池剑锋

来源：DockOne.io

原文链接：http://www.noqcks.io/note/kubernetes-resources-limits/index.html

译文链接：http://www.dockone.io/article/1977

 

不知你是否已清楚，Kubernetes 是支持 Docker 和 rkt（当前是这两种）的容器调度系统。除了下面这些优美的特性，比如简易部署，配置管理，服务发现，等等，它还允许我们以一种更高效的方式来管理计算资源。本文将阐述如下问题，Kubernetes 资源模型如何工作，为什么你应该总是限制容器资源，以及如何才能正确做到。

 

资源管理的必要性

Kubernetes 出现之前，运行容器的普遍方式是，把应用容器丢到一个实例上，并且满怀希望地建立一个监控系统，当容器退出时自动重启。这个模型的问题是，你在该实例上的应用，可能只使用了 10% 的可用 CPU。你完全浪费了 90% 的可用 CPU。而 Kubernetes 会把那些互不相连的实例整合成一个计算资源池，多个应用可以被调度到一个物理实例上。它就像“取一大堆木块（容器或任务）——各种形状和大小的木块——并找到一种方法把所有这些木块压缩到木桶里（服务器）”（1）。如果你可以非常仔细得安排这些块（任务），那么你将使用更少的桶（服务器）。

然而，当许多容器运行在同一个实例上时，就会出现资源耗尽的新风险。如果你的容器突然尝试使用 100% 的 CPU，没有什么能阻止它耗尽其它所有容器的 CPU。这里就是 Kubernetes 资源模型起作用的地方了。既然我已用财务激励和资源耗尽风险来引你上钩，那就允许我解释一下资源模型是如何工作的。

 

资源模型

Kubernetes 中资源到底是什么？资源指的是可以被 pod 或容器“请求”,“分配”,“或消费”的那些东西。例如，CPU，内存，网络带宽。

它们可以是可压缩的（容易节流）或不可压缩的（不容易节流）。内存是不可压缩的，而 CPU 和网络是可压缩的，因为它们很容易被节流。

这些资源可以被分成两种不同的情形：期望情形（规格）和当前情形（状态）。资源需求和资源容量可被认为是规格（期望情形），资源使用可被认为是状态（当前情形）。Kubernetes 调度器可以利用这两种情形来推断节点容量，资源需求等。

我们可以用术语“限额”和“请求”来描述资源的规格。

• 请求：一个容器请求的资源数量。如果一个容器超过了它的资源请求，它可能会被压制回到它的请求数。

• 限额：容器能使用的资源上限。当容器尝试超过它的限额时，如果 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

 

 

http://m.sanwen8.cn/p/6f0EaqR.html

 

命名空间的资源限额

如果你愿意你也可以在命名空间里设置资源限额。例如当你有一个开发和产品命名空间，开发人员正在不带任何资源限额的开发命名空间上测试他们的容器，此时就会有用处。在开发命名空间上设置资源限额将有助你确保，当一个开发人员意外得使用了太多开发命名空间下的资源，不会影响你在生产命名空间下的应用。

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 对象上设置限额，如服务和副本控制器。此处列举了命名空间下你可以限制的所有资源和对象。这里可以找到更高级的关于命名空间配额的介绍。

 

 

参考资料

（1）John Wilkes - https://www.wired.com/2013/03/ ... esos/