为Kubernetes中的pod分配或限制资源？

时间：2016-02-25 06:51:26

标签： docker kubernetes cgroups

Pod的资源限制已设置为：

resource
  limit
    cpu: 500m
    memory: 5Gi

节点上还剩10G个记忆。

我在短时间内成功创建了5个广告连播，节点可能仍然留有一些内存，例如： 8G。

随着时间的推移，内存使用量不断增加，并达到限制（5G x 5 = 25G > 10G），然后该节点将无法响应。

为了确保可用性，有没有办法在节点上设置资源限制？

更新

核心问题是pod内存使用量并不总是等于限制，特别是在它刚刚启动时。因此，可以尽快创建无限的pod，然后使所有节点满载。这不好。可能有一些东西需要分配资源而不是设置限制。

更新2

我再次测试了限制和资源：

resources:
  limits:
    cpu: 500m
    memory: 5Gi
  requests:
    cpu: 500m
    memory: 5Gi

总内存为15G，剩下14G，但3个pod已安排并成功运行：

> free -mh
              total        used        free      shared  buff/cache   available
Mem:            15G        1.1G        8.3G        3.4M        6.2G         14G
Swap:            0B          0B          0B

> docker stats

CONTAINER           CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O
44eaa3e2d68c        0.63%               1.939 GB / 5.369 GB   36.11%              0 B / 0 B           47.84 MB / 0 B
87099000037c        0.58%               2.187 GB / 5.369 GB   40.74%              0 B / 0 B           48.01 MB / 0 B
d5954ab37642        0.58%               1.936 GB / 5.369 GB   36.07%              0 B / 0 B           47.81 MB / 0 B

似乎该节点很快将被粉碎XD

更新3

现在我更改资源限制，请求5G并限制8G：

resources:
  limits:
    cpu: 500m
    memory: 5Gi
  requests:
    cpu: 500m
    memory: 8Gi

结果如下： enter image description here

根据k8s source code about the resource check：

enter image description here

总内存仅为15G，所有播客都需要24G，因此所有播放都可能会被杀死。（我的单个容器通常会花费16G以上，如果不是有限。）

这意味着您最好将requests 完全等于与limits保持一致，以避免播放pod或节点粉碎。好像没有指定requests值，它将是set to the limit as default，那么requests究竟用于什么？我认为只有limits完全足够，或IMO，与K8声称的相反，我更喜欢设置资源请求大于限制，以确保可用性节点

更新4

Kubernetes 1.1 schedule the pods mem requests通过以下公式：

(capacity - memoryRequested) >= podRequest.memory

似乎kubernetes并不关心内存使用情况Vishnu Kannan所说。因此，如果mem使用其他应用程序很多，那么该节点将被粉碎。

幸运的是，从提交e64fe822开始，公式已更改为：

(allocatable - memoryRequested) >= podRequest.memory

等待k8s v1.2！

2 个答案:

答案 0 :(得分：16)

Kubernetes资源规范有两个字段request和limit。

limits限制容器可以使用的资源量。对于内存，如果容器超出其限制，它将被OOM杀死。对于CPU，其使用可能会受到限制。

requests的不同之处在于它们确保放置pod的节点至少具有可用的容量。如果要确保在没有节点资源耗尽的情况下您的pod可以增长到特定大小，请指定该大小的请求。这将限制您可以安排多少个pod - 10G节点只能容纳2个具有5G内存请求的pod。

答案 1 :(得分：7)

Kubernetes支持服务质量。如果您的Pod已设置limits，则它们属于Guaranteed类，并且由于系统内存压力而导致它们被杀的可能性非常低。如果您在节点上运行的docker守护程序或其他守护程序会占用大量内存，那么可能会有保证的Pod被杀死。

Kube调度程序确实考虑了调度时分配的内存容量和内存。例如，您不能安排两个以上的pod，每个pod在10GB节点上请求5 GB。

目前，为了安排，Kubernetes不会消耗内存使用量。

相关问题
最新问题