当前位置 博文首页 > 堇牧安年:kubernetes之为每个命名空间的pod设置默认的requests

    堇牧安年:kubernetes之为每个命名空间的pod设置默认的requests

    作者:堇牧安年 时间:2021-01-30 18:22

    一  为啥需要为命名空间里面添加pod添加默认的requests和limits?

      

      通过前面的学习我们已经知道,如果节点上面的pod没有设置requests和limits,这些容器就会受那些设置了的控制,一旦出现节点内存资源超卖,这些未被设置的pod则会优先被kubernetes清除,所以对于每个pod而言,都应当给设定requests和limits值是个不错的选择。

     

      1.1 介绍limitRange资源

        limitRange不仅支持用户给命名空间里面的pod每种资源配置最大最小值,甚至还会在没有显性的申明下,还会给容器添加系统的默认配值,更详细的描述如图所示

                    

     

    • 图中很好的显示了,当创建podA的时候,由于里面的requests和Limits值超过了LimitRange的预设置,所以无法成功的创建
    • 而在创建pod B的时候由于没有设置默认的requests和limits的值在,则准入插件会根据默认值为它添加这2项
    • 如果命名空间里面没有LimitRange的话,当pod申请的资源大于节点的资源的时候API服务器还是会接收这个请求,但是却无法进行调度
    • limitRange资源参数limit的作用对象始终是每个独立的pod,容器或者是其他类型对象,始终不会是某个命名空间的limits总和,实际上总和是由ResourceQuota对象来指定

     

      1.2  创建一个LimitRange对象

    apiVersion: v1
    kind: LimitRange
    metadata:
      name: example
    spec:
      limits:
      - type: Pod
        min:
          cpu: 50m
          memory: 5Mi
        max:
          cpu: 1
          memory: 1Gi
      - type: Container
        defaultRequest:
          cpu: 100m
          memory: 10Mi
        default:
          cpu: 200m
          memory: 100Mi
        min:
         cpu: 50m
         memory: 5Mi
        max:
          cpu: 1
          memory: 1Gi
        maxLimitRequestRatio:
          cpu: 4
          memory: 10
      - type: PersistentVolumeClaim
        min:
          storage: 1Gi
        max:
          storage: 10Gi
    • LimitRange中以type为分类可以限制各种各种类型的资源,第一项限制了pod中容器requests和limits之和最大值和最小值区间
    • 第二项设置了pod中每个容器在没有配置的时候默认添加的requests和limits的值以及每个容器的内存以及cpu最小最大值,和最大值与最小值的比值限制等
    • 并且可以限制pvc的最大值以及最小值
    • 也可以单独的将这些type进行拆分,之后pod在通过API的准入插件的时候,会将所有的这些type合并起来
    • 如果在修改了LimitRange之后,之前集群已经创建的pod规则不会收到影响(这里有个疑问,如果pod在LimitRange资源创建之前就已经好了,后来由于某种原因需要重新调度,并且还是沿用之前pod的requests和limits,我觉得还是会受到影响)

     二  限制命名空间的资源总量

     

      2.1  kubernetes通过ResourceQuota资源对命名空间的资源总量进行控制

        资源配额的作用是限制某个命名空间里面各种资源的最大使用量,已经创建的pod不会被限制,例如当在创建某个pod的时候,申请的pod的内存加上集群中已经存在的pod的内存总量超过ResourceQuota,那么API服务器将会决绝接收这个pod的申请,并且除了容器的cpu,内存等这些基础资源,同时也可以限制其他的API类型资源,例如RC,RS等等一系列的资源使用量

     

      2.2 为CPU和内存使用量创建ResourceQuota    

    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: cpu-and-mem
    spec:
      hard:
        requests.cpu: 400m
        requests.memory: 200Mi
        limits.cpu: 600m
        limits.memory: 500Mi
    • 这个ResourceQuota分别对命名空间里面的requests.cpu,requests.memory,limits.cpu,limits.memory的总量总出了限制
    • 区别于LimitRange针对的对象是pod以及容器,ResourceQuota针对的对象是命名空间这些资源的总量

     

      2.3  查看配额以及配额使用情况

    [root@node01 Chapter14]# k describe quota
    Name:            cpu-and-mem
    Namespace:       default
    Resource         Used  Hard
    --------         ----  ----
    limits.cpu       1     600m
    limits.memory    20Mi  500Mi
    requests.cpu     2     400m
    requests.memory  50Mi  200Mi
    • 这些资源是之前就已经创建了的,后面创建的ResourceQuota无法对其起到限制作用
    • 需要注意的一点是在创建的ResourceQuota的时候集群里面必须已经有LimitRange资源,否则在创建那些未设定requests和limits的pod的时候无法纳入统计,或者导致ResourceQuota统计的资源不准确

     

      2.4  为持久化存储指定配额

    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: storage
    spec:
      hard:
        requests.storage: 500Gi
        ssd.storageclass.storage.k8s.io/requests.storage: 300Gi
        standard.storageclass.storage.k8s.io/requests.storage: 1Ti
    • 系统允许在这个命名空间里面添加最大的存储为500Gi
    • 第二项是ssd的storage的配置最大为300Gi
    • 第三项是低性能的磁盘的额度为1Ti

      2.5  限制集群资源可创建对象

    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: quota-objects
    spec:
      hard:
        pods: 10
        replicationcontrollers: 5
        secrets: 10
        configmaps: 10
        persistentvolumeclaims: 4
        services: 5
        services.loadbalancers: 1
        services.nodeports: 2
        ssd.storageclass.storage.k8s.io/persistenevolumeclaims: 2
    • 上面的代码不言而喻,分别对命名空间里面的每种资源的数量数额进行限制

     

      2.6 为特定的状态的pod或者Qos等级的pod指定配额

        先来解释一下,可以选择的状态有哪几种

      • BestEffort 前面已经介绍过,即pod未被设置任何的requests和limits
      • NotBestEffort,即所有的配置了requests和limits的pod
      • Termination,这个不好理解,可以直接理解为pod的spec中配置了activeDeadlineSecond属性的pod,而这个属性意思就是当pod被标记为failed的时候pod还可以在节点上运行的时间
      • NotTermination,这个意思是pod未加入这个activeDeadlineSecond属性的pod

        对于BestEffort和NotTermination的范围,只需要pod在集群中的数量,而对于NotBestEffort以及Termination状态的pod除了需要添加数量外,还需要添加requests以及limits,一个示范例子如下所示

    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: besteffort-notterminating-pods
    spec:
      scopes:
      - BestEffort
      - NotTerminating
      hard:
        pods: 40

     

    三 监控集群中pod的资源使用量

     

      注意:这里只对原理进行说明,不对实际的操作以及如何部署相关的应用进行展开

     

      3.1 如何收集每个节点上面的pod的资源使用情况

        kubelet自身包含一个cAdvisor的agent,它会收集整个节点上容器的消耗情况,之后将信息汇报给Heapster的组件

     

    bk