Pod的资源限制已设置为：

resource
  limit
    cpu: 500m
    memory: 5Gi

并且节点上还剩下10G内存.

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

随着时间的推移,mem的使用越来越多,并且达到极限(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 source code about the resource check：

总内存只有15G,而且所有的pod都需要24G,所以所有的pod都可能会被杀死.(我的单个容器通常如果没有限制,将花费超过16G.)

这意味着你最好保持请求完全等于限制,以避免pod dead或node crush.好像没有指定请求值,它将是set to the limit as default,那么究竟是什么请求用于？我认为只有限制是完全足够的,或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！