以下内容均来自个人笔记并重新梳理，如有错误欢迎指正！
如果对您有帮助，烦请点赞、关注、转发！如果您有其他想要了解的，欢迎私信联系我～
资源限制
Requests（请求）：定义容器启动时所需的最小资源量。Kubernetes 会确保每个容器至少获得其请求的资源量，以避免因为资源不足而启动失败 Limits（限制）：定义容器可以使用的最大资源量。当容器尝试使用超过其限制的资源时，它可能会被系统终止或受到限制，以防止影响集群中其他容器的性能 Quotas（配额）：针对命名空间内所有资源进行总体限制，用于控制资源的消耗，防止某些用户或团队过度使用资源
资源定义：用户在 Pod 中定义资源请求和限制 调度决策：Kubernetes 调度器在调度 Pod 时会考虑节点上的可用资源。如果节点上的资源不足以满足 Pod 的请求，调度器将不会将 Pod 调度到该节点 资源分配：一旦 Pod 被调度到节点，Kubernetes 会根据资源请求为 Pod 分配资源。Pod 可以使用的资源不会超过其限制 资源监控：Kubernetes 持续监控每个 Pod 的资源使用情况 资源回收：当 Pod 使用的资源超过其限制时，Kubernetes 可以采取回收措施。如果是 CPU 使用超过限制，CPU 会被压缩导致应用程序运行变缓，如果是内存使用超过限制，容器会直接被 OOM Kill 资源配额：通过设置资源配额，Kubernetes 可以限制命名空间内可以创建的资源数量和消耗的资源总量，从而避免资源的过度使用
3、限制方法
配置 Container 限制
apiVersion: apps/v1kind: Deploymentmetadata:nanme: demo-deploymentspec:...spec:containers:...resources:limits:cpu: 1000mmemory: 1Gi: 10Girequests:cpu: 100mmemory: 100Mi: 1Gi说明1：如果没有设置 requests，则其值与 limits 的值相同说明2：如果没有设置 limits， 则其值默认为 0，即没有限制=1c=1000mk/Mi/Gi；无单位是字节，1000=1kk/Mi/Gi，定义临时存储的需求和限制
配置 namespace 限制（即资源配额）
# 定义资源配额对象# resourcequota.yamlapiVersion: v1kind: ResourceQuotametadata:name: quota-demospec:hard:: 1000m: 1000Mi: 4000m: 8000Mi: "1Gi"persistentvolumeclaims: "2"# 创建对象kubectl apply -f resourcequota.yaml# 查看对象kubectl get resourcequotasNAME AGE REQUEST LIMIT4m5s persistentvolumeclaims: 15/2, requests.cpu: 3050m/1, requests.memory: 12912Mi/1000Mi, requests.storage: 1316Gi/1Gi limits.cpu: 63700m/4, limits.memory: 148200Mi/8000Mi
配置默认限制
# 定义 LimitRange 对象# limitrange.yamlapiVersion: v1kind: LimitRangemetadata:name: demo-limit-rangespec:limits:type: Containerdefault:cpu: 500mmemory: 1000MidefaultRequest:cpu: 100mmemory: 200Mi# 创建对象kubectl apply -f limitrange.yaml# 查看对象详情kubectl describe limitrangesName: demo-limit-rangeNamespace: lanhuappType Resource Min Max Default Request Default Limit Max Limit/Request Ratio-------- --- --- --------------- ------------- -----------------------Container cpu - - 100m 500m -Container memory - - 200Mi 1000Mi -
服务质量等级
服务质量等级（Qos，即 Quality Of Service）用于为不同 Pod 提供不同等级的资源供应保障。
服务质量等级分为以下三种：
Guaranteed：Limits 和 Requests 的值相同，等级最高
Burstable：Limits 和 Requests 的值不同
Best-Effort：Limits 和 Requests 的值没有设置 ，等级最低
需要长时间以稳定状态运行的 Pod，可以配置为 Guaranteed 级别，以确保节点资源不足时 Pod 保持稳定运行而不会被驱逐，而其它 pod 则可以配置为 Burstable 甚至 Best-Effort 级别
