Quotas, requests, and limits都在OpenShift分配资源的方式中起作用，很容易使它们混淆。实际上，OpenShift在不同时间出于不同目的考虑了它们。下表总结了这些概念：
| 何时评估 | ||
| Quotas | Request Time | 限制单个租户（namespace）可以请求多少资源，以便他们不能占用整个集群资源。 |
| Requests | Scheduling Time | 请求用于选择哪个节点最适合给定的工作负载（以及其他条件）。 |
| Limits | Run Time | 限制用于限制容器在运行时可以使用的最大资源量。 |
QUOTAS附加在namespace上，与集群的实际容量无关。但是，如果一个namespace达到其QUOTAS，则群集将不会接受来自它的任何其他请求，就好像它已满一样（我们还可以设置multi-project quotas，也就是设置一个qouta，对多个Namesapce有效）
最佳实践：创建像T-shirt似的Namespace模板（创建ns的yaml文件）。通过这种方式，集群管理员将通过模板为namespace定义一些标准大小，其中大小由相关的配额确定。
REQUESTS是对容器运行时将消耗的量的估计。OpenShift使用此信息来创建所有节点及其基于已分配容器的可用资源数量的映射。这是一个简单的示例：
在此示例中，需要将请求2GB内存的新Pod分配给已提交内存的节点。由于节点2没有足够的可用资源，因此OpenShift只能将此Pod放置在节点1上。
如果没有节点可以满足请求约束，则OpenShift可以拒绝Pod的调度。
我们可以通过以下命令了解OpenShift如何估算正在使用的节点：
#oc describe node
在此特定示例中，我们有一个具有12GB内存的节点，其中2.6GB被来自部署的20个Pod的request预订。
注意，这个数字（22％）与节点上使用的实际内存无关。因为如果我们未指定容器所需的资源量，则OpenShift会假定其为零。所以，如果您不为容器指定request，技术集群中没有资源了，而OpenShift还会认为所有节点都具有可用容量。也就是说，如果所有pod我们都设置了request，那么上面百分比的将会更高，并且更准确一些。
最佳做法：为所有容器指定request。您可以通过在namecspase的limit range 中设置最小request来指定对所有容器的请求。
LimitRange是在一个namespace中，对容器资源的限制。
https://docs.openshift.com/container-platform/4.6/nodes/clusters/nodes-cluster-limit-ranges.html
我们看一个例子
apiVersion: "v1"kind: "LimitRange"metadata:name: "resource-limits"spec:limits:- type: "Container"max:cpu: "2"memory: "1Gi"min:cpu: "100m"memory: "4Mi"default:cpu: "300m"memory: "200Mi"defaultRequest:cpu: "200m"memory: "100Mi"maxLimitRequestRatio:cpu: "10"
LIMITS
LIMITS确定容器在运行时可以使用的最大资源量（CPU和/或内存）。设置限制相当于将内存限制的--memory参数和CPU限制的--cpu-quota参数传递给docker run命令。
这会影响在给定容器周围创建的cgroup，从而限制了它可以使用的资源。
同样，如果您没有为容器指定LIMITS，则OpenShift会假定它们是不受限制的，并且容器可以消耗节点上所有可用的资源。
查看实时资源利用率
为了解可以在节点上使用的实际资源，您可以运行:
#oc adm top node
实际的资源消耗比上图中OpenShift估计的要高得多。差异的原因是：在此节点中，有多个pod未声明请求和限制。
总而言之，为了完全能够描述集群的可用容量，我们应该能够回答两个问题（并且至少对于内存和CPU，我们需要回答它们）：
根据Pod request的请求，OpenShift可以估计多少容量。
根据当前使用情况实际有多少容量可用。
实际资源可用性对OpenShift估计可用性的跟踪程度将取决于Pod大小调整的程度以及当前的负载。
群集管理员应注意估计资源与实际资源之间的比率。他们还应该制定政策，以确保两个指标尽可能地接近。这使OpenShift可以通过增加密度来优化分配，但同时可以保证所请求的SLA。
监视群集的可用容量
一种方法是编写以上命令的脚本（oc describe node和oc adm top），并进行一些计算以获得答案。另一种方法是使用Kube-ops-view。这是一个K8S上的性能监工具，我们把他部署到了OCP4.6上。
部署方法:
oc new-project ocp-ops-view# oc create sa kube-ops-viewoc adm policy add-scc-to-user privileged system:serviceaccount:ops-view:kube-ops-viewoc adm policy add-scc-to-user privileged system:serviceaccount:ops-view:defaultoc adm policy add-cluster-role-to-user cluster-admin system:serviceaccount:ocp-ops-view:kube-ops-viewoc apply -f https://raw.githubusercontent.com/davidsajare/kube-ops-view-/main/kube-ops-view.yamloc expose svc kube-ops-view
图形化登录UI。这个UI显示每个OCP节点上的pod。我们先看UI各个位置的显示意义：
按照名称排序：
按照运行时间排序：
按照使用内存排序：
按照使用CPU排序：
在下图中，在闪的pod是pendding的pod：
图中的侧柱代表节点的利用率，这里显示的数值，和oc describe node的是一致的：
接下来，我们检查pod的利用率：
我们通过如下命令查看验证
#oc adm top pods -A
得到的结果是一致。说明UI显示的准确的。
这个工具还挺好用的。
