简述
request是指用户“要求”的资源数量，可以理解为至少要给这些资源才行。而limit表示这些资源的上限是什么。如果K8S集群中的Node（物理机资源）不能满足这个Pod（注意Pod是K8S调度的最小单位，而不是container）的request则会分配失败。而且limit是不能小于request的。
CPU
如果container使用的CPU超过了limit限制，那么K8S会将其限制（throttle）。CPU是一种compressible（可压缩的，可压榨的）资源。当CPU超过限制，该container不会被驱逐。但是这个容器中的应用会有很差的性能，比如会处理超时。 CPU的单位是微核，比如要配置1/4个CPU，只需要配置为250m；如果要配置2个CPU，配置为2000m。
It’s when it comes to CPU limits that things get interesting. CPU is considered a “compressible” resource. If your app starts hitting your CPU limits, Kubernetes starts throttling your container. This means the CPU will be artificially restricted, giving your app potentially worse performance! However, it won’t be terminated or evicted. You can use a liveness health check to make sure performance has not been impacted.
内存
内存不能被compressed。如果container超过了limit，他会被终止，或者被spin up a replacement(被重建)。
Unlike CPU resources, memory cannot be compressed. Because there is no way to throttle memory usage, if a container goes past its memory limit it will be terminated. If your pod is managed by a Deployment, StatefulSet, DaemonSet, or another type of controller, then the controller spins up a replacement.
k8s可以针对每个container进行资源配置。由于一个Pod可以有多个container，因此K8S调度时，需要将这些container的所有资源都累加起来计算，看集群中有没有能满足需求的Node。
除了可以对每个container进行资源配置，还可以对Pod进行设置，比如配置该Pod内所有container总的资源（每个container可以平分这些资源），配置该Pod内container的默认资源配置，最大配置，最小配置。其中最大配置表示的limit的配置，最小配置表示的是request配置。也就是说，如果在Pod内没有配置默认的，则会根据最小配置进行K8S资源调度，并且这个Pod使用的资源不能超过最大配置。
如果K8S node的可用资源不能满足Pod的request，则这个node是不能被分配的。一般K8S使用轮询的方式进行调度，即这个node不能满足，则尝试下一个node。如果到最后也没有分配成功资源，则该Pod进入pending状态。
异常情况
如果这个Node被分配的所有Pod的request占满了，正好可以全部分配出去。随着Pod的运行，Pod所需要的资源可能超过request，但是又没有达到limit，但是总的Node资源已经无法满足。如果只是CPU不足了，那么K8S会throttle超过request的CPU资源。如果内存不足了，会有点复杂。
- 如果有些Pod没有配置内存request，那么默认认为超过了限制，作为驱逐候选。
- 对于那些超过request的Pod，按照优先级顺序，先驱逐优先级低的。
- 如果优先级都一样，那么驱逐超过request最多的pod。
下面这段话存疑，待确定
如果一个Pod中，有多个container，但是只有一个container的内存超过了limit，那么会将整个Pod驱逐吗？应该不会，因为K8S资源是container粒度的，Pod只是调度单位。这种情况，只会将超过limit的container驱逐。
