一图说清Kubernetes资源控制机制：让我们重新认识OpenShift系列6

OpenShift的资源控制和K8S无本质区别。

资源控制配置方式不难，难在把所有概念理清楚。

我们通过思维导图把这些概念理清楚。

首先照着上图说结论：

1.针对OCP的资源限制，如果想对某一个pod进行限制，其余的pod都不限制，那个就在deployments或者dc中配置request和limits。这样做的好处是：但OCP在调度这个pod时，先查worker节点上能够满足request的资源，才调度到这个节点上。

2. 如果要整体限制资源。那么通常以namespaces为单位。qoutas限制的是一个项目中，此类对象的总数，比如项目中，pod使用的cpu资源总量，svc的总量。limits range是限制一类对象的使用资源范围，如pod能够获取到的cpu和内存的最大值、最小值。limits range中defaultRequest部分为容器中的容器设置默认请求，如果不设置最大值和最小值，那么就会用这个资源的数值。defaultRequest不低于min，不高于max。

3.Cluster qoutas本质上用的还是namespace qouta。只是可以一次性让多个项目生效而已。

所以说，qoutas和limits range要结合使用才有更高的控制颗粒度。避免将LimitRange约束设置得太高，或者将ResourceQuota约束设置得太低。违反LimitRange constraints会阻止pod创建，并显示错误消息。违反资源配额约束会阻止将Pod调度到任何节点。pods可能已创建，但仍处于挂起状态。

定义Pod的资源请求和限制

pod定义可以包括资源请求和资源限制：

• Resource requests：用于调度，并指示Pod无法以少于指定数量的计算资源运行。调度程序尝试查找具有足够计算资源以满足Pod请求的节点。

• Resource limits：用于防止Pod耗尽节点上的所有计算资源。运行Pod的节点将配置Linux kernel cgroups功能以强制对Pod进行资源限制。

应该为部署或部署配置资源中的每个容器定义资源请求和资源限制。如果尚未定义请求和限制，则将找到每个容器的resources:()行。

修改resources: {}以指定所需的request和limits。例如：

如果使用oc edit命令修改deployments或dc，请确保使用正确的缩进。缩进错误可能导致编辑器拒绝保存更改。为避免缩进问题，可以使用oc set resources命令指定资源请求和限制。以下命令设置与上例相同的请求和限制。

oc set resources deployment hello-world-nginx --requests cpu=10m,memory=20Mi --limits cpu=80m,memory=100Mi

如果资源qoutas适用于资源请求，则pods应定义一个资源请求。如果资源配额适用于资源限制，那么pods还应该定义资源限制。即使没有使用配额，红帽也建议定义资源请求和限制。

查看requests、limits和实际使用情况

使用OpenShift命令行界面，群集管理员可以查看各个节点上的计算使用情况信息。oc describe node命令显示有关节点的详细信息，包括有关在该节点上运行的容器的信息。对于每个pods，它显示CPU  requests和limites以及内存requests和limits。如果未指定请求或限制，那么pods将在该列显示0。还显示所有资源请求和限制的摘要。

# oc describe nodes worker-0

查看最底下的内容：

“requests和limits”的摘要列显示已定义的请求和限制的总数。对于上面的输出，在节点上运行的20个pod中只有1个定义了内存限制，该限制为512Mi。

oc describe node命令显示request和limits的静态数值，而oc adm top命令显示实际用法。例如，如果容器请求10m的CPU，则调度程序将确保将容器放置在具有可用容量的节点上。尽管Pod请求了10m的CPU，但它可能会使用多于或少于此值，除非它也受CPU限制的约束。同样，未指定资源请求的pod仍将使用一些资源。oc adm top nodes命令显示集群中一个或多个节点的实际使用情况，而oc adm top pods命令显示项目中每个Pod的实际使用情况。

我们查看所有项目中的pod利用率排名：

oc adm pods --all-namespaces

查看节点的资源利用率：

只查看worker节点的资源使用：

# oc adm top nodes -l node-role.kubernetes.io/worker

使用qoutas

OpenShift容器平台可以强制实施配额，以跟踪和限制两种资源的使用：

• Object counts

  Kubernetes资源的数量，例如Pod， services, and routes.

• Compute resources

  物理或虚拟硬件资源的数量，例如CPU，内存和存储容量。

通过避免Etcd数据库的无限制增长，对Kubernetes资源的数量施加配额可提高OpenShift控制平面的稳定性。Kubernetes资源上的配额还可以避免耗尽其他有限的软件资源，例如服务的IP地址。

以类似的方式，对计算资源量施加配额可避免耗尽OpenShift群集中单个节点的计算能力。通过使用所有群集容量，还避免了一个应用程序使共享群集中的其他应用程序资源不足无法运行。

OpenShift通过使用资源配额资源或配额来管理群集中资源数量的配额和计算资源的使用。配额指定项目的硬资源使用限制。配额的所有属性都是可选的，这意味着不受配额限制的任何资源都可以无限制地使用。

尽管单个配额资源可以定义一个项目的所有配额，但是一个项目可以包含多个配额。例如，一个配额资源可能会限制计算资源，例如允许的总CPU或允许的总内存。另一个配额资源可能会限制对象计数，例如允许的Pod数量或允许的服务数量。多个配额的影响是累积性的，但可以预期的是，同一项目的两个不同的ResourceQuota资源不会限制使用相同类型的Kubernetes或计算资源。例如，项目中的两个不同配额不应同时尝试限制允许的Pod的最大数量。

下表描述了一些qouta可以限制其数量或数量的资源。

下表描述了可以受配额限制的一些计算资源。

配额属性可以跟踪项目中所有pods的资源请求或资源限制。默认情况下，配额属性跟踪资源requests。要跟踪资源limits，请在计算资源名称前添加限制，例如limits.cpu。

以下清单显示了使用YAML语法定义的资源配额资源。本示例指定资源数量和计算资源使用的qoutas：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
spec:
  hard:
    services: "10"
    cpu: "1300m"
    memory: "1.5Gi"

pod源请求和资源限制的资源单位相同，例如：Gimeans GiB和mmeans millicores。1毫内核等于一个CPU内核的1/1000。

可以使用与任何其他OpenShift Container Platform资源相同的方式来创建资源配额。也就是说，通过将YAML或JSON资源定义文件传递给theoc create命令：

$oc create --save-config -f dev-quota.yml

创建资源配额的另一种方法是使用oc create quota命令，例如：

$oc create quota dev-quota --hard services=10,cpu=1300,memory=1.5Gi

使用oc get resource quota命令列出可用的配额，并使用oc describe resourcequota命令查看与配额中定义的任何硬限制有关的使用情况统计信息，例如：

[user@demo ~]$oc get resourcequota
NAME            CREATED AT
compute-quota   2019-11-26T21:51:43Z
count-quota     2019-11-26T21:51:09Z

没有参数，oc describe quota命令显示为项目中的all Resource Quota资源设置的累积限制。

[user@demo ~]$oc describe quota
Name:       compute-quota
Namespace:  schedule-demo
Resource    Used    Hard
--------    ----    ----
cpu         500m    10
memory      300Mi   1Gi


Name:                   count-quota
Namespace:              schedule-demo
Resource                Used  Hard
--------                ----  ----
pods                    1     3
replicationcontrollers  1     5
services                1     2

可以使用oc delete命令按名称删除活动配额：

$oc delete resourcequota QUOTA

在项目中首次创建配额时，项目将限制创建可能违反配额约束的任何新资源的能力，直到它计算了更新的使用情况统计信息为止。创建配额并使用情况统计信息是最新的之后，项目将接受新内容的创建。创建新资源后，配额使用量会立即增加。删除资源后，下一次完全重新计算项目的配额统计信息时，配额使用量将减少。

配额适用于新资源，但不会影响现有资源。例如，如果创建配额将项目限制为15个Pod，但是已经有20个Pod正在运行，则该配额将不会删除超出配额的其他5个Pod。

ResourceQuota约束总体上适用于项目，但是许多OpenShift流程（例如构建和部署）会在项目内部创建pod，并且可能会失败，因为启动它们会超出项目配额。

如果对项目的修改超出了资源计数的配额，则服务器将拒绝该操作，并向用户返回适当的错误消息。但是，如果修改超出了计算资源的配额，则操作不会立即失败。OpenShift会重试该操作几次，使管理员有机会增加配额或执行其他纠正措施，例如使新节点联机。

如果设置了限制项目使用计算资源的配额，则OpenShift拒绝创建未为该计算资源指定资源请求或资源限制的Pod。要对受配额限制的项目使用大多数模板和构建器，该项目还必须包含一个限制范围资源，该资源指定容器资源请求的默认值。

使用Limit Ranges

LimitRange resource也称为limit，它定义计算资源请求的默认值，最小值和最大值，以及项目中定义的单个容器或单个容器的限制。容器的资源请求或限制是其容器的总和。

要了解 limit range 和resource quota的区别，请考虑限制范围定义单个pods的有效范围和默认值，而resource quota仅定义项目中所有pods总和的最高值。关心OpenShift集群中资源使用情况的集群管理员通常为项目定义limits和quotas。

 limit range资源还可以定义image，is或pvc所请求的存储容量的默认值，最小值和最大值。如果添加到项目中的资源未提供计算资源请求，则它将采用该项目的限制范围所提供的默认值。如果新资源提供的计算资源请求或限制小于项目限制范围所指定的最小值，则不会创建该资源。以类似的方式，如果新资源提供的计算资源请求或限制高于项目限制范围所指定的最大值，则不会创建该资源。

下表描述了可以由limit range资源指定的一些计算资源。

以下清单显示了使用YAML语法定义的限制范围：

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "dev-limits"
spec:
  limits:
    - type: "Pod"
      max:
        cpu: "500m"
        memory: "750Mi"
      min:
        cpu: "10m"
        memory: "5Mi"
    - type: "Container"
      default:
        cpu: "100m"
        memory: "100Mi"
      max:
        cpu: "500m"
        memory: "750Mi"
      min:
        cpu: "10m"
        memory: "5Mi"

用户可以像创建其他OpenShift资源一样创建限制范围资源。也就是说，通过将YAML或JSON资源定义文件传递给oc create命令：

oc create --save-config -f  dev-limits.yml

红帽OpenShift容器平台4.2并不像资源配额那样专门为限制范围提供oc create命令行。唯一的选择是使用YAML或JSON文件。

使用oc describe limitrange命令可查看项目中实施的限制约束。

oc describe limitrange dev-limits
Name:       dev-limits
Namespace:  schedule-demo
Type        Resource  Min  Max    Default Request  Default Limit  ...
----        --------  ---  ---    ---------------  -------------  ...
Pod         cpu       10m  500m   -                -              ...
Pod         memory    5Mi  750Mi  -                -              ...
Container   cpu       10m  500m   100m             100m           ...
Container   memory    5Mi  750Mi  100Mi            100Mi          ...

可以使用oc delete命令通过名称删除活动的限制范围：

oc delete limitrange dev-limits

在项目中创建限制范围后，将针对项目中的每个限制范围资源评估所有创建新资源的请求。如果新资源违反了任何限制范围所列举的最小或最大约束，则该资源将被拒绝。如果新资源未设置显式值，并且约束条件支持默认值，则默认值将作为其使用值应用于新资源。

还针对项目中的每个限制范围资源评估所有资源更新请求。如果更新的资源违反任何约束，则拒绝更新。

避免将LimitRange约束设置得太高，或者将ResourceQuota约束设置得太低。违反LimitRange constraints会阻止pod创建，并显示错误消息。违反资源配额约束会阻止将Pod调度到任何节点。pods可能已创建，但仍处于挂起状态。

将配额应用于多个项目

集群资源配额资源是在群集级别创建的，类似于持久卷，并指定了适用于多个项目的资源约束。

群集管理员可以通过两种方式指定哪些项目要受群集资源配额的限制：

使用openshift.io/requesterannotation指定项目所有者。具有指定所有者的所有项目均受配额限制。

使用selector。标签与选择器匹配的所有项目均受配额限制。

以下是为qauser拥有的所有项目创建群集资源配额的示例：

$oc create clusterquotauser-qa --project-annotation-selector openshift.io/requester=qa --hard pods=12,secrets=20

以下是为已分配了所有项目的项目创建群集资源配额的示例。 environment=qa

$oc create clusterquotaenv-qa --project-label-selectorenvironment=qa --hard pods=10,services=5

项目用户可以使用oc describe QUOTA命令查看适用于当前项目的群集资源配额（如果有）。

使用oc delete命令删除集群资源配额：

[user@demo ~]$oc delete clusterquota QUOTA

标签：重新认识,限制,Kubernetes,oc,配额,Pod,计算资源,OpenShift,资源
来源： https://blog.51cto.com/u_15127570/2711348