在 Kubernetes 中为 pods 分配或限制资源？
Allocate or Limit resource for pods in Kubernetes?
Pod的资源限制设置为：
resource
limit
cpu: 500m
memory: 5Gi
节点上还有 10G 内存。
我在短时间内成功创建了 5 pods，节点可能还有一些内存，例如8G.
随着时间的推移，mem使用量越来越大，达到极限（5G x 5 = 25G > 10G），节点将失去响应。
为了保证可用性，有没有办法在节点上设置资源限制？
更新
核心问题是pod的内存占用并不总是等于limit，尤其是刚启动的时候。所以可以尽快创建无限制的pods，然后让所有节点满载。这不好。可能有一些分配资源而不是设置限制。
更新 2
我再次测试了限制和资源：
resources:
limits:
cpu: 500m
memory: 5Gi
requests:
cpu: 500m
memory: 5Gi
总mem为15G，剩余14G，但调度了3个pods，运行成功：
> 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，而所有pods需要24G，所以可能会把pods全部杀掉。 （如果没有限制，我的单个容器通常会花费 16G 以上。）
这意味着你最好保持 requests 正好等于 到 limits 以避免 pod 被杀死或节点崩溃。好像没有指定requests值，就会是set to the limit as default，那么requests到底是干什么用的呢？我觉得只有limits就完全够了，或者IMO，与K8s声称的相反，我更喜欢设置资源请求大于限制，以确保节点的可用性。
更新 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！
Kubernetes 资源规范有两个字段，request 和 limit。
limits 对容器可以使用的资源量设置上限。对于内存，如果容器超出其限制，它将被 OOM 杀死。对于 CPU，它的使用可能会受到限制。
requests 的不同之处在于它们确保放置 pod 的节点至少有那么多的可用容量。如果您想确保您的 pods 能够在节点 运行 资源不足的情况下增长到特定大小，请指定该大小的请求。不过，这将限制您可以调度的数量 pods——一个 10G 的节点将只能满足 2 个 pods 的 5G 内存请求。
Kubernetes 支持服务质量。如果您的 Pods 设置了 limits，则它们属于 Guaranteed class，并且它们因系统内存压力而被杀死的可能性极低。如果 docker 守护进程或节点上 运行 的其他守护进程消耗大量内存，则 Guaranteed Pods 有可能被杀死。
Kube 调度程序确实会在调度时考虑内存容量和分配的内存。例如，您不能安排超过两个 pods，每个都在 10GB 节点上请求 5GB。
到目前为止，Kubernetes 还没有为调度目的消耗内存。
Pod的资源限制设置为：
resource
limit
cpu: 500m
memory: 5Gi
节点上还有 10G 内存。
我在短时间内成功创建了 5 pods，节点可能还有一些内存，例如8G.
随着时间的推移，mem使用量越来越大，达到极限（5G x 5 = 25G > 10G），节点将失去响应。
为了保证可用性，有没有办法在节点上设置资源限制？
更新
核心问题是pod的内存占用并不总是等于limit，尤其是刚启动的时候。所以可以尽快创建无限制的pods，然后让所有节点满载。这不好。可能有一些分配资源而不是设置限制。
更新 2
我再次测试了限制和资源：
resources:
limits:
cpu: 500m
memory: 5Gi
requests:
cpu: 500m
memory: 5Gi
总mem为15G，剩余14G，但调度了3个pods，运行成功：
> 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，而所有pods需要24G，所以可能会把pods全部杀掉。 （如果没有限制，我的单个容器通常会花费 16G 以上。）
这意味着你最好保持 requests 正好等于 到 limits 以避免 pod 被杀死或节点崩溃。好像没有指定requests值，就会是set to the limit as default，那么requests到底是干什么用的呢？我觉得只有limits就完全够了，或者IMO，与K8s声称的相反，我更喜欢设置资源请求大于限制，以确保节点的可用性。
更新 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！
Kubernetes 资源规范有两个字段，request 和 limit。
limits 对容器可以使用的资源量设置上限。对于内存，如果容器超出其限制，它将被 OOM 杀死。对于 CPU，它的使用可能会受到限制。
requests 的不同之处在于它们确保放置 pod 的节点至少有那么多的可用容量。如果您想确保您的 pods 能够在节点 运行 资源不足的情况下增长到特定大小，请指定该大小的请求。不过，这将限制您可以调度的数量 pods——一个 10G 的节点将只能满足 2 个 pods 的 5G 内存请求。
Kubernetes 支持服务质量。如果您的 Pods 设置了 limits，则它们属于 Guaranteed class，并且它们因系统内存压力而被杀死的可能性极低。如果 docker 守护进程或节点上 运行 的其他守护进程消耗大量内存，则 Guaranteed Pods 有可能被杀死。
Kube 调度程序确实会在调度时考虑内存容量和分配的内存。例如，您不能安排超过两个 pods，每个都在 10GB 节点上请求 5GB。
到目前为止，Kubernetes 还没有为调度目的消耗内存。