美文网首页KubernetesKubernetes
Kubernetes 配置Pod和容器(五)应用资源配额和限制

Kubernetes 配置Pod和容器(五)应用资源配额和限制

作者: YiQinGuo | 来源:发表于2017-06-01 16:15 被阅读890次

    演示使用了下面的资源: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和内存资源的举措可能受命名空间定义的配额限制。

    可以调整消耗这些资源的任何举措,或者可以选择默认命名空间级别的默认值来满足你的最终需求。

    配额可以根据服务质量和集群节点上预期的持久性进行分配。

    相关文章

      网友评论

        本文标题:Kubernetes 配置Pod和容器(五)应用资源配额和限制

        本文链接:https://www.haomeiwen.com/subject/dpsefxtx.html