在之前的文章中, 介绍了搭建好的#minikube#环境,如果你现在还没有一个可用的minikube环境, 那么可以去中直接下载;
在之前的文章中, 先后介绍了如何从源代码开始构建一个Node.js应用和Spring Boot 应用, 并且部署到Kubernetes 中(这个Kubernetes 环境主要是之前建好的#minikube#) , 现在我们开始进一步深入的学习Kubernetes, 用一个个可以实际运行的例子的形式, 深入理解#Kubernetes#的概念以及原理.
在#动手动脑学Kubernetes#系列教程中, 我们展示了Kubernetes的基本用法
在里, 学习了#Pod#的基本知识;
在里, 学习了标签(#Label#)的语法, 使用Label来选择和过滤Kubernetes 资源;
在里, 介绍了#Deployment#的使用, 介绍了Deployment与Replica Set、Pod的关系, 并展示了如何进行应用的版本回滚;
在里, 介绍了#Service#的使用,使用Replication Controller创建Pod, 并创建Service, 展示了从Service 调用应用的方法; 随后又展示了扩展 Pod的数量为2, 比较了Service和之前的不同, 基本展示了Cluster IP 类型的Service的基本用法.
在里, 介绍了#Namespace#的使用, 除了创建,列出系统的Namespace之外, 还说明Namespace 如何对资源进行隔离, 建立Development, Staging, Production等环境的方法.
在里, 介绍了#Service Discovery#的使用, 讲解了如何检查Kube-dns, 如何检查和使用Service的FQDN等知识, 对Kubernetes的DNS 系统有整体的理解.
在里, 介绍了#Port Forwards#, #端口转发#的用法, 在本地程序开发的时候, 使用端口转发可以简化本地测试的工作, 同时介绍了其他几种本地端口转发的用法.
在里, 介绍了#Probe#(#探针#)的知识, 介绍了livenessProbe 和readinessProbe的用法,同时介绍了Pod 容器中的几个状态变化, 以及2个容器生命周期回调接口.
在里, 介绍了#环境变量#的用法, 使用环境变量可以把Pod 定义的信息传递给运行其中的镜像.
在里, 我们介绍了#Volume#, 卷的用法, 主要展示了emptyDir卷的使用, emptyDir卷的生命周期是和Pod 生命周期同步的.
在里, 我们介绍了#Persistent Volume#, 也就是持久卷的用法,展示了当数据存入到PV 之后,数据超乎Pod 生命周期之外的情况.
在里, 介绍了#Secret#, 也就是机密信息的用法, 机密是绑定在命名空间里的, 在使用时候和Volume的用法一样, 可以被Pod 访问, 本篇展示了Opaque类型的Secret的用法.
在里, 介绍了日志(#logging#)的使用, 介绍了Kubernetes中基本日志记录的查看和常用的命令行参数,在理论部分展示了其他几种logging的使用.
在里, 介绍了#Job#, 也就是作业的使用, 介绍了Kubernetes中最基本的、非并行性的一次性运行的作业, 同时介绍了作业的基本概念和基本用法.
在里, 介绍了#CronJob#, 也就是调度作业的使用, 介绍了CronJob的用法，以及如何查看CronJob的执行情况；同时给出了手工执行CronJob的方法， 用来调试和验证CronJob；最后介绍了Cron表达式的写法.
在里, 介绍了#Init 容器#概念和用法, 同时讲解了init 容器的启动过程和对资源的要求.
在里, 介绍了#API Server#, 以及讲解了API server 返回的API组和版本, REST API, 以及健康检查API, 对API Server 有了初步的理解
今天来学习一下#Resource Quote#， 也就是#资源配额#的概念，继续来学习吧!
当一个Kubernetes 集群中有多个用户或者多个团队时， 对于固定资源的创建、使用必须加以隔离和限制， 以防止相互干扰和竞争， 这时除了我们之前介绍过的Namespace之外， 还可以借助Kubernetes 提供的Resource Quote--资源配额， 来实现这一目的， 先来看看资源配额怎么使用吧。
我们面临着这么一个需求， 团队中需要搭建一个UAT环境， 并且为我们的UAT环境做一下资源限定， 具体要求如下：
每个容器必须有内存请求和限制，以及 CPU 请求和限制。所有容器的内存请求总和不能超过1 GiB。所有容器的内存限制总和不能超过2 GiB。所有容器的 CPU 请求总和不能超过1 cpu。所有容器的 CPU 限制总和不能超过2 cpu。来创建资源配额吧！对于上面的需求， 我们首先来创建相应的命名空间(Namespace)， 目前资源配额一般是和命名空间关联在一起的, 因此我们首先来创建一个对应的UAT 环境：
kubectl create ns uat-env
下面来创建资源配额， 资源配额也是一个Kubernetes 对象， 因此这里用yaml文件来直观表示：
Github地址：
文件内容：
https://raw.githubusercontent.com/hintcnuie/kbe/main/specs/quota/uat-quota.yaml
文件内容：
apiVersion: v1kind: ResourceQuotametadata: name: mem-cpu-quota namespace: uat-envspec: hard: requests.cpu: "1" requests.memory: 1Gi limits.cpu: "2" limits.memory: 2Gi注意， 资源配额的类型（kind）是ResourceQuota, 缩写是quota， 然后是spec.hard模式下有两个针对cpu和内存的配额。 另外还有需要注意的是， 这里使用的是Gi，这里使用的是2的指数级的单位，即1Gi=1024 * Mi； 如果是G，那么单位就是1 G=1000* M
下面先来创建：
$ kubectl apply -f https://raw.githubusercontent.com/hintcnuie/kbe/main/specs/quota/uat-quota.yamlresourcequota/mem-cpu-quota created$ kubectl get quotaNo resources found in default namespace.$ kubectl get quota --namespace=uat-envNAME AGE REQUEST LIMITmem-cpu-quota 6m14s requests.cpu: 0/1, requests.memory: 0/1Gi limits.cpu: 0/2, limits.memory: 0/2Gi创建之后， 我们先在默认的命名空间（default）里面查询， 没有找到相应的配额对象；然后我们使用kubectl get quota --namespace， 通过指定命名空间参数， 然后我们就找到了这个quota 对象。
再来使用kubectl describe,详细查看一下这个对象，当然也要加上命名空间参数
$ kubectl describe quota mem-cpu-quota --namespace=uat-envName: mem-cpu-quotaNamespace: uat-envResource Used Hard-------- ---- ----limits.cpu 0 2limits.memory 0 2Girequests.cpu 0 1requests.memory 0 1Gi看来资源配额已经创建好了， 那么怎么使用呢？ 我们先来创建个Pod 试试吧。
创建Pod 时候指定资源限制首先来看Pod的定义：
Github地址：https://raw.githubusercontent.com/hintcnuie/kbe/main/specs/quota/pod-resource-quota.yaml
文件内容：
apiVersion: v1kind: Podmetadata: name: pod-with-mem-cpu-quota namespace: uat-envspec: containers: - name: pod-with-mem-cpu-quota-c1 image: nginx resources: limits: memory: "800Mi" cpu: "800m" requests: memory: "600Mi" cpu: "400m"值得注意的是， 这个Pod 和以前的Pod 的定义相比， 多了一个resources部分， 里面包含limits和request两个部分。
下面来创建这个Pod：
$ kubectl apply -f https://raw.githubusercontent.com/hintcnuie/kbe/main/specs/quota/pod-resource-quota.yamlpod/pod-with-mem-cpu-quota created$ kubectl get pods --namespace=uat-envNAME READY STATUS RESTARTS AGEpod-with-mem-cpu-quota 1/1 Running 0 15s可以看到在uat-env 命名空间下， 已经创建了这个Pod， 来查看一下这个Pod的详细情况：
$ kubectl describe pod pod-with-mem-cpu-quota --namespace=uat-envName: pod-with-mem-cpu-quotaNamespace: uat-envPriority: 0Node: localhost.localdomain/10.0.2.15Start Time: Wed, 07 Apr 2021 13:04:03 +0000Labels: <none>Annotations: <none>Status: RunningIP: 172.17.0.9IPs: IP: 172.17.0.9Containers: pod-with-mem-cpu-quota-c1: Container ID: docker://b5e7369c5b762b86f702f37be01a6a80e086421feccbce07b84f7620bc5ade5a Image: nginx Image ID: docker-pullable://nginx@sha256:bae781e7f518e0fb02245140c97e6ddc9f5fcf6aecc043dd9d17e33aec81c832 Port: <none> Host Port: <none> State: Running Started: Wed, 07 Apr 2021 13:04:08 +0000 Ready: True Restart Count: 0 Limits: cpu: 800m memory: 800Mi Requests: cpu: 400m memory: 600Mi Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from default-token-t8k5d (ro)Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True Volumes: default-token-t8k5d: Type: Secret (a volume populated by a Secret) SecretName: default-token-t8k5d Optional: falseQoS Class: BurstableNode-Selectors: <none>Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s node.kubernetes.io/unreachable:NoExecute op=Exists for 300sEvents: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 13m default-scheduler Successfully assigned uat-env/pod-with-mem-cpu-quota to localhost.localdomain Normal Pulling 13m kubelet Pulling image "nginx" Normal Pulled 13m kubelet Successfully pulled image "nginx" in 3.945183502s Normal Created 13m kubelet Created container pod-with-mem-cpu-quota-c1 Normal Started 13m kubelet Started container pod-with-mem-cpu-quota-c1可以看到， 这个Pod 里的资源配额， 和我们在yaml里面的定义是一致的。
下面来查看一下，当创建了一个Pod之后的资源配额对象发生了什么变化。
$ kubectl get quota mem-cpu-quota --namespace=uat-env -o=yamlapiVersion: v1kind: ResourceQuotametadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"ResourceQuota","metadata":{"annotations":{},"name":"mem-cpu-quota","namespace":"uat-env"},"spec":{"hard":{"limits.cpu":"2","limits.memory":"2Gi","requests.cpu":"1","requests.memory":"1Gi"}}} creationTimestamp: "2021-04-07T12:01:38Z" managedFields: - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:status: f:hard: .: {} f:limits.cpu: {} f:limits.memory: {} f:requests.cpu: {} f:requests.memory: {} f:used: {} manager: kube-controller-manager operation: Update time: "2021-04-07T12:01:38Z" - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:annotations: .: {} f:kubectl.kubernetes.io/last-applied-configuration: {} f:spec: f:hard: .: {} f:limits.cpu: {} f:limits.memory: {} f:requests.cpu: {} f:requests.memory: {} manager: kubectl-client-side-apply operation: Update time: "2021-04-07T12:01:38Z" - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:status: f:used: f:limits.cpu: {} f:limits.memory: {} f:requests.cpu: {} f:requests.memory: {} manager: kube-apiserver operation: Update time: "2021-04-07T13:04:03Z" name: mem-cpu-quota namespace: uat-env resourceVersion: "40818" uid: ebf8ebb4-0970-42ba-a678-90fee3a86a3aspec: hard: limits.cpu: "2" limits.memory: 2Gi requests.cpu: "1" requests.memory: 1Gistatus: hard: limits.cpu: "2" limits.memory: 2Gi requests.cpu: "1" requests.memory: 1Gi used: limits.cpu: 800m limits.memory: 800Mi requests.cpu: 400m requests.memory: 600Mi上面的内容中， 我们重点来看最后的status 部分，可以看出在used部分， 资源配额中的cpu 和memory 部分都已经发生了变化, requests的配额已经使用了一部分。
status: hard: limits.cpu: "2" limits.memory: 2Gi requests.cpu: "1" requests.memory: 1Gi used: limits.cpu: 800m limits.memory: 800Mi requests.cpu: 400m requests.memory: 600Mi下面我们来尝试着看一下， 再创建一个Pod 会怎么样。
先来看第二个Pod的定义：
Github地址：
https://raw.githubusercontent.com/hintcnuie/kbe/main/specs/quota/pod2-resource-quota.yaml
文件内容：
apiVersion: v1kind: Podmetadata: name: pod2-with-mem-cpu-quota namespace: uat-envspec: containers: - name: pod2-with-mem-cpu-quota-c1 image: nginx resources: limits: memory: "1Gi" cpu: "800m" requests: memory: "700Mi" cpu: "400m"这个配置文件中，你可以看到 Pod 的内存请求为 700 MiB。 请注意新的内存请求与已经使用的内存请求之和超过了内存请求的配额： 600 MiB + 700 MiB > 1 GiB。
尝试创建 Pod：
$ kubectl apply -f https://raw.githubusercontent.com/hintcnuie/kbe/main/specs/quota/pod2-resource-quota.yamlError from server (Forbidden): error when creating "https://raw.githubusercontent.com/hintcnuie/kbe/main/specs/quota/pod2-resource-quota.yaml": pods "pod2-with-mem-cpu-quota" is forbidden: exceeded quota: mem-cpu-quota, requested: requests.memory=700Mi, used: requests.memory=600Mi, limited: requests.memory=1Gi第二个 Pod 不能被创建成功。上面的输出结果显示创建第二个 Pod 会导致内存请求总量超过内存请求配额。
设置命名空间的默认资源限额刚才我们的例子中， 资源限额是在Pod 级别分别设置的， 如果我们想在某一个命名空间中， 设置默认的cpu 和memory的资源限额， 应该怎么做呢？
这时候Kubernetes资源限制中的另外一个对象， LimitRange就上场了， 通过这个对象， 我们可以设置一个命名空间内的对象的资源使用限制， 先来一个例子看看。
Github 地址：
https://raw.githubusercontent.com/hintcnuie/kbe/main/specs/limits/uat-limits.yaml
文件内容：
apiVersion: v1kind: LimitRangemetadata: name: mem-cpu-limits-in-uat namespace: uat-envspec: limits: - default: memory: 512Mi cpu: 1 defaultRequest: memory: 256Mi cpu: 0.5 type: Container上面的资源文件定义里面， 我们对uat-env环境下的所有容器， 都默认要求其cpu 不能超过0.5， 内存不能超过256MiB。
先来创建一下看看运行情况：
$ kubectl apply -f https://raw.githubusercontent.com/hintcnuie/kbe/main/specs/limits/uat-limits.yamllimitrange/mem-cpu-limits-in-uat created[vagrant@control-plane ~]$ kubectl get limits --namespace=uat-envNAME CREATED ATmem-cpu-limits-in-uat 2021-04-07T14:58:33Z来详细地查看一下这个LimitRange对象的情况：
$ kubectl get limits/mem-cpu-limits-in-uat -o=yaml --namespace=uat-envapiVersion: v1kind: LimitRangemetadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"LimitRange","metadata":{"annotations":{},"name":"mem-cpu-limits-in-uat","namespace":"uat-env"},"spec":{"limits":[{"default":{"cpu":1,"memory":"512Mi"},"defaultRequest":{"cpu":0.5,"memory":"256Mi"},"type":"Container"}]}} creationTimestamp: "2021-04-07T14:58:33Z" managedFields: - apiVersion: v1 fieldsType: FieldsV1 fieldsV1: f:metadata: f:annotations: .: {} f:kubectl.kubernetes.io/last-applied-configuration: {} f:spec: f:limits: {} manager: kubectl-client-side-apply operation: Update time: "2021-04-07T14:58:33Z" name: mem-cpu-limits-in-uat namespace: uat-env resourceVersion: "42381" uid: 897b1d74-a960-4320-9227-9fde0eb06b20spec: limits: - default: cpu: "1" memory: 512Mi defaultRequest: cpu: 500m memory: 256Mi type: Container可以看出这个限制是和我们的定义是一致的， 默认的请求限制是， cpu 是500m， 内存是256MiB；
在创建Pod 之前， 先来看看一个uat-env 环境下的资源配额情况：
status: hard: limits.cpu: "2" limits.memory: 2Gi requests.cpu: "1" requests.memory: 1Gi used: limits.cpu: 800m limits.memory: 800Mi requests.cpu: 400m requests.memory: 600Mi然后我们使用命令来创建一个Pod， Pod 中不明确标记限额。
$ kubectl run nginx-test-in-uat-env --image=nginx --restart=Never --namespace=uat-env pod/nginx-test-in-uat-env created$ kubectl describe pod nginx-test-in-uat-env --namespace=uat-envName: nginx-test-in-uat-envNamespace: uat-envPriority: 0Node: localhost.localdomain/10.0.2.15Start Time: Wed, 07 Apr 2021 15:21:24 +0000Labels: run=nginx-test-in-uat-envAnnotations: kubernetes.io/limit-ranger: LimitRanger plugin set: cpu, memory request for container nginx-test-in-uat-env; cpu, memory limit for container nginx-test-in-uat-envStatus: Running...Containers: nginx-test-in-uat-env: ... State: Running Started: Wed, 07 Apr 2021 15:21:28 +0000 Ready: True Restart Count: 0 Limits: cpu: 1 memory: 512Mi Requests: cpu: 500m memory: 256Mi...QoS Class: Burstable...在上面的命令中， 我们创建了一个名字为nginx-test-in-uat-env的Pod， 从最上面的Annotation部分就能看到已经和LimitRange关联；而且我们在使用kubectl describe 查看的时候， 也能够看到这个Pod遵循了默认的配额限制： 内存请求为256Mi， cpu为500m。
那么当这个Pod 创建之后， uat-env 这个命名空间下的资源配额情况怎么样了呢？这时候再来检查一下之前的Quota：
$ kubectl get quota mem-cpu-quota --namespace=uat-env -o=yamlapiVersion: v1kind: ResourceQuotametadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"v1","kind":"ResourceQuota","metadata":{"annotations":{},"name":"mem-cpu-quota","namespace":"uat-env"},"spec":{"hard":{"limits.cpu":"2","limits.memory":"2Gi","requests.cpu":"1","requests.memory":"1Gi"}}} creationTimestamp: "2021-04-07T12:01:38Z" ... name: mem-cpu-quota namespace: uat-env resourceVersion: "42687" uid: ebf8ebb4-0970-42ba-a678-90fee3a86a3aspec: hard: limits.cpu: "2" limits.memory: 2Gi requests.cpu: "1" requests.memory: 1Gistatus: hard: limits.cpu: "2" limits.memory: 2Gi requests.cpu: "1" requests.memory: 1Gi used: limits.cpu: 1800m limits.memory: 1312Mi requests.cpu: 900m requests.memory: 856Mi可以看出， 现在的资源配额对象的used部分已经发生变化， 请求的cpu和memory部分，已经是两个Pod之和。
Pod
request
cpu
request
memory
nginx-test-in-uat-env
500m
256Mi
pod-with-mem-cpu-quota
400m
600Mi
--
--
--
Total
900m
856Mi
可见， 当我们在uat-env的命名空间中增加了LimitRange对象的限制之后， 对于Pod的创建和使用， 就会有默认的资源限制； 这时候Kubernetes系统管理员就可以从具体的资源分配中解放出来。
对于资源配额的操作， 我们先操作到这里，下面我们来看看相关的知识吧。
Kubernetes中的资源类型Kubernetes中的资源，基本上可以分为计算资源、存储资源、API 资源和扩展资源这四种。
计算资源是可以计算的资源类型，包括CPU 和内存， 计算资源的数量是可测量的，可以被请求、被分配、被消耗。 对于计算资源， 都可以指定limits和request 两种设置。
K8S通过Request和Limit两个抽象概念来支持资源的升级与配额的管理，对于以下两种资源K8S都有权来管理，Request主要是应用发布时对容器的使用量进行灵活配置；Limit主要是对应用容器进行资源限制，使应用容器能够合理进行资源占有。
请求和约束
资源的请求（request）和约束（limit）如果 Pod 运行所在的节点具有足够的可用资源，容器可能（且可以）使用超出对应资源 request 属性所设置的资源量。不过，容器不可以使用超出其资源 limit 属性所设置的资源量。
例如，如果将容器的 memory 的请求量设置为 256 MiB，而该容器所处的 Pod 被调度到一个具有 8 GiB 内存的节点上，并且该节点上没有其他 Pods 运行，那么该容器就可以尝试使用更多的内存。
如果将某容器的 memory 约束设置为 4 GiB，kubelet （和 容器运行时） 就会确保该约束生效。 容器运行时会禁止容器使用超出所设置资源约束的资源。 例如：当容器中进程尝试使用超出所允许内存量的资源时，系统内核会将尝试申请内存的进程终止， 并引发内存不足（OOM）错误。
约束值可以以被动方式来实现（系统会在发现违例时进行干预），或者通过强制生效的方式实现 （系统会避免容器用量超出约束值）。不同的容器运行时采用不同方式来实现相同的限制。
用户可以对给定命名空间下的可被请求的计算资源总量进行限制。
配额机制所支持的资源类型：
资源名称
描述
limits.cpu
所有非终止状态的 Pod，其 CPU 限额总量不能超过该值。
limits.memory
所有非终止状态的 Pod，其内存限额总量不能超过该值。
requests.cpu
所有非终止状态的 Pod，其 CPU 需求总量不能超过该值。
requests.memory
所有非终止状态的 Pod，其内存需求总量不能超过该值。
hugepages-<size>
对于所有非终止状态的 Pod，针对指定尺寸的巨页请求总数不能超过此值。
cpu
与 requests.cpu 相同。
memory
与 requests.memory 相同。
下面来详细介绍Kuberenets中的计算资源。
Kubernetes 中的CPU 资源CPU 资源的约束和请求以 cpu 为单位。
Kubernetes 中的一个 cpu 等于云平台上的 1 个 vCPU/核和裸机 Intel 处理器上的1 个超线程 。
你也可以表达带小数 CPU 的请求。spec.containers[].resources.requests.cpu 为 0.5 的 Container 肯定能够获得请求 1 CPU 的容器的一半 CPU 资源。表达式 0.1 等价于表达式 100m， 可以看作 “100 millicpu”。有些人说成是“一百毫 cpu”，其实说的是同样的事情。 具有小数点（如 0.1）的请求由 API 转换为 100m；最大精度是 1m。 因此，或许你应该优先考虑使用 100m 的形式。
CPU 总是按绝对数量来请求的，不可以使用相对数量； 0.1 的 CPU 在单核、双核、48 核的机器上的意义是一样的。
Kubernetes 中的内存资源内存的约束和请求以字节为单位。你可以使用以下后缀之一以一般整数或定点数字形式来表示内存： E、P、T、G、M、K。你也可以使用对应的 2 的幂数：Ei、Pi、Ti、Gi、Mi、Ki。 例如，以下表达式所代表的是大致相同的值：
128974848、129e6、129M、123Mi下面是个例子。
以下 Pod 有两个 Container。每个 Container 的请求为 0.25 cpu 和 64MiB（226 字节）内存， 每个容器的资源约束为 0.5 cpu 和 128MiB 内存。 可以认为该 Pod 的资源请求为 0.5 cpu 和 128 MiB 内存，资源限制为 1 cpu 和 256MiB 内存。
apiVersion: v1kind: Podmetadata: name: frontendspec: containers: - name: app image: images.my-company.example/app:v4 env: - name: MYSQL_ROOT_PASSWORD value: "password" resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m" - name: log-aggregator image: images.my-company.example/log-aggregator:v6 resources: requests: memory: "64Mi" cpu: "250m" limits: memory: "128Mi" cpu: "500m"下面来看一下Kubernetes中的API 资源。
Kubernetes中的API资源API资源与计算资源不同， API 资源是指对API 对象的数量的限制， 自从Kubernetes 1.9之后， 你可以指定命名空间中的API对象的数量。
例如下面是一个对命名空间中Pod数量的限制，只允许这个命名空间下有两个Pod：
apiVersion: v1kind: ResourceQuotametadata: name: pods-quota namespace: pods-quota-nsspec: hard: pods: 2Kubernetes中的存储资源对于存储资源的资源配额，相对于计算资源而言相对复杂一些， 对于Namespace而言主要有两种可以限制的实体： 存储的数量和持久性存储声明（persistent volume claim）的数量。对于具体的storage， 也可以进行限制，但是要视具体的存储类（class）而定。
requests.storage
所有的persistent volume claim的请求存储的总量
persistentvolumeclaims
一个命名空间中允许的persistent volume claim的最大数量
扩展资源（Extended Resources）扩展资源是 kubernetes.io 域名之外的标准资源名称。 它们使得集群管理员能够颁布非 Kubernetes 内置资源，而用户可以使用他们。
使用扩展资源需要两个步骤。首先，集群管理员必须颁布扩展资源。其次，用户必须在 Pod 中请求扩展资源。好了， 对于Kubernetes中的资源配额， 就介绍到这里， 继续学习Kubernetes吧！
回顾本篇介绍了Kubernetes中资源配额（#ResourceQuota#）的使用， 并用例子展示了如何在一个特定的命名空间中使用资源配额， 以及如何在一个命名空间中使用#LimitRange#来设置默认的资源配额。 最后， 介绍了Kubernetes中的资源分类， 重点介绍了计算资源的定义、单位和如何设置。
阳春布德泽，万物生光辉
