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

Question

Pod的资源限制已设置为:

resource
  limit
    cpu: 500m
    memory: 5Gi

并且10G在节点上留下了mem.

我5成功地在短时间内创建了pod,节点可能还剩下一些内存,例如8G.

随着时间的推移,mem的使用越来越多,并且达到limit(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

结果是:

根据关于资源检查的k8s源代码:

总内存是唯一的15G,并且所有的pod都需要24G,因此所有的pod都可能被杀死.(我的单个容器的成本16G通常比通常不受限制.)

这意味着你最好保持requests 完全等于,limits以避免pod死或节点粉碎.好像requests未指定该值,它将被设置limit为默认值,那么究竟requests用于什么？我认为只有limits完全足够,或IMO,与K8声称的相反,我更喜欢将资源请求设置为大于限制,以确保节点的可用性.

更新4

Kubernetes 1.1通过以下公式安排pods mem请求:

(capacity - memoryRequested) >= podRequest.memory

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

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

(allocatable - memoryRequested) >= podRequest.memory

等待k8s v1.2!

Answer 1

Kubernetes资源规范有两个领域,request和limit.

limits对容器可以使用多少资源设置上限.对于内存,如果容器超出其限制,它将被OOM杀死.对于CPU,其使用可能会受到限制.

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

Answer 2

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

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

到目前为止,Kubernetes不会使用内存使用来进行调度.