k8s 资源管理

标签：color   有一个   col   思考   系统   问题   ber   its   情况下   

对应到
Kubernetes的Pod容器上，就是下面这4个参数：
◎　spec.container[].resources.requests.cpu；
◎　spec.container[].resources.limits.cpu；
◎　spec.container[].resources.requests.memory；
◎　spec.container[].resources.limits.memory。
其中，limits对应资源量的上限，即最多允许使用这个上限的资源
量。由于CPU资源是可压缩的，进程无论如何也不可能突破上限，因此
设置起来比较容易。对于Memory这种不可压缩资源来说，它的Limit设
置就是一个问题了，如果设置得小了，当进程在业务繁忙期试图请求超
过Limit限制的Memory时，此进程就会被Kubernetes杀掉。因此，
Memory的Request与Limit的值需要结合进程的实际需求谨慎设置。如果
不设置CPU或Memory的Limit值，会怎样呢？在这种情况下，该Pod的资
源使用量有一个弹性范围，我们不用绞尽脑汁去思考这两个Limit的合理值，但问题也来了，考虑下面的例子：

Pod A的 Memory Request被设置为1GB，Node A当时空闲的Memory为1.2GB，符
合Pod A的需求，因此Pod A被调度到Node A上。运行3天后，Pod A的访问请求大增，
内存需要增加到1.5GB，此时Node A的剩余内存只有200MB，由于Pod A新增的内存已
经超出系统资源，所以在这种情况下，Pod A就会被Kubernetes杀掉。

重点：

尽管Requests和Limits只能被设置到容器上，但是设置Pod级别的
Requests和Limits能大大提高管理Pod的便利性和灵活性，因此在
Kubernetes中提供了对Pod级别的Requests和Limits的配置。对于CPU和
内存而言，Pod的Requests或Limits是指该Pod中所有容器的Requests或
Limits的总和（对于Pod中没有设置Requests或Limits的容器，该项的值
被当作0或者按照集群配置的默认值来计算）。下面对CPU和内存这两
种计算资源的特点进行说明。

k8s 资源管理

标签：color   有一个   col   思考   系统   问题   ber   its   情况下   

原文地址：https://www.cnblogs.com/shanhua-fu/p/12024307.html