为Kubernetes中的窗格分配或限制资源？
Pod的资源限制设置为：
resource limit cpu: 500m memory: 5Gi 在节点上剩下10G mem。
我已经在短时间内成功创build了5豆荚，并且该节点可能还有一些mem，例如8G 。
内存使用量随着时间的推移而增长，达到极限（ 5G x 5 = 25G > 10G ），则节点将失去响应。
为了保证可用性，有没有办法在节点上设置资源限制？
更新
核心问题是pod内存的使用并不总是等于极限，特别是在刚启动的时候。 所以可以尽快创build无限的豆荚，然后使所有的节点满载。 这不好。 有可能是分配资源，而不是设置限制。
更新2
我再次testing了限制和资源：
resources: limits: cpu: 500m memory: 5Gi requests: cpu: 500m memory: 5Gi
总容量为15G，剩下14G，但是3个豆荚计划运行成功：
> 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 ，所有的豆荚需要24G ，所有的豆荚可能会被杀死（如果没有限制的话，我的单个容器的价格通常会超过16G ）。
这意味着你最好把requests保持在等于 limits ，以避免荚杀或节点粉碎。 就好像没有指定requests值一样，它将被设置为默认的limit ，那么究竟是什么requests使用？ 我认为只有limits是完全足够的，或IMO，相反，K8s声称，我宁愿设置资源请求大于限制 ，以确保节点的可用性。
更新4
Kubernetes 1.1通过公式计划pod mem请求 ：
(capacity - memoryRequested) >= podRequest.memory
看起来kubernetes不关心内存使用Vishnu Kannan说。 所以如果其他应用程序使用mem，那么节点将会被破坏。
幸运的是，从提交e64fe822 ，公式已被更改为：
(allocatable - memoryRequested) >= podRequest.memory
等待k8s v1.2！
Kubernetes资源规范有两个字段， request和limit 。
limits了容器可以使用多less资源的上限。 对于记忆来说，如果一个容器超出限制，就会被OOM杀死。 对于CPU，其使用可能会受到限制。
requests是不同的，因为它们确保吊舱所在的节点至less具有可用的容量。 如果你想确保你的豆荚能够增长到一个特定的大小，没有节点资源不足，指定一个这样的大小的请求。 这将限制你可以调度多less个豆荚，但是一个10G节点只能够满足5个内存请求的2个豆荚。
Kubernetes支持服务质量。 如果您的豆荚已经设置了limits ，它们属于Guaranteed类别，并且由于系统内存压力而死亡的可能性非常低。 如果在节点上运行的docker守护进程或其他守护进程消耗大量内存，那么有保证Pod可能会被终止。
Kube调度程序确实考虑了调度时分配的内存容量和内存。 例如，您不能在10GB节点上安排每个请求5 GB的两个以上的吊舱。
为了进行调度，目前Kubernetes并没有使用内存使用。