资源 Quota
在生产中我们还会遇到一个场景：假如集群是由多个人同时提交的，或者是多个业务同时在使用，我们肯定要限制某个业务或某个人提交的总量，防止整个集群的资源都会被使用掉，导致另一个业务没有资源使用。
Kubernetes 给我们提供了一个能力叫：ResourceQuota 方法。它可以做到限制 namespace 资源用量。
具体的做法如上图右侧的 yaml 所示，可以看到它的 spec 包括了一个 hard 和 scopeSelector。hard 内容其实和 Resourcelist 很像，这里可以填一些基础的资源。但是它比 ResourceList 更丰富一点，它还可以填写一些 Pod，这样可以限制 Pod 数量能力。然后 scopeSelector 为这个 Resource 方法定义更丰富的索引能力。
比如上面的例子中，索引出非 BestEffort 的 pod，限制的 cpu 是 1000 个，memory 是 200G，Pod 是 10 个，然后 Scope 除了提供 NotBestEffort，它还提供了更丰富的索引范围，包括 Terminating/Not Terminating，BestEffort/NotBestEffort，PriorityClass。
当我们创建了这样的 ResourceQuota 作用于集群，如果用户真的用超了资源，表现的行为是：它在提交 Pod spec 时，会收到一个 forbidden 的 403 错误，提示 exceeded quota。这样用户就无法再提交 cpu 或者是 memory，或者是 Pod 数量的资源。
假如再提交一个没有包含在这个 ResourceQuota 方案里面的资源，还是能成功的。这就是 Kubernetes 里 ResourceQuota 的基本用法。 我们可以用 ResourceQuota 方法来做到限制每一个 namespace 的资源用量，从而保证其他用户的资源使用。
小结：如何满足 Pod 资源要求？
上面介绍完了基础资源的使用方式，也就是我们做到了如何满足 Pod 资源要求。下面做一个小结：
- Pod 要配置合理的资源要求
- CPU/Memory/EphemeralStorage/GPU
- 通过 Request 和 Limit 来为不同业务特点的 Pod 选择不同的 QoS
- Guaranteed：敏感型，需要业务保障
- Burstable：次敏感型，需要弹性业务
- BestEffort：可容忍性业务
- 为每个 NS 配置 ResourceQuota 来防止过量使用，保障其他人的资源可用
