对应到
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和内存这两
种计算资源的特点进行说明。