精华内容
下载资源
问答
  • 为namespace设置资源限制 1.资源的限制类型 Kubernetes采用request和limit两种限制类型来对资源进行分配。 • request(资源需求):即运行Pod的节点必须满足运行Pod的最基本需求才能 运行Pod。 • limit(资源限额):...

    1.资源的限制类型

    Kubernetes采用request和limit两种限制类型来对资源进行分配。
    • request(资源需求):即运行Pod的节点必须满足运行Pod的最基本需求才能 运行Pod。
    • limit(资源限额):即运行Pod期间,可能内存使用量会增加,那最多能使用多少内存,这就是资源限额。

    资源类型:
    • CPU 的单位是核心数,内存的单位是字节。
    • 一个容器申请0.5个CPU,就相当于申请1个CPU的一半,你也可以加个后缀 m 表示千分之一的概念。比如说100m的CPU,100豪的CPU和0.1个CPU都是一样的。

    内存单位:
    • K、M、G、T、P、E #通常是以1000为换算标准的。
    • Ki、Mi、Gi、Ti、Pi、Ei #通常是以1024为换算标准的。


    2. 内存限制

    [kubeadm@server1 ~]$ mkdir quota
    [kubeadm@server1 ~]$ cd quota/
    [kubeadm@server1 quota]$ vim demo.yml
    [kubeadm@server1 quota]$ cat demo.yml
    apiVersion: v1 
    kind: Pod 
    metadata:  
      name: memory-demo 
    spec:  
      containers:  
      - name: memory-demo    
        image: stress    
        args:    
        - --vm    
        - "1"    
        - --vm-bytes    
        - 200M    
        resources:      
          requests:        
            memory: 50Mi      
          limits:        
            memory: 100Mi
    [kubeadm@server1 quota]$ kubectl apply -f demo.yml 
    pod/memory-demo created
    [kubeadm@server1 quota]$ kubectl get pod
    NAME                                     READY   STATUS              RESTARTS   AGE
    memory-demo                              0/1     ContainerCreating   0          5s
    nfs-client-provisioner-96649cd96-pntbp   1/1     Running             1          26h
    [kubeadm@server1 quota]$ kubectl get pod
    NAME                                     READY   STATUS      RESTARTS   AGE
    memory-demo                              0/1     OOMKilled   2          33s
    nfs-client-provisioner-96649cd96-pntbp   1/1     Running     1          26h
    [kubeadm@server1 quota]$ kubectl describe pod memory-demo 
    Name:         memory-demo
    Namespace:    default
    Priority:     0
    Node:         server3/172.25.1.3
    Start Time:   Sat, 04 Jul 2020 22:43:14 +0800
    Labels:       <none>
    Annotations:  Status:  Running
    IP:           10.244.2.137
    IPs:
      IP:  10.244.2.137
    Containers:
      memory-demo:
        Container ID:  docker://d8745253bbf2a986d4a8bf7e1afd5aed1609e42601d4801d57feccb5424bcb21
        Image:         stress
        Image ID:      docker-pullable://stress@sha256:48a71454d405dbe1c756dd728cadeb577f429f61313ac62b413b52fbaa8a3b44
        Port:          <none>
        Host Port:     <none>
        Args:
          --vm
          1
          --vm-bytes
          200M
        State:          Waiting
          Reason:       CrashLoopBackOff
        Last State:     Terminated
          Reason:       OOMKilled
          Exit Code:    1
          Started:      Sat, 04 Jul 2020 22:44:51 +0800
          Finished:     Sat, 04 Jul 2020 22:44:51 +0800
        Ready:          False
        Restart Count:  4
        Limits:
          memory:  100Mi
        Requests:
          memory:     50Mi
        Environment:  <none>
        Mounts:
          /var/run/secrets/kubernetes.io/serviceaccount from default-token-5qqxc (ro)
    Conditions:
      Type              Status
      Initialized       True 
      Ready             False 
      ContainersReady   False 
      PodScheduled      True 
    Volumes:
      default-token-5qqxc:
        Type:        Secret (a volume populated by a Secret)
        SecretName:  default-token-5qqxc
        Optional:    false
    QoS Class:       Burstable
    Node-Selectors:  <none>
    Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                     node.kubernetes.io/unreachable:NoExecute for 300s
    Events:
      Type     Reason     Age                From               Message
      ----     ------     ----               ----               -------
      Normal   Scheduled  104s               default-scheduler  Successfully assigned default/memory-demo to server3
      Normal   Created    51s (x4 over 96s)  kubelet, server3   Created container memory-demo
      Normal   Started    51s (x4 over 96s)  kubelet, server3   Started container memory-demo
      Warning  BackOff    22s (x7 over 94s)  kubelet, server3   Back-off restarting failed container
      Normal   Pulling    7s (x5 over 103s)  kubelet, server3   Pulling image "stress"
      Normal   Pulled     7s (x5 over 96s)   kubelet, server3   Successfully pulled image "stress"
    [kubeadm@server1 quota]$ kubectl delete -f demo.yml 
    pod "memory-demo" deleted
    

    在这里插入图片描述
    在这里插入图片描述


    3. CPU限制

    [kubeadm@server1 quota]$ cat demo.yml 
    apiVersion: v1 
    kind: Pod 
    metadata:  
      name: memory-demo 
    spec:  
      containers:  
      - name: memory-demo    
        image: stress    
        args:    
        - -c    
        - "2"    
        resources:      
          requests:        
            cpu: 5      
          limits:        
            cpu: 10
    
    [kubeadm@server1 quota]$ kubectl apply -f demo.yml 
    pod/memory-demo created
    [kubeadm@server1 quota]$ kubectl get pod
    NAME                                     READY   STATUS              RESTARTS   AGE
    memory-demo                              0/1     Pending             0          3s
    nfs-client-provisioner-96649cd96-zprsg   0/1     ContainerCreating   0          10h
    [kubeadm@server1 quota]$ kubectl get pod
    NAME                                     READY   STATUS              RESTARTS   AGE
    memory-demo                              0/1     Pending             0          7s
    nfs-client-provisioner-96649cd96-zprsg   0/1     ContainerCreating   0          10h
    [kubeadm@server1 quota]$ kubectl describe pod memory-demo 
    Name:         memory-demo
    Namespace:    default
    Priority:     0
    Node:         <none>
    Labels:       <none>
    Annotations:  Status:  Pending
    IP:           
    IPs:          <none>
    Containers:
      memory-demo:
        Image:      stress
        Port:       <none>
        Host Port:  <none>
        Args:
          -c
          2
        Limits:
          cpu:  10
        Requests:
          cpu:        5
        Environment:  <none>
        Mounts:
          /var/run/secrets/kubernetes.io/serviceaccount from default-token-5qqxc (ro)
    Conditions:
      Type           Status
      PodScheduled   False 
    Volumes:
      default-token-5qqxc:
        Type:        Secret (a volume populated by a Secret)
        SecretName:  default-token-5qqxc
        Optional:    false
    QoS Class:       Burstable
    Node-Selectors:  <none>
    Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                     node.kubernetes.io/unreachable:NoExecute for 300s
    Events:
      Type     Reason            Age                From               Message
      ----     ------            ----               ----               -------
      Warning  FailedScheduling  16s (x2 over 16s)  default-scheduler  0/3 nodes are available: 3 Insufficient cpu.

    在这里插入图片描述在这里插入图片描述
    在这里插入图片描述
    调度失败是因为申请的CPU资源超出集群节点所能提供的资源 但CPU 使用率过高,不会被杀死


    [kubeadm@server1 quota]$ vim demo.yml 
    [kubeadm@server1 quota]$ cat demo.yml 
    apiVersion: v1 
    kind: Pod 
    metadata:  
      name: memory-demo 
    spec:  
      containers:  
      - name: memory-demo    
        image: stress    
        args:    
        - -c    
        - "1"    
        resources:      
          requests:        
            memory: 50Mi
            cpu: 1      
          limits:        
            memory: 300Mi
            cpu: 10
    [kubeadm@server1 quota]$ kubectl apply -f demo.yml 
    pod/memory-demo created
    [kubeadm@server1 quota]$ kubectl get pod
    NAME                                     READY   STATUS    RESTARTS   AGE
    memory-demo                              1/1     Running   0          3s
    
    [kubeadm@server1 quota]$ kubectl describe pod memory-demo 
    Name:         memory-demo
    Namespace:    default
    Priority:     0
    Node:         server3/172.25.1.3
    Start Time:   Sat, 04 Jul 2020 22:47:39 +0800
    Labels:       <none>
    Annotations:  Status:  Running
    IP:           10.244.2.138
    IPs:
      IP:  10.244.2.138
    Containers:
      memory-demo:
        Container ID:  docker://7487935a3be6f3b577786c33dc924e34b9f65644ac184886592bceeb5b6156d6
        Image:         stress
        Image ID:      docker-pullable://stress@sha256:48a71454d405dbe1c756dd728cadeb577f429f61313ac62b413b52fbaa8a3b44
        Port:          <none>
        Host Port:     <none>
        Args:
          -c
          1
        State:          Running
          Started:      Sat, 04 Jul 2020 22:47:40 +0800
        Ready:          True
        Restart Count:  0
        Limits:
          cpu:     10
          memory:  300Mi
        Requests:
          cpu:        1
          memory:     50Mi
        Environment:  <none>
        Mounts:
          /var/run/secrets/kubernetes.io/serviceaccount from default-token-5qqxc (ro)
    Conditions:
      Type              Status
      Initialized       True 
      Ready             True 
      ContainersReady   True 
      PodScheduled      True 
    Volumes:
      default-token-5qqxc:
        Type:        Secret (a volume populated by a Secret)
        SecretName:  default-token-5qqxc
        Optional:    false
    QoS Class:       Burstable
    Node-Selectors:  <none>
    Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                     node.kubernetes.io/unreachable:NoExecute for 300s
    Events:
      Type    Reason     Age   From               Message
      ----    ------     ----  ----               -------
      Normal  Scheduled  18s   default-scheduler  Successfully assigned default/memory-demo to server3
      Normal  Pulling    17s   kubelet, server3   Pulling image "stress"
      Normal  Pulled     17s   kubelet, server3   Successfully pulled image "stress"
      Normal  Created    17s   kubelet, server3   Created container memory-demo
      Normal  Started    17s   kubelet, server3   Started container memory-demo

    在这里插入图片描述
    在这里插入图片描述


    4. 为namespace设置资源限制

    [kubeadm@server1 quota]$ vim limits.yml
    [kubeadm@server1 quota]$ cat limits.yml
    apiVersion: v1 
    kind: LimitRange 
    metadata:  
      name: limitrange-memory 
    spec:  
      limits:  
      - default:      
          cpu: 0.5      
          memory: 512Mi    
        defaultRequest:      
          cpu: 0.1      
          memory: 256Mi    
        max:      
          cpu: 1      
          memory: 1Gi    
        min:      
          cpu: 0.1      
          memory: 100Mi    
        type: Container
    [kubeadm@server1 quota]$ kubectl apply -f limits.yml 
    limitrange/limitrange-memory created
    [kubeadm@server1 quota]$ kubectl get limitranges 
    NAME                CREATED AT
    limitrange-memory   2020-07-04T14:51:09Z
    [kubeadm@server1 quota]$ kubectl describe limitranges limitrange-memory 
    Name:       limitrange-memory
    Namespace:  default
    Type        Resource  Min    Max  Default Request  Default Limit  Max Limit/Request Ratio
    ----        --------  ---    ---  ---------------  -------------  -----------------------
    Container   cpu       100m   1    100m             500m           -
    Container   memory    100Mi  1Gi  256Mi            512Mi          -
    [kubeadm@server1 quota]$ kubectl apply -f demo.yml 
    Error from server (Forbidden): error when creating "demo.yml": pods "memory-demo" is forbidden: [minimum memory usage per Container is 100Mi, but request is 50Mi, maximum cpu usage per Container is 1, but limit is 10]
    [kubeadm@server1 quota]$ vim demo.yml 
    [kubeadm@server1 quota]$ cat demo.yml 
    apiVersion: v1 
    kind: Pod 
    metadata:  
      name: memory-demo 
    spec:  
      containers:  
      - name: memory-demo    
        image: myapp:v1    
        resources:      
          requests:        
            memory: 100Mi
            cpu: 0.2      
          limits:        
            memory: 300Mi
            cpu: 1
    [kubeadm@server1 quota]$ kubectl apply -f demo.yml 
    pod/memory-demo created
    [kubeadm@server1 quota]$ kubectl delete -f demo.yml 
    pod "memory-demo" deleted
    

    ==注意:LimitRange 在 namespace 中施加的最小和最大内存限制只有在创建和更新 Pod 时才会被应用。改变 LimitRange 不会对之前创建的 Pod 造成影响。 ==

    在这里插入图片描述在这里插入图片描述
    在这里插入图片描述

    在这里插入图片描述


    [kubeadm@server1 quota]$ vim demo.yml 
    [kubeadm@server1 quota]$ cat demo.yml 
    apiVersion: v1 
    kind: Pod 
    metadata:  
      name: memory-demo 
    spec:  
      containers:  
      - name: memory-demo    
        image: myapp:v1    
    [kubeadm@server1 quota]$ kubectl apply -f demo.yml 
    pod/memory-demo created
    [kubeadm@server1 quota]$ kubectl describe pod demo.yml 
    Error from server (NotFound): pods "demo.yml" not found
    [kubeadm@server1 quota]$ kubectl describe pod memory-demo 
    Name:         memory-demo
    Namespace:    default
    Priority:     0
    Node:         server3/172.25.1.3
    Start Time:   Sat, 04 Jul 2020 22:55:49 +0800
    Labels:       <none>
    Annotations:  kubernetes.io/limit-ranger:
                    LimitRanger plugin set: cpu, memory request for container memory-demo; cpu, memory limit for container memory-demo
    Status:       Running
    IP:           10.244.2.140
    IPs:
      IP:  10.244.2.140
    Containers:
      memory-demo:
        Container ID:   docker://70632378717f635ef59e376befa1d5925ac86c654b1feacc8ecea4ed25fe3428
        Image:          myapp:v1
        Image ID:       docker-pullable://myapp@sha256:9eeca44ba2d410e54fccc54cbe9c021802aa8b9836a0bcf3d3229354e4c8870e
        Port:           <none>
        Host Port:      <none>
        State:          Running
          Started:      Sat, 04 Jul 2020 22:55:50 +0800
        Ready:          True
        Restart Count:  0
        Limits:
          cpu:     500m
          memory:  512Mi
        Requests:
          cpu:        100m
          memory:     256Mi
        Environment:  <none>
        Mounts:
          /var/run/secrets/kubernetes.io/serviceaccount from default-token-5qqxc (ro)
    Conditions:
      Type              Status
      Initialized       True 
      Ready             True 
      ContainersReady   True 
      PodScheduled      True 
    Volumes:
      default-token-5qqxc:
        Type:        Secret (a volume populated by a Secret)
        SecretName:  default-token-5qqxc
        Optional:    false
    QoS Class:       Burstable
    Node-Selectors:  <none>
    Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                     node.kubernetes.io/unreachable:NoExecute for 300s
    Events:
      Type    Reason     Age   From               Message
      ----    ------     ----  ----               -------
      Normal  Scheduled  19s   default-scheduler  Successfully assigned default/memory-demo to server3
      Normal  Pulled     18s   kubelet, server3   Container image "myapp:v1" already present on machine
      Normal  Created    18s   kubelet, server3   Created container memory-demo
      Normal  Started    18s   kubelet, server3   Started container memory-demo
    

    在这里插入图片描述
    在这里插入图片描述


    5. 为namespace设置资源配额

    参考官网:https://kubernetes.io/zh/docs/concepts/policy/resource-quotas/
    当多个用户或团队共享具有固定节点数目的集群时,人们会担心有人使用超过其基于公平原则所分配到的资源量。资源配额是帮助管理员解决这一问题的工具。

    资源配额,通过 ResourceQuota 对象来定义,对每个命名空间的资源消耗总量提供限制。 它可以限制命名空间中某种类型的对象的总数目上限,也可以限制命令空间中的 Pod 可以使用的计算资源的总上限。

    资源配额的工作方式如下:
    不同的团队可以在不同的命名空间下工作,目前这是非约束性的,在未来的版本中可能会通过 ACL (Access Control List 访问控制列表) 来实现强制性约束。
    集群管理员可以为每个命名空间创建一个或多个资源配额对象。
    当用户在命名空间下创建资源(如 Pod、Service 等)时,Kubernetes 的配额系统会跟踪集群的资源使用情况,以确保使用的资源用量不超过资源配额中定义的硬性资源限额。
    如果资源创建或者更新请求违反了配额约束,那么该请求会报错(HTTP 403 FORBIDDEN),并在消息中给出有可能违反的约束。
    如果命名空间下的计算资源 (如 cpu 和 memory)的配额被启用,则用户必须为这些资源设定请求值(request)和约束值(limit),否则配额系统将拒绝 Pod 的创建。
    提示: 可使用 LimitRanger 准入控制器来为没有设置计算资源需求的 Pod 设置默认值。

    在这里插入图片描述更多示例可以参考https://kubernetes.io/docs/tasks/administer-cluster/quota-api-object/


    [kubeadm@server1 quota]$ kubectl get limitranges 
    NAME                CREATED AT
    limitrange-memory   2020-07-06T22:15:14Z
    [kubeadm@server1 quota]$ cat demo.yml 
    apiVersion: v1 
    kind: Pod 
    metadata:  
      name: memory-demo 
    spec:  
      containers:  
      - name: memory-demo    
        image: myapp:v1    
    [kubeadm@server1 quota]$ kubectl apply -f demo.yml 
    pod/memory-demo created
    [kubeadm@server1 quota]$ kubectl get pod
    NAME          READY   STATUS    RESTARTS   AGE
    memory-demo   1/1     Running   0          9s
    
    [kubeadm@server1 quota]$ cat quota.yml 
    apiVersion: v1 
    kind: ResourceQuota 
    metadata:  
      name: mem-cpu-demo 
    spec:  
      hard:    
        requests.cpu: "1"    
        requests.memory: 1Gi    
        limits.cpu: "2"    
        limits.memory: 2Gi
        pods: "2"
    [kubeadm@server1 quota]$ kubectl apply -f quota.yml 
    resourcequota/mem-cpu-demo created
    [kubeadm@server1 quota]$ kubectl describe resourcequotas 
    Name:            mem-cpu-demo
    Namespace:       default
    Resource         Used   Hard
    --------         ----   ----
    limits.cpu       500m   2
    limits.memory    512Mi  2Gi
    pods             1      2
    requests.cpu     100m   1
    requests.memory  256Mi  1Gi
    

    在这里插入图片描述在这里插入图片描述
    创建的ResourceQuota对象将在default名字空间中添加以下限制:
    • 每个容器必须设置内存请求(memory request),内存限额(memory limit),cpu请求(cpu request)和cpu限额(cpu limit)

    在这里插入图片描述

    [kubeadm@server1 quota]$ kubectl delete -f limits.yml 
    limitrange "limitrange-memory" deleted
    [kubeadm@server1 quota]$ kubectl delete -f demo.yml 
    pod "memory-demo" deleted
    [kubeadm@server1 quota]$ kubectl apply -f demo.yml 
    Error from server (Forbidden): error when creating "demo.yml": pods "memory-demo" is forbidden: failed quota: mem-cpu-demo: must specify limits.cpu,limits.memory,requests.cpu,requests.memory
    [kubeadm@server1 quota]$ kubectl describe resourcequotas 
    Name:            mem-cpu-demo
    Namespace:       default
    Resource         Used  Hard
    --------         ----  ----
    limits.cpu       0     2
    limits.memory    0     2Gi
    pods             0     2
    requests.cpu     0     1
    requests.memory  0     1Gi
    [kubeadm@server1 quota]$ vim demo.yml 
    [kubeadm@server1 quota]$ cat demo.yml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: memory-demo
    spec:
      containers:
      - name: memory-demo
        image: myapp:v1
        resources:
          requests:
            memory: 100Mi
            cpu: 0.2
          limits:
            memory: 300Mi
            cpu: 1
    [kubeadm@server1 quota]$ kubectl apply -f demo.yml 
    pod/memory-demo created
    [kubeadm@server1 quota]$ kubectl describe resourcequotas
    Name:            mem-cpu-demo
    Namespace:       default
    Resource         Used   Hard
    --------         ----   ----
    limits.cpu       1      2
    limits.memory    300Mi  2Gi
    requests.cpu     200m   1
    requests.memory  100Mi  1Gi
    
    

    在这里插入图片描述
    在这里插入图片描述


    为 Namespace 配置Pod配额:

    [kubeadm@server1 quota]$ vim quota.yml
    [kubeadm@server1 quota]$ cat quota.yml
    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: mem-cpu-demo
    spec:
      hard:
        requests.cpu: "1"
        requests.memory: 1Gi
        limits.cpu: "2"
        limits.memory: 2Gi
        pods: "2"
    [kubeadm@server1 quota]$ kubectl apply -f quota.yml
    resourcequota/mem-cpu-demo configured
    [kubeadm@server1 quota]$ kubectl describe resourcequotas 
    Name:            mem-cpu-demo
    Namespace:       default
    Resource         Used   Hard
    --------         ----   ----
    limits.cpu       1      2
    limits.memory    300Mi  2Gi
    pods             1      2
    requests.cpu     200m   1
    requests.memory  100Mi  1Gi
    [kubeadm@server1 quota]$ kubectl apply -f limits.yml 
    limitrange/limitrange-memory created
    [kubeadm@server1 quota]$ kubectl get limitranges 
    NAME                CREATED AT
    limitrange-memory   2020-07-06T22:34:34Z
    [kubeadm@server1 quota]$ kubectl run demo-1 --image=myapp:v1
    pod/demo-1 created
    [kubeadm@server1 quota]$ kubectl get pod
    NAME          READY   STATUS    RESTARTS   AGE
    demo-1        1/1     Running   0          4s
    memory-demo   1/1     Running   0          7m26s
    [kubeadm@server1 quota]$ kubectl run demo-2 --image=myapp:v1
    Error from server (Forbidden): pods "demo-2" is forbidden: exceeded quota: mem-cpu-demo, requested: pods=1, used: pods=2, limited: pods=2
    [kubeadm@server1 quota]$ kubectl delete pod demo-1 
    pod "demo-1" deleted
    [kubeadm@server1 quota]$ kubectl delete -f .
    pod "memory-demo" deleted
    limitrange "limitrange-memory" deleted
    resourcequota "mem-cpu-demo" deleted
    
    

    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述

    展开全文
  • kubernetes 容器资源限制 namespace资源限制一、容器资源限制二、namespace资源限制为namespace设置资源限制为namespace设置资源配额为 Namespace 配置Pod配额 一、容器资源限制 Kubernetes采用request和limit两种...

    一、容器资源限制

    Kubernetes采用requestlimit两种限制类型来对资源进行分配。

    • request(资源需求):即运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod。
    • limit(资源限额):即运行Pod期间,可能内存使用量会增加,那最多能使用多少内存,这就是资源限额。

    资源类型:

    • CPU 的单位是核心数,内存的单位是字节。
    • 一个容器申请0.5个CPU,就相当于申请1个CPU的一半,你也可以加个后缀m表示千分之一的概念。比如说100m的CPU,100豪的CPU和0.1个CPU都是一样的。

    内存单位:

    K、M、G、T、P、E 	        #通常是以1000为换算标准的。
    Ki、Mi、Gi、Ti、Pi、Ei        #通常是以1024为换算标准的
    

    1.内存限制示例:

    [root@server1 ~]# mkdir limit
    [root@server1 ~]# cd limit
    [root@server1 limit]# vim pod.yaml 
    [root@server1 limit]# cat pod.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: memory-demo
    spec:
      containers:
      - name: memory-demo
        image: stress
        args:
        - --vm
        - "1"
        - --vm-bytes
        - 200M
        resources:
          requests:
            memory: 50Mi
          limits:
            memory: 100Mi
    

    上述部署文件表示容器最小需要50Mi的内存,但是最多使用100Mi的内存,该容器的镜像使用stress消耗200Mi的内存,我们运行这个pod来查看状态:

    [root@server1 limit]# kubectl apply -f pod.yaml 
    pod/memory-demo created
    [root@server1 limit]# kubectl get pod -o wide
    NAME                                      READY   STATUS      RESTARTS   AGE   IP             NODE      NOMINATED NODE   READINESS GATES
    memory-demo                               0/1     OOMKilled   0          33s   10.244.1.109   server2   <none>           <none>
    nfs-client-provisioner-6b66ddf664-2qf7m   1/1     Running     0          27m   10.244.2.98    server3   <none>           <none>
    [root@server1 limit]# kubectl get pod -o wide
    NAME                                      READY   STATUS             RESTARTS   AGE   IP             NODE      NOMINATED NODE   READINESS GATES
    memory-demo                               0/1     CrashLoopBackOff   2          51s   10.244.1.109   server2   <none>           <none>
    nfs-client-provisioner-6b66ddf664-2qf7m   1/1     Running            0          28m   10.244.2.98    server3   <none>           <none>
    

    在这里插入图片描述
    可以看出容器的状态为OOMKilled,之后变为CrashLoopBackOff,说明如果容器超过其内存限制,则会被终止。如果可重新启动,则与所有其他类型的运行时故障一样,kubelet 将重新启动它。

    如果一个容器超过其内存请求,那么当节点内存不足时,它的 Pod 可能被逐出。

    实验后删除:

    [root@server1 limit]# kubectl delete -f pod.yaml 
    pod "memory-demo" deleted
    

    而当我们将容器的资源限制提升到300Mi后该pod可以正常运行:
    在这里插入图片描述

    2.CPU限制示例

    [root@server1 limit]# vim pod1.yaml 
    [root@server1 limit]# cat pod1.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: cpu-demo
    spec:
      containers:
      - name: cpu-demo
        image: stress
        resources:
          limits:
            cpu: "10"
          requests:
            cpu: "5"
        args:
        - -c
        - "2"
    

    该部署文件表示该容器运行至少需要5个cpu,最大的限制为10个cpu,而我们主机只有2个cpu,因此运行该pod会出现pending的状态:

    [root@server1 limit]# kubectl apply -f pod1.yaml 
    pod/cpu-demo created
    [root@server1 limit]# kubectl get pod
    NAME                                      READY   STATUS    RESTARTS   AGE
    cpu-demo                                  0/1     Pending   0          4s
    nfs-client-provisioner-6b66ddf664-2qf7m   1/1     Running   0          36m
    [root@server1 limit]# kubectl get pod
    NAME                                      READY   STATUS    RESTARTS   AGE
    cpu-demo                                  0/1     Pending   0          5s
    nfs-client-provisioner-6b66ddf664-2qf7m   1/1     Running   0          36m
    [root@server1 limit]# kubectl get pod
    NAME                                      READY   STATUS    RESTARTS   AGE
    cpu-demo                                  0/1     Pending   0          6s
    nfs-client-provisioner-6b66ddf664-2qf7m   1/1     Running   0          36m
    

    我们使用以下命令查看pod的详细信息:

    [root@server1 limit]# kubectl describe pod cpu-demo 
    

    在这里插入图片描述可以看出调度失败的错误,调度失败的原因是申请的CPU资源超出集群节点所能提供的资源。

    但CPU 使用率过高,不会被杀死

    删除该pod:

    [root@server1 limit]# kubectl delete -f pod1.yaml 
    pod "cpu-demo" deleted
    

    当我们将cpu限制设置为最少0.5个最大2个cpu时pod就可以正常运行:

    在这里插入图片描述

    二、namespace资源限制

    为namespace设置资源限制

    [root@server1 limit]# vim limitrange.yaml 
    [root@server1 limit]# cat limitrange.yaml 
    apiVersion: v1
    kind: LimitRange
    metadata:
      name: limitrange-memory
    spec:
      limits:
      - default:
          cpu: 0.5
          memory: 512Mi
        defaultRequest:
          cpu: 0.1
          memory: 256Mi
        max:
          cpu: 1
          memory: 800Mi
        min:
          cpu: 0.1
          memory: 100Mi
        type: Container
    

    上述部署文件的default字段和defaultRequest字段表示在默认(没有指定namespace所以是默认)的namespace中创建的pod如果没有指定资源限制,那么就将这两个字段作为pod的资源限制。

    而pod指定了限制时,也不可以超过max字段定义的1个cpu和800Mi内存的限制,也不能低于0.1个cpu和100Mi的内存。

    运行该部署文件:

    [root@server1 limit]# kubectl apply -f limitrange.yaml 
    limitrange/limitrange-memory created
    

    可以使用以下命令查看namespace资源限制:

    [root@server1 limit]# kubectl get limitranges 
    NAME                CREATED AT
    limitrange-memory   2020-05-08T18:20:12Z
    [root@server1 limit]# kubectl describe limitranges 
    Name:       limitrange-memory
    Namespace:  default
    Type        Resource  Min    Max    Default Request  Default Limit  Max Limit/Request Ratio
    ----        --------  ---    ---    ---------------  -------------  -----------------------
    Container   cpu       100m   1      100m             500m           -
    Container   memory    100Mi  800Mi  256Mi            512Mi          -
    

    设置的限制都可以查看到。

    需要注意的是:LimitRange 在 namespace 中施加的最小和最大内存限制只有在创建和更新 Pod 时才会被应用。改变 LimitRange 不会对之前创建的 Pod 造成影响。

    实验后删除限制:

    [root@server1 limit]# kubectl delete -f limitrange.yaml 
    limitrange "limitrange-memory" deleted
    

    为namespace设置资源配额

    这个配额定义的是该namespace中所有pod资源的总和上限

    [root@server1 limit]# vim quota.ayml
    [root@server1 limit]# \vi quota.ayml 
    [root@server1 limit]# cat quota.ayml 
    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: mem-cpu-demo
    spec:
      hard:
        requests.cpu: "1"
        requests.memory: 1Gi
        limits.cpu: "2"
        limits.memory: 2Gi
    

    创建的ResourceQuota对象将在default名字空间中添加以下限制:

    • 每个容器必须设置内存请求(memory request),内存限额(memory limit),cpu请求(cpu request)和cpu限额(cpu limit)。
    • 所有容器的内存请求总额不得超过1 GiB。
    • 所有容器的内存限额总额不得超过2 GiB。
    • 所有容器的CPU请求总额不得超过1 CPU。
    • 所有容器的CPU限额总额不得超过2 CPU。

    创建后查看设置的配额:

    [root@server1 limit]# kubectl create -f quota.ayml 
    resourcequota/mem-cpu-demo created
    [root@server1 limit]# kubectl describe resourcequotas 
    Name:            mem-cpu-demo
    Namespace:       default
    Resource         Used  Hard
    --------         ----  ----
    limits.cpu       0     2
    limits.memory    0     2Gi
    requests.cpu     0     1
    requests.memory  0     1Gi
    

    可以看出没有以使用的资源,同时需要注意的是我们创建pod时必须指定所有的资源限制(memory request,memory limit,cpu request和cpu limit),否则将会不能创建:

    [root@server1 limit]# vim pod.yaml 
    [root@server1 limit]# cat pod.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: memory-demo
    spec:
      containers:
      - name: memory-demo
        image: nginx
    
    [root@server1 limit]# kubectl apply -f pod.yaml 
    Error from server (Forbidden): error when creating "pod.yaml": pods "memory-demo" is forbidden: failed quota: mem-cpu-demo: must specify limits.cpu,limits.memory,requests.cpu,requests.memory
    

    可以看出创建时提示forbidden,并且提醒我们设置资源限制。

    当我们设置了资源限制后创建时:

    [root@server1 limit]# vim pod1.yaml 
    [root@server1 limit]# cat pod1.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: cpu-demo
    spec:
      containers:
      - name: cpu-demo
        image: nginx
        resources:
          limits:
            cpu: "1"
            memory: 512Mi
          requests:
            cpu: "0.5"
            memory: 256Mi
    
    [root@server1 limit]# kubectl apply -f pod1.yaml 
    pod/cpu-demo configured
    [root@server1 limit]# kubectl get pod
    NAME                                      READY   STATUS    RESTARTS   AGE
    cpu-demo                                  1/1     Running   3          44s
    nfs-client-provisioner-6b66ddf664-2qf7m   1/1     Running   0          61m
    

    可以成功创建,此时我们再查看配额情况:

    [root@server1 limit]# kubectl describe resourcequotas 
    Name:            mem-cpu-demo
    Namespace:       default
    Resource         Used   Hard
    --------         ----   ----
    limits.cpu       1      2
    limits.memory    512Mi  2Gi
    requests.cpu     500m   1
    requests.memory  256Mi  1Gi
    

    可以看出在Used那一列正是我们在pod中设置的资源限制,再次创建pod将会在这一列上累加,但是不能超过配额,即Hard那一列。

    实验后删除:

    [root@server1 limit]# kubectl delete -f quota.ayml
    resourcequota "mem-cpu-demo" deleted
    

    为 Namespace 配置Pod配额

    [root@server1 limit]# vim limitpod.yaml 
    [root@server1 limit]# cat limitpod.yaml 
    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: pod-demo
    spec:
      hard:
        pods: "2"
    

    设置Pod配额以限制可以在namespace中运行的Pod数量。 上述部署文件表示在默认的namespace上最多只能运行2个pod。

    创建pod配额:

    [root@server1 limit]# kubectl apply -f limitpod.yaml 
    resourcequota/pod-demo created
    

    可以使用以下命令查看设置的配额:

    [root@server1 limit]# kubectl get resourcequotas 
    NAME           AGE   REQUEST                                            LIMIT
    mem-cpu-demo   19m   requests.cpu: 500m/1, requests.memory: 256Mi/1Gi   limits.cpu: 1/2, limits.memory: 512Mi/2Gi
    pod-demo       12s   pods: 2/2     
    [root@server1 limit]# kubectl describe resourcequotas pod-demo 
    Name:       pod-demo
    Namespace:  default
    Resource    Used  Hard
    --------    ----  ----
    pods        2     2
    

    可以看出配额已经全部使用完,此时我们再创建pod:

    [root@server1 limit]# vim pod1.yaml 
    [root@server1 limit]# cat pod1.yaml 
    apiVersion: v1
    kind: Pod
    metadata:
      name: cpu-demo-1
    spec:
      containers:
      - name: cpu-demo
        image: nginx
        resources:
          limits:
            cpu: "1"
            memory: 512Mi
          requests:
            cpu: "0.5"
            memory: 256Mi
    
    [root@server1 limit]# kubectl apply -f pod1.yaml 
    Error from server (Forbidden): error when creating "pod1.yaml": pods "cpu-demo-1" is forbidden: exceeded quota: pod-demo, requested: pods=1, used: pods=2, limited: pods=2
    

    创建失败,提示原因是pod数量超出配额。

    接下来我们创建一个namespace test:

    [root@server1 limit]# kubectl create namespace test
    namespace/test created
    [root@server1 limit]# kubectl get namespaces 
    NAME              STATUS   AGE
    default           Active   21d
    ingress-nginx     Active   17d
    kube-node-lease   Active   21d
    kube-public       Active   21d
    kube-system       Active   21d
    test              Active   6s
    

    将pod运行在新的namespace即可:

    [root@server1 limit]# kubectl apply -f pod1.yaml -n test
    pod/cpu-demo-1 created
    nfs-client-provisioner-6b66ddf664-2qf7m   1/1     Running   0          67m
    [root@server1 limit]# kubectl get pod -n test
    NAME         READY   STATUS    RESTARTS   AGE
    cpu-demo-1   1/1     Running   0          14s
    

    实验后删除设置的配额以及运行的pod:

    [root@server1 limit]# kubectl delete namespaces test
    namespace "test" deleted
    [root@server1 limit]# kubectl delete -f limitpod.yaml 
    resourcequota "pod-demo" deleted
    [root@server1 limit]# kubectl delete -f quota.ayml
    resourcequota "mem-cpu-demo" deleted
    [root@server1 limit]# kubectl get pod
    NAME                                      READY   STATUS    RESTARTS   AGE
    cpu-demo                                  1/1     Running   3          7m29s
    nfs-client-provisioner-6b66ddf664-2qf7m   1/1     Running   0          68m
    [root@server1 limit]# kubectl delete pod cpu-demo 
    pod "cpu-demo" deleted
    
    展开全文
  • 如果未对该Pod进行资源限制的话,可能会影响其他的Pod。 k8s常见的资源管理方式:计算资源管理(Compute Resources)、资源的配置范围管理(LimitRange)和资源的配额管理(Resource Quotas) 计算资源管理(Compute ...

    简介

    在k8s集群中为了能够使系统正常稳定运行,通常会限制Pod的资源使用情况,在k8s集群中如果有一个程序出现异常,并占用大量的系统资源。如果未对该Pod进行资源限制的话,可能会影响其他的Pod。

    k8s常见的资源管理方式:计算资源管理(Compute Resources)、资源的配置范围管理(LimitRange)和资源的配额管理(Resource Quotas)

     

    计算资源管理(Compute Resources): 为Pod中的容器指定使用的计算资源(CPU和内存)。

     

    资源的配置范围管理(LimitRange):可以对集群内Request和Limits的配置做一个全局的统一的限制,相当于批量设置了某一个范围内(某个命名空间)的Pod的资源使用限制。

     

    资源的配额管理(Resource Quotas):可以为每一个命名空间(namespace)提供一个总体的资源使用限制,通过它可以限制命名空间中某个类型的对象的总数目上限,也可以设置命名空间中Pod可以使用到的计算资源的总上限。资源的配额管理有效解决了多用户或多个团队公用一个k8s集群时资源有效分配的问题。

     

     

    本篇主要总结 资源的配额管理(Resource Quotas)的使用

     

    资源配额,通过 ResourceQuota 对象来定义,对每个命名空间的资源消耗总量提供限制。 它可以限制命名空间中某种类型的对象的总数目上限,也可以限制命令空间中的 Pod 可以使用的计算资源的总上限。

    资源配额的工作方式如下:

    • 不同的团队可以在不同的命名空间下工作,目前这是非约束性的,在未来的版本中可能会通过 ACL (Access Control List 访问控制列表) 来实现强制性约束。

    • 集群管理员可以为每个命名空间创建一个或多个资源配额对象。

    • 当用户在命名空间下创建资源(如 Pod、Service 等)时,Kubernetes 的配额系统会 跟踪集群的资源使用情况,以确保使用的资源用量不超过资源配额中定义的硬性资源限额。

    • 如果资源创建或者更新请求违反了配额约束,那么该请求会报错(HTTP 403 FORBIDDEN), 并在消息中给出有可能违反的约束。

    • 如果命名空间下的计算资源 (如 cpumemory)的配额被启用,则用户必须为 这些资源设定请求值(request)和约束值(limit),否则配额系统将拒绝 Pod 的创建。 提示: 可使用 LimitRanger 准入控制器来为没有设置计算资源需求的 Pod 设置默认值。

       

    ResourceQuota 对象的名称必须时合法的 DNS 子域名

    下面是使用命名空间和配额构建策略的示例:

    • 在具有 32 GiB 内存和 16 核 CPU 资源的集群中,允许 A 团队使用 20 GiB 内存 和 10 核的 CPU 资源, 允许 B 团队使用 10 GiB 内存和 4 核的 CPU 资源,并且预留 2 GiB 内存和 2 核的 CPU 资源供将来分配。

    • 限制 "testing" 命名空间使用 1 核 CPU 资源和 1GiB 内存。允许 "production" 命名空间使用任意数量。

    在集群容量小于各命名空间配额总和的情况下,可能存在资源竞争。资源竞争时,Kubernetes 系统会遵循先到先得的原则。

    不管是资源竞争还是配额的修改,都不会影响已经创建的资源使用对象。

    启用资源配额

    资源配额的支持在很多 Kubernetes 版本中是默认开启的。当 apiserver --enable-admission-plugins= 参数中包含 ResourceQuota 时,资源配额会被启用。

    当命名空间中存在一个 ResourceQuota 对象时,对于该命名空间而言,资源配额就是开启的。

    计算资源配额

    用户可以对给定命名空间下的可被请求的 计算资源 总量进行限制。

    配额机制所支持的资源类型:

    资源名称描述
    limits.cpu所有非终止状态的 Pod,其 CPU 限额总量不能超过该值。
    limits.memory所有非终止状态的 Pod,其内存限额总量不能超过该值。
    requests.cpu所有非终止状态的 Pod,其 CPU 需求总量不能超过该值。
    requests.memory所有非终止状态的 Pod,其内存需求总量不能超过该值。

    扩展资源的资源配额

    除上述资源外,在 Kubernetes 1.10 版本中,还添加了对 扩展资源 的支持。

    由于扩展资源不可超量分配,因此没有必要在配额中为同一扩展资源同时指定 requestslimits。 对于扩展资源而言,目前仅允许使用前缀为 requests. 的配额项。

    以 GPU 拓展资源为例,如果资源名称为 nvidia.com/gpu,并且要将命名空间中请求的 GPU 资源总数限制为 4,则可以如下定义配额:

    • requests.nvidia.com/gpu: 4

    有关更多详细信息,请参阅查看和设置配额

    存储资源配额

    用户可以对给定命名空间下的存储资源总量进行限制。

    此外,还可以根据相关的存储类(Storage Class)来限制存储资源的消耗。

    资源名称描述
    requests.storage所有 PVC,存储资源的需求总量不能超过该值。
    persistentvolumeclaims在该命名空间中所允许的 PVC 总量。
    <storage-class-name>.storageclass.storage.k8s.io/requests.storage在所有与 storage-class-name 相关的持久卷声明中,存储请求的总和不能超过该值。
    <storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims在与 storage-class-name 相关的所有持久卷声明中,命名空间中可以存在的持久卷申领总数。

    例如,如果一个操作人员针对 gold 存储类型与 bronze 存储类型设置配额,操作人员可以定义如下配额:

    • gold.storageclass.storage.k8s.io/requests.storage: 500Gi

    • bronze.storageclass.storage.k8s.io/requests.storage: 100Gi

    在 Kubernetes 1.8 版本中,本地临时存储的配额支持已经是 Alpha 功能:

    资源名称描述
    requests.ephemeral-storage在命名空间的所有 Pod 中,本地临时存储请求的总和不能超过此值。
    limits.ephemeral-storage在命名空间的所有 Pod 中,本地临时存储限制值的总和不能超过此值。

    对象数量配额

    Kubernetes 1.9 版本增加了使用以下语法对所有标准的、命名空间域的资源类型进行配额设置的支持。

    • count/<resource>.<group>

    这是用户可能希望利用对象计数配额来管理的一组资源示例。

    • count/persistentvolumeclaims

    • count/services

    • count/secrets

    • count/configmaps

    • count/replicationcontrollers

    • count/deployments.apps

    • count/replicasets.apps

    • count/statefulsets.apps

    • count/jobs.batch

    • count/cronjobs.batch

    • count/deployments.extensions

    Kubernetes 1.15 版本增加了对使用相同语法来约束自定义资源的支持。 例如,要对 example.com API 组中的自定义资源 widgets 设置配额,请使用 count/widgets.example.com

    当使用 count/* 资源配额时,如果对象存在于服务器存储中,则会根据配额管理资源。 这些类型的配额有助于防止存储资源耗尽。例如,用户可能想根据服务器的存储能力来对服务器中 Secret 的数量进行配额限制。集群中存在过多的 Secret 实际上会导致服务器和控制器无法启动!用户可以选择对 Job 进行配额管理,以防止配置不当的 CronJob 在某命名空间中创建太多作业而导致集群拒绝服务。

    在 Kubernetes 1.9 版本之前,可以在有限的一组资源上实施一般性的对象数量配额。 此外,还可以进一步按资源的类型设置其配额。

    支持以下类型:

    资源名称描述
    configmaps在该命名空间中允许存在的 ConfigMap 总数上限。
    persistentvolumeclaims在该命名空间中允许存在的 PVC 的总数上限。
    pods在该命名空间中允许存在的非终止状态的 pod 总数上限。Pod 终止状态等价于 Pod 的 .status.phase in (Failed, Succeeded) = true
    replicationcontrollers在该命名空间中允许存在的 RC 总数上限。
    resourcequotas在该命名空间中允许存在的资源配额总数上限。
    services在该命名空间中允许存在的 Service 总数上限。
    services.loadbalancers在该命名空间中允许存在的 LoadBalancer 类型的服务总数上限。
    services.nodeports在该命名空间中允许存在的 NodePort 类型的服务总数上限。
    secrets在该命名空间中允许存在的 Secret 总数上限。

    例如,pods 配额统计某个命名空间中所创建的、非终止状态的 Pod 个数并确保其不超过某上限值。 用户可能希望在某命名空间中设置 pods 配额,以避免有用户创建很多小的 Pod,从而耗尽集群所能提供的 Pod IP 地址。

    配额作用域

    每个配额都有一组相关的作用域(scope),配额只会对作用域内的资源生效。 配额机制仅统计所列举的作用域的交集中的资源用量。

    当一个作用域被添加到配额中后,它会对作用域相关的资源数量作限制。 如配额中指定了允许(作用域)集合之外的资源,会导致验证错误。

    作用域描述
    Terminating匹配所有 spec.activeDeadlineSeconds 不小于 0 的 Pod。
    NotTerminating匹配所有 spec.activeDeadlineSeconds 是 nil 的 Pod。
    BestEffort匹配所有 Qos 是 BestEffort 的 Pod。
    NotBestEffort匹配所有 Qos 不是 BestEffort 的 Pod。
    BestEffort` 作用域限制配额跟踪以下资源:`pods

    TerminatingNotTerminatingNotBestEffort 这三种作用域限制配额跟踪以下资源:

    • cpu

    • limits.cpu

    • limits.memory

    • memory

    • pods

    • requests.cpu

    • requests.memory

    基于优先级类(PriorityClass)来设置资源配额

    FEATURE STATE: Kubernetes 1.12 [beta]

    Pod 可以创建为特定的优先级。 通过使用配额规约中的 scopeSelector 字段,用户可以根据 Pod 的优先级控制其系统资源消耗。

    仅当配额规范中的 scopeSelector 字段选择到某 Pod 时,配额机制才会匹配和计量 Pod 的资源消耗。

    本示例创建一个配额对象,并将其与具有特定优先级的 Pod 进行匹配。 该示例的工作方式如下:

    • 集群中的 Pod 可取三个优先级类之一,即 "low"、"medium"、"high"。

    • 为每个优先级创建一个配额对象。

    将以下 YAML 保存到文件 quota.yml 中。

    apiVersion: v1
    kind: List
    items:
    - apiVersion: v1
      kind: ResourceQuota
      metadata:
        name: pods-high
      spec:
        hard:
          cpu: "1000"
          memory: 200Gi
          pods: "10"
        scopeSelector:
          matchExpressions:
          - operator : In
            scopeName: PriorityClass
            values: ["high"]
    - apiVersion: v1
      kind: ResourceQuota
      metadata:
        name: pods-medium
      spec:
        hard:
          cpu: "10"
          memory: 20Gi
          pods: "10"
        scopeSelector:
          matchExpressions:
          - operator : In
            scopeName: PriorityClass
            values: ["medium"]
    - apiVersion: v1
      kind: ResourceQuota
      metadata:
        name: pods-low
      spec:
        hard:
          cpu: "5"
          memory: 10Gi
          pods: "10"
        scopeSelector:
          matchExpressions:
          - operator : In
            scopeName: PriorityClass
            values: ["low"]

    使用 kubectl create 命令运行以下操作。

    kubectl create -f ./quota.yml
    resourcequota/pods-high created
    resourcequota/pods-medium created
    resourcequota/pods-low created

    使用 kubectl describe quota 操作验证配额的 Used 值为 0

    kubectl describe quota
    Name:       pods-high
    Namespace:  default
    Resource    Used  Hard
    --------    ----  ----
    cpu         0     1k
    memory      0     200Gi
    pods        0     10
    ​
    ​
    Name:       pods-low
    Namespace:  default
    Resource    Used  Hard
    --------    ----  ----
    cpu         0     5
    memory      0     10Gi
    pods        0     10
    ​
    ​
    Name:       pods-medium
    Namespace:  default
    Resource    Used  Hard
    --------    ----  ----
    cpu         0     10
    memory      0     20Gi
    pods        0     10

    创建优先级为 "high" 的 Pod。 将以下 YAML 保存到文件 high-priority-pod.yml 中。

    apiVersion: v1
    kind: Pod
    metadata:
      name: high-priority
    spec:
      containers:
      - name: high-priority
        image: ubuntu
        command: ["/bin/sh"]
        args: ["-c", "while true; do echo hello; sleep 10;done"]
        resources:
          requests:
            memory: "10Gi"
            cpu: "500m"
          limits:
            memory: "10Gi"
            cpu: "500m"
      priorityClassName: high

    使用 kubectl create 运行以下操作。

    kubectl create -f ./high-priority-pod.yml

    确认 "high" 优先级配额 pods-high 的 "Used" 统计信息已更改,并且其他两个配额未更改。

    kubectl describe quota
    Name:       pods-high
    Namespace:  default
    Resource    Used  Hard
    --------    ----  ----
    cpu         500m  1k
    memory      10Gi  200Gi
    pods        1     10
    ​
    ​
    Name:       pods-low
    Namespace:  default
    Resource    Used  Hard
    --------    ----  ----
    cpu         0     5
    memory      0     10Gi
    pods        0     10
    ​
    ​
    Name:       pods-medium
    Namespace:  default
    Resource    Used  Hard
    --------    ----  ----
    cpu         0     10
    memory      0     20Gi
    pods        0     10

    scopeSelectoroperator 字段中支持以下值:

    • In

    • NotIn

    • Exist

    • DoesNotExist

    请求与限制

    分配计算资源时,每个容器可以为 CPU 或内存指定请求和约束。 配额可以针对二者之一进行设置。

    如果配额中指定了 requests.cpurequests.memory 的值,则它要求每个容器都显式给出对这些资源的请求。 同理,如果配额中指定了 limits.cpulimits.memory 的值,那么它要求每个容器都显式设定对应资源的限制。

    查看和设置配额

    Kubectl 支持创建、更新和查看配额:

    kubectl create namespace myspace
    cat <<EOF > compute-resources.yaml
    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: compute-resources
    spec:
      hard:
        requests.cpu: "1"
        requests.memory: 1Gi
        limits.cpu: "2"
        limits.memory: 2Gi
        requests.nvidia.com/gpu: 4
    EOF
    kubectl create -f ./compute-resources.yaml --namespace=myspace
    cat <<EOF > object-counts.yaml
    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: object-counts
    spec:
      hard:
        configmaps: "10"
        persistentvolumeclaims: "4"
        pods: "4"
        replicationcontrollers: "20"
        secrets: "10"
        services: "10"
        services.loadbalancers: "2"
    EOF
    kubectl create -f ./object-counts.yaml --namespace=myspace
    kubectl get quota --namespace=myspace
    NAME                    AGE
    compute-resources       30s
    object-counts           32s
    kubectl describe quota compute-resources --namespace=myspace
    Name:                    compute-resources
    Namespace:               myspace
    Resource                 Used  Hard
    --------                 ----  ----
    limits.cpu               0     2
    limits.memory            0     2Gi
    requests.cpu             0     1
    requests.memory          0     1Gi
    requests.nvidia.com/gpu  0     4
    kubectl describe quota object-counts --namespace=myspace
    Name:                   object-counts
    Namespace:              myspace
    Resource                Used    Hard
    --------                ----    ----
    configmaps              0       10
    persistentvolumeclaims  0       4
    pods                    0       4
    replicationcontrollers  0       20
    secrets                 1       10
    services                0       10
    services.loadbalancers  0       2

    kubectl 还使用语法 count/<resource>.<group> 支持所有标准的、命名空间域的资源的对象计数配额:

    kubectl create namespace myspace
    kubectl create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4 --namespace=myspace
    kubectl create deployment nginx --image=nginx --namespace=myspace
    kubectl describe quota --namespace=myspace
    Name:                         test
    Namespace:                    myspace
    Resource                      Used  Hard
    --------                      ----  ----
    count/deployments.extensions  1     2
    count/pods                    2     3
    count/replicasets.extensions  1     4
    count/secrets                 1     4

    配额和集群容量

    资源配额与集群资源总量是完全独立的。它们通过绝对的单位来配置。 所以,为集群添加节点时,资源配额不会自动赋予每个命名空间消耗更多资源的能力。

    有时可能需要资源配额支持更复杂的策略,比如:

    • 在几个团队中按比例划分总的集群资源。

    • 允许每个租户根据需要增加资源使用量,但要有足够的限制以防止资源意外耗尽。

    • 探测某个命名空间的需求,添加物理节点并扩大资源配额值。

    这些策略可以通过将资源配额作为一个组成模块、手动编写一个控制器来监控资源使用情况, 并结合其他信号调整命名空间上的硬性资源配额来实现。

    注意:资源配额对集群资源总体进行划分,但它对节点没有限制:来自不同命名空间的 Pod 可能在同一节点上运行。

    默认情况下限制特定优先级的资源消耗

    有时候可能希望当且仅当某名字空间中存在匹配的配额对象时,才可以创建特定优先级 (例如 "cluster-services")的 Pod。

    通过这种机制,操作人员能够将限制某些高优先级类仅出现在有限数量的命名空间中, 而并非每个命名空间默认情况下都能够使用这些优先级类。

    要实现此目的,应使用 kube-apiserver 标志 --admission-control-config-file 传递如下配置文件的路径:

    apiVersion: apiserver.config.k8s.io/v1
    kind: AdmissionConfiguration
    plugins:
    - name: "ResourceQuota"
      configuration:
        apiVersion: apiserver.config.k8s.io/v1
        kind: ResourceQuotaConfiguration
        limitedResources:
        - resource: pods
          matchScopes:
          - scopeName: PriorityClass
            operator: In
            values: ["cluster-services"]

    现在,仅当命名空间中存在匹配的 scopeSelector 的配额对象时,才允许使用 "cluster-services" Pod。

    示例:

        scopeSelector:
          matchExpressions:
          - scopeName: PriorityClass
            operator: In
            values: ["cluster-services"]

     

     

    以上内容主要摘自k8s官方文档:https://kubernetes.io/zh/docs/concepts/policy/resource-quotas/

     

    展开全文
  • 一次搞明白 Docker 容器资源限制

    千次阅读 2020-10-16 00:00:00
    Docker核心 Docker分别使用Namespace和CGroup实现了对容器的资源隔离和资源限制,本文将会讲到怎么使用内核来调用CGroup对容器资源做限制。 OOM介绍 out of memorty OOM:out of memorty的简称,称之为内存溢出 1....

    点击上方 "程序员小乐"关注, 星标或置顶一起成长

    后台回复“大礼包”有惊喜礼包!

    关注订阅号「程序员小乐」,收看更多精彩内容

    每日英文

    Anywhere, it is a good in the past, recall the number of times many, all would be light. 

    任何地方,再好的过去,回忆的次数多了,一切也就淡了。

    每日掏心

    要记住,相聚是短暂的,分别是永远的,任何人都不是你永恒的挂牵,任何事都不是你所有的渴盼。

    来自:zhuanlan.zhihu.com/p/162699218 | 责编:乐乐

    程序员小乐(ID:study_tech)第 1023 次推文

    往日回顾:把 14 亿人拉到一个微信群,如何实现?

         

       正文   

    前言

    在使用容器时(未被Kubernetes进行管理的情况下),我们单台主机上可能会跑几十个容器,容器虽然都相互隔离,但是用的却是与宿主机相同的内核,CPU、内存、磁盘等硬件资源。注:容器没有内核。默认情况下,容器没有资源限制,可以使用主机内核调度程序允许的尽可能多的给定资源;如果不对容器资源进行限制,容器之间就会相互影响,一些占用硬件资源较高的容器会吞噬掉所有的硬件资源,从而导致其它容器无硬件资源可用,发生停服状态。Docker提供了限制内存,CPU或磁盘IO的方法, 可以对容器所占用的硬件资源大小以及多少进行限制,我们在使用docker create创建一个容器或者docker run运行一个容器的时候就可以来对此容器的硬件资源做限制。

    Docker核心

    Docker分别使用Namespace和CGroup实现了对容器的资源隔离和资源限制,本文将会讲到怎么使用内核来调用CGroup对容器资源做限制。

    OOM介绍

    out of memorty

    OOM:out of memorty的简称,称之为内存溢出

    1.如果内存耗尽,内存将无法给予内存空间,内核检测到没有足够的内存来执行重要的系统功能,它会抛出OOM或Out of Memory异常,内存将会溢出,随之会有选择性的杀死相应的进程。2.内存属于不可压缩性资源,如果执行这个进程的内存不够使用,这个进程它就会一直申请内存资源,直到内存溢出。3.CPU属于可压缩性资源,所以CPU并不会出现这种情况,例如一个进程占用了一个核心100%的CPU,那么原本这个进程是需要占用200%的CPU资源,如果其它进程所占用的CPU核心并不需要多高的CPU频率,那么此进程就会占用掉空闲的CPU,如果其它进程也需要他自己核心的CPU频率,那么此进程就只能使用对它自己所使用CPU核心100%,因此叫做可压缩。4.内存的有选择性:为什么不是杀死占用内存最高的进程呢?举个例子:例如我们运行了一个MySQL和一个Tomcat;这个MySQL原本是需要占用2G的内存资源,但他占用了1.9G;而Tomcat原本是需要占用500M的内存空间,可他占用了1G内存空间,这个时候当内存报异常OOM的时候,就会选择Tomcat进程进行发送kill -9的信号,进行杀死以释放内存。5.当我们的一个重要的进程占用的内存超标而导致内存OOM的情况下,我们不希望内核来Kill掉我们这个进程,怎么办?我们可以调整内存OOM后kill进程的优先级,优先级越高越优先杀死,则反之 为此,Docker特地调整了docker daemon的OOM优先级,以免它被内核的杀死,但容器的优先级并未被调整

    导致内存OOM

    1.加载对象过大;2.相应资源过多,来不及加载;3.应用运行时间较长未重启,从而一点一点占用内存资源,长期积累导致占用内存空间较多;4.代码存在内存泄漏bug。
    搜索公众号程序员小乐回复关键字“Java”,获取Java面试题和答案。

    解决OOM办法

    1.内存引用上做一些处理,常用的有软引用;2.内存中加载图片直接在内存中做处理,(如边界压缩);3.动态回收内存;4.优化Delivk虚拟机的堆内存分配;5.自定义堆内存大小;6.定期重启应用以释放内存。


    压测工具stress

    下载stress

    docker pull lorel/docker-stress-ng:latest
    latest:Pullingfrom lorel/docker-stress-ng
    c52e3ed763ff:Pull complete 
    a3ed95caeb02:Pull complete 
    7f831269c70e:Pull complete 
    Digest: sha256:c8776b750869e274b340f8e8eb9a7d8fb2472edd5b25ff5b7d55728bca681322
    Status:Downloaded newer image for lorel/docker-stress-ng:latest
    

    使用方法

    docker run --name stress -it --rm lorel/docker-stress-ng:latest stress --help
    --name 指定lorel/docker-stress-ng:latest所启动的测试得容器名称为stress
    --it:打开一个伪终端,并提供交互式
    --rm:容器停止即删除
    lorel/docker-stress-ng:latest:压测stress工具镜像名称
    stress:lorel/docker-stress-ng:latest镜像内所内置的命令,必须使用此命令来指定--help支持的选项
    

    stress常用选项

    --cpu N:启动几个子进程来做压测,默认一个进程使用一个CPU核心,选项可简写为-c N
    docker run --name stress -it --rm lorel/docker-stress-ng:latest stress --help | grep  "cpu N"
    -c N,--cpu N            start N workers spinning on sqrt(rand())
    
    
    --vm N:启动几个进程来做匿名页压测,选项可简写为-m N
    docker run --name stress -it --rm lorel/docker-stress-ng:latest stress --help | grep  "vm N"
    -m N,--vm N             start N workers spinning on anonymous mmap
    
    
    --vm-bytes N:为--vm N指定的进程提供内存分配,每个进程可以分配到的内存数量,默认为256M
    docker run --name stress -it --rm lorel/docker-stress-ng:latest stress --help | grep  "vm-bytes N"
    --vm-bytes N       allocate N bytes per vm worker (default256MB)
    

    Docker内存限制

    限制内存注意事项

    1.为需要限制容器内的应用提前做好压测,例如Nginx容器自身所占内存空间,以及预算业务量大小所需占用的内存空间,进行压测后,才能进入生产环境使用;2.保证宿主机内存资源充足,监控及时上报容器内的内存使用情况,一旦容器所占用的内存不足,立刻对容器内存限制做调整或者打包此容器为镜像到其它内存充足的机器上进行启动;3.如果物理内存充足,尽量不要使用swap交换内存,swap会导致内存计算复杂。

    设置内存选项

    注意:可限制的内存单位:b、k、m、g;分别对应bytes、KB、MB、GB

    -m or --memory=:容器能使用的最大内存大小,最小值为4M--memory-swap=:容器能够使用swap内存的大小,使用—memory-swap选项必须要使用—memory选项,否则—memory-swap不生效
    --memory-swappiness:默认情况下,主机可以把容器使用的匿名页swap出来,你可以设置一个0-100之间的值,代表swap出来的比例,如果此值设置为0,容器就会先使用物理内存,能不用就不用swap空间,如果设置为100,则反之,能用swap就会用,哪怕有一丝可以用到swap空间的可能性就会使用swap空间--memory-reservation:预留的一个内存空间,设置一个内存使用soft limit,如果docker发现主机内存不足,会执行OOM操作,这个值必须小于—memory设置的值--kernel-memory:容器能够使用kernel memory大小,最小值为4M--oom-kill-disable:是否运行OOM的时候杀死容器,只有设置了-m或者-memory,才可以设置此值,值为flase或者true,设置为false之后当此容器的内存溢出的时候就会对此容器执行kill操作,否则容器会耗尽主机内存,而且导致主机应用被杀死,如果这个容器运行的应用非常重要,就把—oom-kill-disable设置为true,就是禁止被oom杀掉

    --memory-swap详解: swap:交换内存 ram:物理内存

    查看内存大小:

    限制容器内存

    使用docker的--memory选项来限制容器能够使用物理内存的大小,使用stress命令的选项--vm指定启动几个占用内存的进程和每个占用内存进程所占用的内存空间大小 我们指定了容器最多使用物理内存512M,启动两个占用内存的进程,每个进程分别占用512M的空间,那么两个进程理论上需要占用1024的空间,我们只给了1024的空间,显然是不够的:

    docker run --name stress-memory  -it --rm -m 512M  lorel/docker-stress-ng:latest stress --vm 2--vm-bytes 512M
    stress-ng: info:[1] defaulting to a 86400 second run per stressor
    stress-ng: info:[1] dispatching hogs:2 vm
    

    使用docker stats命令来查看容器硬件资源的使用情况 可以看到我们的stress-memory容器的总内存为512M,使用了500多点,但为超过521M,内存占用的百分比为99.3%:

    使用htop命令来查看资源情况:

    限制容器swap内存

    设置oom时是否杀掉进程

    Docker CPU限制

    查看CPU核心数以及编码:

    设置CPU选项

    --cpu-shares:共享式CPU资源,是按比例切分CPU资源;比如当前系统上一共运行了两个容器,第一个容器上权重是1024,第二个容器权重是512, 第二个容器启动之后没有运行任何进程,自己身上的512都没有用完,而第一台容器的进程有很多,这个时候它完全可以占用容器二的CPU空闲资源,这就是共享式CPU资源;如果容器二也跑了进程,那么就会把自己的512给要回来,按照正常权重1024:512划分,为自己的进程提供CPU资源。如果容器二不用CPU资源,那容器一就能够给容器二的CPU资源所占用,如果容器二也需要CPU资源,那么就按照比例划分,这就是CPU共享式,也证明了CPU为可压缩性资源。--cpus:限制容器运行的核数;从docker1.13版本之后,docker提供了--cpus参数可以限定容器能使用的CPU核数。这个功能可以让我们更精确地设置容器CPU使用量,是一种更容易理解也常用的手段。-cpuset-cpus:限制容器运行在指定的CPU核心;运行容器运行在哪个CPU核心上,例如主机有4个CPU核心,CPU核心标识为0-3,我启动一台容器,只想让这台容器运行在标识0和3的两个CPU核心上,可以使用cpuset来指定。
    搜索公众号程序员小乐回复关键字“offer”,获取算法面试题和答案。

    限制CPU Share

    启动stress压测工具,并使用stress命令加--cpu选项来启动四个进程,默认一个进程占用一颗CPU核心:

    docker run --name stress-share  -it --rm --cpu-shares 512  lorel/docker-stress-ng:latest stress -c 2
    stress-ng: info:[1] defaulting to a 86400 second run per stressor
    stress-ng: info:[1] dispatching hogs:2 cpu
    

    压测工具会吃掉俩个核心的所有CPU资源 再次打开一个窗口,使用htop命令来查看硬件资源损耗情况 我们一共开了两个进程,默认会占用两个cpu核心,每个核心的资源为100%,两个也就是为200%,由于没有指定限制在某个CPU核心上,所以它是动态的跑在四核CPU核心数,但是stress占用CPU的资源不会超出200%:

    再次打开一个窗口,使用docker top container也可以查看到两个进程一共消耗了多少cpu资源:

    限制CPU核数

    我们使用docker的--cpus选项来限制cpu运行的核心数,使用stress命令的选项--cpu来限制启动的进程数 显示cpu只运行两个核心数,也就是只能运行200%CPU资源,启动4个进程,也就是讲这4个进程只能跑在200%的cpu资源上:

    docker run --name stress-cpus  -it --rm --cpus 2  lorel/docker-stress-ng:latest stress -c 4
    stress-ng: info:[1] defaulting to a 86400 second run per stressor
    stress-ng: info:[1] dispatching hogs:4 cpu
    

    使用htop命令查看cpu占用资源 可以看到四个进程,但是跑在了四颗cpu上面,但是每颗cpu只运行了50%左右的资源,4*50也就是200%左右的cpu资源:

    使用docker top container也可以查看到四个进程一共消耗了多少cpu资源:

    限制容器运行在指定核心

    我们使用docker的--cpuset-cpus选项来指定cpu运行在哪个核心上,使用stress的选项--cpu来指定启动的进程数 我们指定4个进程运行在编号为0和2的cpu上:

    docker run --name stress-cpuset  -it --rm --cpuset-cpus=0,2  lorel/docker-stress-ng:latest stress -c 4
    stress-ng: info:[1] defaulting to a 86400 second run per stressor
    stress-ng: info:[1] dispatching hogs:4 cpu
    

    使用htop查看系统硬件占用资源 可以看到和预期一样,占用了第一颗和第三颗cpu,每个进程占用cpu资源为50%,总资源为200%,两颗cpu的量:

    欢迎在留言区留下你的观点,一起讨论提高。如果今天的文章让你有新的启发,欢迎转发分享给更多人。欢迎加入程序员小乐技术交流群,在后台回复“加群”或者“学习”即可。

    猜你还想看

    阿里、腾讯、百度、华为、京东最新面试题汇集

    北京44岁程序员失业,感叹:编程估计没戏了,想去卖煎饼果子

    腾讯推出的这款高性能 RPC 开发框架,确定不了解下吗?

    推荐一套开源通用后台管理系统

    嘿,你在看吗

    展开全文
  • Linux资源限制

    千次阅读 2018-07-14 09:04:39
    Linux 资源限制通过限制特定用户或程序的资源访问,也可以实现性能调优的目的。对于多用户的系统不限制资源本身可能就是一种不公平。1.通过 ulimit 是限制系统资源的一种途径,ulimit 支持 hard 和 soft 限制。Soft ...
  • k8s容器资源限制

    千次阅读 2020-05-08 20:34:23
    1. k8s容器资源限制 k8s采用request和limit两种限制类型来对资源进行分配 request(资源需求):即运行pod的节点必须满足运行pod的最基本需求才能运行pod。 limit(资源限制):即运行pod期间,可能内存使用量会增加...
  • Kubernetes K8S之CPU和内存资源限制详解

    万次阅读 2021-01-04 21:37:07
    Kubernetes K8S之CPU和内存资源限制详解
  • k8s容器资源限制2. 内存资源限制实例3. cpu资源限制4. namespace设置资源限制5. namespace中pod的配额6. namespace的创建、使用和删除7. 清除资源限制和配额 1. k8s容器资源限制 k8s采用request和limit两种限制类型...
  • Docker 的资源隔离与资源限制

    千次阅读 2019-09-06 09:56:38
    Docker 的资源隔离与资源限制Docker容器的本质Linux内核的namespace机制linux的namespace机制namespace可以隔离哪些Linux的 cgroups强大内核工具cgroups Docker容器的本质 docker容器的本质是宿主机上的一个进程。 ...
  • 后续几篇文章围绕该图涉及组件进行整理介绍,本文主要探究Namespace及与Namespace管理相关的资源限制ResourceQuota/LimitRange部分。 Namespace 理解 Namespace即命名空间,主要有两个方面的作用: 资源隔离:可为...
  • Docker容器资源限制

    千次阅读 2017-08-27 15:14:24
    Docker容器资源限制 内存 cpu调度
  • Linux资源限制配置

    千次阅读 2018-11-25 15:53:49
    命令作用:可以设置系统的限制值 命令参数: -a 显示所有限制 -c core文件大小的上限 -d 进程数据段大小的上限 -f shell所能创建的文件大小的上限 -m 驻留内存大小的上限 -s 堆栈大小的上限 -t 每秒可占用的...
  • 三、怎样对每个容器使用的这些资源进行限制呢?1、磁盘大小限制(不会)2、cpu、内存限制 一、首先先看看怎样查看这三项指标 1、先进入docker容器里 docker exec -it b6bac438271d /bin/bash 2、查看磁盘 3...
  • docker 容器资源限制

    千次阅读 2021-02-28 21:14:29
    内存和CPU资源的配置教程
  • 日常工作中会涉及到各种资源分配等问题,跨部门,跨业务等等,这里介绍基于CDH版本的Yarn 公平调度(实际使用DRF调度) 不同时间配置不同资源参考(计划模式):...
  • Docker 运行时资源限制

    万次阅读 2016-12-18 17:04:48
    Docker 运行时资源限制Docker 基于 Linux 内核提供的 cgroups 功能,可以限制容器在运行时使用到的资源,比如内存、CPU、块 I/O、网络等。内存限制概述Docker 提供的内存限制功能有以下几点: 容器能使用的内存和...
  • Docker容器通过namespace实现进程隔离通过cgroups实现资源限制; Docker镜像(rootfs)是一个操作系统的所有文件和目录而不包括内核,Docker镜像是共享宿主机的内核的; Docker镜像是以只读方式挂载,所有的增...
  • k8s中CPU和内存的资源限制解释

    千次阅读 2020-10-26 16:42:36
    在K8s中定义Pod中运行容器有两个维度的限制资源需求:即运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod。如 Pod运行至少需要2G内存,1核CPU。(硬限制资源限额:即运行Pod期间,可能内存使用量会增加...
  • docker容器运行和资源限制

    千次阅读 2018-01-13 17:47:23
    七,资源限制 一个docker host上会运行若干个容器,每个容器都需要CPU、内存和io资源。对于VMware等虚拟化技术,用户可以控制分配多少CPU、内存资源给每个虚拟机。对于容器,docker也提供了类似的机制避免某个...
  • 资源限制参数+查看资源限制参数

    千次阅读 2017-05-25 16:02:24
    cpu_per_session:限制用户一次数据库会话期间可以使用的CPU时间,单位为百分之一秒,超过时间,终止会话 cpu_per_call:用来限制每条sql所能使用的cpu时间,单位为百分之一秒 logical_reads_per_session:限制每个...
  • 已超出资源限制。此时间段的数据收集已停止 咨询了vs的工作人员。 得到回复: Thank you for reporting this issue. This warning is by-design when resource consumption by the Diagnostic Tools window ...
  • linux进程资源限制

    千次阅读 2016-02-05 17:23:05
    1.进程的资源限制通常是在系统初始化时有0进程建立,然后由每个后续进程继承,其中一些资源可以用getrlimit和setrlimt函数查询和更改 2.在更改资源限制时,须遵守下列三条规则 (1)任何一个进程都可将一个软限制值...
  • kubernetes 资源限制之ResourceQuota

    千次阅读 2019-08-02 15:55:15
    namespace提供了两种资源限制的方式:ResourceQuota 和LimitRange。 其中ResourceQuota 是针对namespace做的资源限制,而LimitRange是针对namespace中的每个组件做的资源限制。 一、ResourceQuota的使用 当多个...
  • limit资源限制ulimit 详解

    万次阅读 2015-05-28 17:39:38
    系统性能一直是一个受关注的话题...ulimit是一种Linux系统的内键功能,它具有一套参数集,用于为由它生成的shell进程及其子进程的资源使用设置限制。 命令总结: 查看系统用户所有限制值:ulimit -a 设置用户open...
  • Linux查看进程所使用资源限制

    千次阅读 2016-08-05 18:41:18
    查看方法:ulimit -a 软限制 ...下面是Ubuntu12.04 x64系统下,进程资源限制情况: core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size 
  • Hbase多租户实现方案—资源限制—quotas  上次整理了hbasde多租户基于namespace的权限管理实现方案,对于一些应用场景,基于namespace权限的多租户还不能够很好的满足业务的需求。业务有时候不单单需要基于权限...
  • Kubernetes - HPA自动伸缩、resources资源限制HPA-example 自动伸缩(测试版)一、测试 HPA 基于 CPU 的自动伸缩1、运行 hpa-example,并设置 CPU 最大资源限制200m2、创建HPA控制器3、增加 CPU 负载,查看负载节点...
  • linux资源限制级别汇总

    千次阅读 2014-12-26 15:05:29
    linux资源限制级别汇总
  • 项目中用到了K8S容器资源限制这一块内容,rancher上没有对应API,因此调用K8S的接口,但实际使用过程中有些情况是保存不了的(前端点保存后有些情况下并未设置成自己需要设置的值,因此测试认为是Bug) 调研之后...
  • Docker 运行时资源限制-内存限制

    千次阅读 2019-05-31 20:32:01
    Docker 运行时资源限制-CPU 限制CPU 限制概述CPU 限制相关参数CPU 集CPU 资源的相对限制CPU 资源的绝对限制正确的理解“绝对” CPU 限制 概述 Docker 的资源限制和隔离完全基于 Linux cgroups。对 CPU 资源的限制...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 953,469
精华内容 381,387
关键字:

资源限制

友情链接: task1.rar