演示使用了下面的资源：Namespace, ResourceQuota, 和 LimitRange。
开始之前
你必须有一个Kubernetes集群，并且kubectl命令行工具能够和你的集群沟通。如果你还没有集群，可以使用Minikube创建一个集群。
场景
集群管理员操作多用户团队的集群，集群管理员希望可以控制特定集群中可以消耗资源的总量，以提升集群的共享和控制成本。
- 限制运行pod的计算资源量
- 限制持久卷声明数量来控制对于存储的访问
- 限制负载均衡数量来控制成本
- 限制使用节点端口来保存稀缺的资源
- 提供默认的计算资源请求以实现更好的调度策略
新建命名空间
这个例子将在自定义的命名空间工作以演示相关的概念。
让我们新建一个名字为quota-example的命名空间：
$ kubectl create namespace quota-example
namespace "quota-example" created
$ kubectl get namespaces
NAME STATUS AGE
default Active 2m
kube-system Active 2m
quota-example Active 39s
将对象计数配额应用于命名空间
集群管理员像控制下面的资源：
- 持久卷声明
- 负载均衡
- 节点端口
让我们新建一个简单的配额来控制命名空间中的对象计数。
$ kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/rq-object-counts.yaml --namespace=quota-example
resourcequota "object-counts" created
配额系统观察到配额已经创建，并将计算命名空间中资源的消耗。很快就可以看到。
我们来观察配额，看看目前命名空间中消耗的是什么：
$ kubectl describe quota object-counts --namespace=quota-example
Name: object-counts
Namespace: quota-example
Resource Used Hard
-------- ---- ----
persistentvolumeclaims 0 2
services.loadbalancers 0 2
services.nodeports 0 0
如果用户创建应用所需的资源多余每种资源指定的数量，配额系统将不允许创建。
将计算资源配额应用于命名空间
限制命名空间可以消耗的计算资源量，让我们创建一个配额跟踪计算资源。
$ kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/rq-compute-resources.yaml --namespace=quota-example
resourcequota "compute-resources" created
我们来观察配额，看看目前命名空间中消耗的是什么：
$ kubectl describe quota compute-resources --namespace=quota-example
Name: compute-resources
Namespace: quota-example
Resource Used Hard
-------- ---- ----
limits.cpu 0 2
limits.memory 0 2Gi
pods 0 4
requests.cpu 0 1
requests.memory 0 1Gi
配额系统现在不允许命名空间中超过4个非终端pod。此外它将强制pod中的每个容器都要定义cpu和内存的request和limit。
应用默认的资源请求和限制
Pod的发起者很少给他们的pod指定资源请求和限制。
由于我们对项目施行了配额，让我看看当最终用户创建了没有cpu和内存限制的pod发生了什么，这个pod包含一个nginx容器。
这个演示我们创建了一个运行了nginx的deployment：
$ kubectl run nginx --image=nginx --replicas=1 --namespace=quota-example
deployment "nginx" created
让我们看看创建的pod：
$ kubectl get pods --namespace=quota-example
可以看到没有创建pod！让我们看看deployment发生了什么。
$ kubectl describe deployment nginx --namespace=quota-example
Name: nginx
Namespace: quota-example
CreationTimestamp: Mon, 06 Jun 2016 16:11:37 -0400
Labels: run=nginx
Selector: run=nginx
Replicas: 0 updated | 1 total | 0 available | 1 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 1 max unavailable, 1 max surge
OldReplicaSets: <none>
NewReplicaSet: nginx-3137573019 (0/1 replicas created)
...
deployment创建了一个相应的副本，并尝试创建一个pod。
看看replica set获取很多详细信息。
$ kubectl describe rs nginx-3137573019 --namespace=quota-example
Name: nginx-3137573019
Namespace: quota-example
Image(s): nginx
Selector: pod-template-hash=3137573019,run=nginx
Labels: pod-template-hash=3137573019
run=nginx
Replicas: 0 current / 1 desired
Pods Status: 0 Running / 0 Waiting / 0 Succeeded / 0 Failed
No volumes.
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
4m 7s 11 {replicaset-controller } Warning FailedCreate Error creating: pods "nginx-3137573019-" is forbidden: Failed quota: compute-resources: must specify limits.cpu,limits.memory,requests.cpu,requests.memory
Kubernetes API服务拒绝replica set请求创建一个pod因为我们的pod没有指定requests或limits的cpu和内存。
所以我们可以指定pod可以消耗的cpu和内存资源量的默认值：
$ kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/rq-limits.yaml --namespace=quota-example
limitrange "limits" created
$ kubectl describe limits limits --namespace=quota-example
Name: limits
Namespace: quota-example
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
---- -------- --- --- --------------- ------------- -----------------------
Container memory - - 256Mi 512Mi -
Container cpu - - 100m 200m -
如果Kubernetes API服务观察到命名空间中创建pod的请求，并且pod中的容器没有设置任何计算资源请求，将会配置默认的资源request和limit作为控制的一部分被应用。
在这个例子中，创建的每个pod都包含等同于以下的计算资源：
$ kubectl run nginx \
--image=nginx \
--replicas=1 \
--requests=cpu=100m,memory=256Mi \
--limits=cpu=200m,memory=512Mi \
--namespace=quota-example
现在我们已经为命名空间应用了默认的计算资源，我们的replica set能够创建他的pod。
$ kubectl get pods --namespace=quota-example
NAME READY STATUS RESTARTS AGE
nginx-3137573019-fvrig 1/1 Running 0 6m
如果打印命名空间的配额使用：
$ kubectl describe quota --namespace=quota-example
Name: compute-resources
Namespace: quota-example
Resource Used Hard
-------- ---- ----
limits.cpu 200m 2
limits.memory 512Mi 2Gi
pods 1 4
requests.cpu 100m 1
requests.memory 256Mi 1Gi
Name: object-counts
Namespace: quota-example
Resource Used Hard
-------- ---- ----
persistentvolumeclaims 0 2
services.loadbalancers 0 2
services.nodeports 0 0
你可以看到，创建的pod正在消耗计算资源，并且Kubernetes可以比较明确的跟踪使用情况。
高级配额范围
我们假设你不想在命名空间中指定默认的消耗资源。相反你希望让用户在他们的命名空间中运行特定数量的BestEffort pod，以利用松散的计算资源，然后要求用户对需要较高服务质量的pod进行明确的资源请求。
让我们创建一个命名空间并提供两个配额来演示这个行为：
$ kubectl create namespace quota-scopes
namespace "quota-scopes" created
$ kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/rq-best-effort.yaml --namespace=quota-scopes
resourcequota "best-effort" created
$ kubectl create -f http://k8s.io/docs/tasks/configure-pod-container/rq-not-best-effort.yaml --namespace=quota-scopes
resourcequota "not-best-effort" created
$ kubectl describe quota --namespace=quota-scopes
Name: best-effort
Namespace: quota-scopes
Scopes: BestEffort
* Matches all pods that have best effort quality of service.
Resource Used Hard
-------- ---- ----
pods 0 10
Name: not-best-effort
Namespace: quota-scopes
Scopes: NotBestEffort
* Matches all pods that do not have best effort quality of service.
Resource Used Hard
-------- ---- ----
limits.cpu 0 2
limits.memory 0 2Gi
pods 0 4
requests.cpu 0 1
requests.memory 0 1Gi
在这种场景下，一个pod没有设置计算资源请求将被"best-effort"配额追踪。
让我们来创建两个deployments来演示：
$ kubectl run best-effort-nginx --image=nginx --replicas=8 --namespace=quota-scopes
deployment "best-effort-nginx" created
$ kubectl run not-best-effort-nginx \
--image=nginx \
--replicas=2 \
--requests=cpu=100m,memory=256Mi \
--limits=cpu=200m,memory=512Mi \
--namespace=quota-scopes
deployment "not-best-effort-nginx" created
即使没有指定默认限制，best-effort-nginx将创建所有的8个pod。这是因为它追踪best-effort配置，not-best-effort配置将忽略它。not-best-effort配置将追踪not-best-effort-nginx deployment因为它创建了具有Burstable服务质量的pod。
让我们看看命名空间的pod列表：
$ kubectl get pods --namespace=quota-scopes
NAME READY STATUS RESTARTS AGE
best-effort-nginx-3488455095-2qb41 1/1 Running 0 51s
best-effort-nginx-3488455095-3go7n 1/1 Running 0 51s
best-effort-nginx-3488455095-9o2xg 1/1 Running 0 51s
best-effort-nginx-3488455095-eyg40 1/1 Running 0 51s
best-effort-nginx-3488455095-gcs3v 1/1 Running 0 51s
best-effort-nginx-3488455095-rq8p1 1/1 Running 0 51s
best-effort-nginx-3488455095-udhhd 1/1 Running 0 51s
best-effort-nginx-3488455095-zmk12 1/1 Running 0 51s
not-best-effort-nginx-2204666826-7sl61 1/1 Running 0 23s
not-best-effort-nginx-2204666826-ke746 1/1 Running 0 23s
你可以看到10个pod已经被允许创建。
让我们看看现在命名空间配额的使用情况：
$ kubectl describe quota --namespace=quota-scopes
Name: best-effort
Namespace: quota-scopes
Scopes: BestEffort
* Matches all pods that have best effort quality of service.
Resource Used Hard
-------- ---- ----
pods 8 10
Name: not-best-effort
Namespace: quota-scopes
Scopes: NotBestEffort
* Matches all pods that do not have best effort quality of service.
Resource Used Hard
-------- ---- ----
limits.cpu 400m 2
limits.memory 1Gi 2Gi
pods 2 4
requests.cpu 200m 1
requests.memory 512Mi 1Gi
可以看到，best-effort配额追踪创建best-effort-nginx deployment中8个pod的使用，并且not-best-effort配置追踪我们在配额里面创建的not-best-effort-nginx的使用情况。
scope提供了一种机制细分资源集合来追踪配额说明，以便在管理者部署和跟踪资源消耗方面提供更大的灵活性。
除了BestEffort和NotBestEffort范围，有一些范围限制长时运行与时间限制的pod。Terminating范围将匹配spec.activeDeadlineSeconds不为nil的任何pod。NotTerminating范围将匹配spec.activeDeadlineSeconds为nil的任何pod。这些范围允许你根据集群中节点上的预期的运行周期来限定pod。
总结
消耗节点cpu和内存资源的举措可能受命名空间定义的配额限制。
可以调整消耗这些资源的任何举措，或者可以选择默认命名空间级别的默认值来满足你的最终需求。
配额可以根据服务质量和集群节点上预期的持久性进行分配。
