kubernetes-准入控制器-13

Pod资源需求及资源限制

如：CPU资源属于可压缩资源，一个Pod获取资源不到时会长期等待CPU资源，而Pod获取不到内存时，会报错因为内存属于非可压缩资源

• requests: Pod资源需求，最低保障，作用： 确保调度时对应节点应该满足于这个Pod运行时的基本需求

• limits： Pod限制，最高或最低区域，硬限制，作用： 限制运行的Pod运行时资源的天花板

  一般来讲 requests 一般小于 limits，资源需求与资源限定需要同时使用

指标说明

• CPU：在资源中是指一颗逻辑(虚拟)CPU或者超线程，1C也可以划分成更细微的资源单位(millicores)

  • 如 1C=1000mc, 500mc=0.5cpu

• 内存单位： E、P、T、G、M、K、 或Ei、 Pi ,i 表示单位为1024 ， 不加i就是1000

示例

]# cat pod_limit.yaml 
apiVersion: apps/v1
kind: Deployment
metadata: 
  name: my-pod-limit
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-pod-limit
  template:
    metadata:
      name: my-pod-limit
      namespace: default
      labels:
        app: my-pod-limit
    spec:
      containers:
      - name: my-pod-limit
        image: ikubernetes/myapp:v1
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 80
        resources:      # 资源限定
          requests:
            memory: "126Mi"
            cpu: "126m"
          limits:
            memory: "256Mi"
            cpu: "256m"
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - preference:
              matchExpressions:
              - key: zone
                operator: In
                values: ["bj","tj"]
            weight: 30

Qos类别

1. Guranteed: 同时设置每个容器的CPU和内存requests和limits. 最高优先级

   • 需要同时满足：cpu.limites=cpu.request, memory.limites=memeory.request

   kubectl delete -f xx.yaml   # 删除
   kubectl apply  -f xx.yaml   # 创建
   
   # 查看资源 ]# kubectl describe pod my-pod-limit-6fb597f6b7-4j28h
       Limits:
         cpu:     256m
         memory:  256Mi
       Requests:
         cpu:        256m
         memory:     256Mi
       Environment:  <none>
   QoS Class:       Guaranteed   # 注意，当条件都满足时， Qos该类别为最高优先级
   

2. Burstable： 至少有一个容器设置了CPU或内存资源的requests属性， 中等优先级

   # 根据类别，分别修改Limits对应的资源
   	Limits:
         cpu:     256m
         memory:  256Mi
       Requests:
         cpu:        126m
         memory:     126Mi
   QoS Class:       Burstable
   

3. BestEffort： 没有任何一个容器设置了reuqest或limit属性， 最低优先级，

   # 没有定义任何的limit或requests时，该Pod为BestEffort属性，级别是最低的
   

资源应用

1. 当宿主机资源不足时会优先将最低优先级的资源终止
2. 无最低就先终止中等优先级，最先优先运行最高优先级的Pod
3. 当只有 最高优先级时， 优先先按照使用的比例来运行，如 pod1的requests是500mi而limit已经占了480mi, pod2的requests是1024mi, 而Limit占了500mi，那么会先终止pod1的程序 因为pod2的空闲很充足

准入控制器

Admission Controllers，理论来源： kubernetes准入控制器

资源管理控制类： 集群访问入口APIService，这时候一般APIService被公认为是整个集群系统的GETWAY

资源访问： 运行在k8s之上跑的应该，一般借助于nodeport或ingress访问，这些请求不会经过APIServer

​ 对Kubernetes之上资源本身的各种各样属性管理类的访问，访问方式无非就是命令行、WEB UI或者API的访问，APIServer不仅接收来自于集群外部的请求之外，还有向集群内部的请求比如向CoreOS这样管理类的应用，甚至每一个Pod都需要与APIServer进行交互，为此，APIServer在内部内嵌了有三个重要的功能插件，分别是认证、授权、准入控制；

​ 至于这些核心功能都是以插件的方式进行部署，因此认证、授权、准入控制就有了各式各样的插件，并且多个模块是可以同时启用的，如果不启用则表示不支持对应功能，

1. 比如认证，几个典型的认证机制

• 第一种：客户端证书认证
• 第二种：基于用户名和密码认证
• 第三种：令牌认证

 一般而言每一种认证方式，通常都需要通过http协议的首部来承载相关的认证信息，尤其是令牌；

2. 对于授权而言，也一样支持多个授权插件同时启用，截止至目前，我们的Kubernetes主要所支持的四种授权模块，分别是Node、ABAC、RBAC、Webhook，认证和授权的工作逻辑很想象，他们都基于短路的方式进行工作，而且是一票通过，也就意味着任何一个对应的插件只要反馈这个用户认证或者授权通过了，那么它就通过了APIServer的认证或者授权的校验，后续其他认证模块将不会再进行检查；

3. 准入控制是一个比较独特的工作逻辑，准入控制的模块分为两类

• 第一种：便易型模块，主要用于按照模块规定，修改用户提交关于资源定义的属性值
• 第二种：校验型模块，主要用于检验用户所提交的配置信息，是否符合当前系统上已有或者用户自定义的某种规范，所有的准入控制代码我们称之为准入控制器；

​ 准入控制器有很多种，其中便易类的准入控制器一般不会拒绝用户的操作，因为它们只是用来修改用户所提交的资源，尤其是新提交的属性定义或新资源，而当这些定义如果不符合规范，比如缺少字段、字段描述方式有误，那么它会自动将字段进行补全、修正或者填充，

​ 而校验型的准入控制器，则是校验用户提交的修改操作是否被准入，提交内容合法并且符合准入控制器的规范则准入则通过，如果用户提交的规范不符合准入控制器所定义的，则被拒绝

​ 准入控制器的工作逻辑是一票否决，准入控制器只对写操作有效，无论便易型或者检验型它只对新增字段或修改值有影响，而如果检测过程定义完成并开始校验，一旦被拒绝那么这次请求将会被直接拒绝，因此这仅对修改类的操作有效；

准入控制器种类

• **AlwaysAdmmit(deprecated)：**总是允许，不拒绝用户的任何请求；
• **AlwaysPullImages： **无论Pod定义imagePullPolicy什么属性，一旦使用这个准入插件检验，那么Pod每次变动都会重新pull镜像，强制避免使用本地镜像；
• **AlwaysDeny(deprecated)：**总是拒绝，拒绝用户的任何请求；
• DefaultStorageClass： 默认存储类，当我们创建了一个不属于StorageClass的PV或者PVC的时候，自动给他分配一个StorageClass；
• **LimitRanger：**限制范围，当我们不期望每一次定义Pod时都显示定义Limit或者request就可以使用LimitRanger，它允许我们在某一个名称空间上，创建一个LimitRanger的资源，这个是一个Kubernetes标准资源，一旦将它定义在名称空间之后，就相当于为这个名称空间内所有创建的Pod限制，必须有资源下限或上限，如果没有定义也会有默认值，前提是在启动ApiServer时必须开启LimitRanger插件才会生效
• ResoucreQuota：资源配额，我们可以在所有或者某一个名称空间上定义一个ResoucreQuota资源类型，它也是标准的Kubernetes资源，ResoucreQuota主要用来定义整个名称空间最多使用的资源总量，它可以定义在一个名称空间上能创建多少个资源，可以明确指定这个名称空间10个Pod、3个Service、3个Deployment、3个pv等都可以定义，也可以名称指定所有Pod加起来所消耗的CPU不能超过10核，内存不能超过20G；
• **ServiceAccount：**每创建一个Pod都会附加一个ServiceAccount，这个SA的名称叫default，每一个SA都应该有一个secrets，这个secrets主要认证到APIServer，因此每一个Pod默认的ServiceAccount的secrets是被作为存储卷的方式自动关联到Pod上去的，而这一切都是依靠ServiceAccount准入控制器自动实现的；
• **PodSecurityPoliy：**Pod安全策略，可以在Pod级别或容器级别定义SecurityContext以确保我们所定义的Pod不会违反安全策略带来危险，而为了避免用户没有定义SecurityContext的Pod带来的危险问题，一旦我们开启了PodSecurityPoliy，每一个名称空间的Pod都必须明确符合我们在PodSecurityPoliy所定义的Pod安全策略，任何用户创建的Pod必须有一个PodSecurityPoliy资源定义，这个Pod才会被允许创建，如果没有定义则这次请求将会被拒绝，PodSecurityPoliy默认没启用就是这个原因；
• DefaultTolerationSeconds：
• DenyEscalatingExec：

limitRager

在Pod级别或者容器级别配置可使用的资源配额，标准k8s资源类型

• 资源类型

  NAME         SHORTNAMES   APIGROUP  NAMESPACED   KIND
  limitranges  limits                 true         LimitRange
  

• 查看默认启用的准入控制器

  ]# grep 'admission' /etc/kubernetes/manifests/kube-apiserver.yaml
      - --enable-admission-plugins=NodeRestriction
  

• Container Limits/Pod Limits： 容器级别的Limits，可以限制CPU或者内存的最大最小的使用范围，当然也可以只定义requests或者只定义limits

• Min:：最小资源限制，可以定义一个具体的值也可以指定一个比例；

• Max：最大资源限制，可以定义一个具体的值也可以指定一个比例；

• MaxLimitRequestRatio：允许的最大倍数，也就是说Max最大比Min大多少被，注意，是最大，所以不是说一定要多少倍；

LimitRanger-示例

1. 定义limit资源

apiVersion: v1
kind: LimitRange
metadata:
  name: core-resource-limits
spec:
  limits:
  - type: Pod     # 类型是Pod
    max:
      cpu: 2
      memory: 1Gi
    min:
      cpu: 200m
      memory: 6Mi
  - type: Container   # 类型是容器
    max:
      cpu: 2
      memory: 1Gi
    min:
      cpu: 200m
      memory: 6Mi
    default: # 如果某一容器在定义时，没有定义请求上限，可以用default定义
      cpu: 300m    # 如果没有定义Pod的resource，那么默认就是这个值， 最小是200m
      memory: 200Mi
    defaultRequest: # 如果某一容器在定义时，没有定义请求下限，可以用default定义
      cpu: 200m     # 资源最小需要这么大，定义Pod时不能小于它
      memory: 100Mi
    maxLimitRequestRatio: #  max最大比min大多少倍
      cpu: 10
      
]# kubectl describe limitranges my-limit-res 
Name:       my-limit-res
Namespace:  default
Type        Resource  Min    Max  Default Request  Default Limit  Max Limit/Request Ratio
----        --------  ---    ---  ---------------  -------------  -----------------------
Pod         cpu       200m   2    -                -              -
Pod         memory    100Mi  1Gi  -                -              -
Container   cpu       200m   2    200m             300m           2
Container   memory    100Mi  1Gi  100Mi            200Mi          10

2. 默认Pod不定义资源

# 如果是默认名称空间就直接定义默认名称空间的POD
]# kubectl run test-limit --image=ikubernetes/myapp:v1
]# kubectl describe pod test-limit
    Limits:
      cpu:     300m
      memory:  200Mi
    Requests:
      cpu:        200m
      memory:     100Mi

3. 当pod资源不符合limitrage时

apiVersion: v1
kind: Pod
metadata:
  name: my-limit-pod
spec:
  containers:
  - name: my-limit-pod
    image: ikubernetes/myapp:v1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    resources:
      limits:
        cpu: 100m     # 很明显小于最小的200m  内存小于100Mi
        memory: 50Mi
      requests:
        cpu: 100m
        memory: 50Mi
        
]# kubectl apply -f pod.yaml 
Error from server (Forbidden): error when creating "pod.yaml": pods "my-limit-pod" is forbidden: [minimum cpu usage per Pod is 200m, but request is 100m, minimum memory usage per Pod is 100Mi, but request is 52428800, minimum cpu usage per Container is 200m, but request is 100m, minimum memory usage per Container is 100Mi, but request is 50Mi]

ResoucreQuota

ResoucreQuota可以在某一个指定的名称空间上限制整个名称空间可使用的资源总额，限制所有非终止状态的Pod的资源总和； 官方参数

1. **cpu：**如果不设定上下限，那么直接定义cpu即可；

2. **limits.cpu：**CPU最大不能超过多少，计算方式是，所有非终止状态的Pod的cpu.limits.cpu的上限值和不能超过这个总额；

3. **limits.memory：**内存最大不能超过多少，计算方式是，所有非终止状态的Pod的cpu.limits.memory的上限值和不能超过这个总额；；

4. **memory：**如果不设定上下限，那么直接定义memory即可；

5. **requests.cpu：**CPU最小不能超过多少，计算方式是，所有非终止状态的Pod的cpu.requests.cpu的上限值和不能超过这个总额；

6. **requests.memory：**内存最小不能超过多少，计算方式是，所有非终止状态的Pod的cpu.requests.memory的上限值和不能超过这个总额；

7. **requests.storage：**指定名称空间的所有Pod的pvc的总量不能超过这个值；

8. **persistentvolumeclaims：**限制在指定名称空间的pvc的数量总和不能超过这个值；

9. 在k8s 1.9之后允许对所有资源类型做数量限制，比如pv、pvc、pod等，语法： count/<resource>.group

service数量限制：count/services
deployment数量限制：count/deployment.apps
pvc限制：count/persistentvolumeclaims
任意类型的资源：count/*

配额作用域

这种配额只对哪些种类型的Pod生效，可以限制指定类别的Pod，而不是所有类别，当然，默认是所有类别；

属性	说明
Terminating	只让它生效在终止状态的Pod上面
NotTerminating	只让它生效在非终止状态的Pod上面
BestEffort	只让它生效在NotBestEffort状态的Pod上面
NotBestEffort	只让它生效在非NotBestEffort的状态的Pod上面

资源配置说明

选项	说明
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 总数上限。

配置-示例

1. 查看api-resources

~]# kubectl api-resources | grep resource
NAME                SHORTNAMES   APIGROUP  NAMESPACED   KIND
resourcequotas      quota                  true         ResourceQuota

2. 示例demo

apiVersion: v1
kind: ResoucreQuota
metadata:
  name: core-object-counts # 核心资源技术
  namespace: cce # 指定生效的namespace
spec:
  hard: # 硬限制
    configmaps: 10             # configmaps资源不能超过10个
    persistentvolumeclaims: 4  # pvc不能超过4个
    replicationcontrollers: 20 # replicationcontrollers控制器不能超过20个
    secrets: 10  			   # secrets不能超过10个
    services: 10			   # services不能超过10个
	pod: 10     			   # Pod不能超过10个

3. 实战-示例-demo

]# kubectl describe -n my-quota resourcequotas object-resource 
Name:                  object-resource
Namespace:             my-quota
Resource               Used  Hard
--------               ----  ----
count/deployment.apps  0     1
limits.cpu             0     2
limits.memory          0     2Gi
pods                   0     10
services               0     1

4. deployment资源

]# cat quota-deploy.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: quota-deploy
  namespace: my-quota
spec:
  replicas: 10
  selector:
    matchLabels:
      name: my-quota
      release: qa
  template:
    metadata:
      name: my-quota
      namespace: my-quota
      labels:
        name: my-quota
        release: qa
    spec:
      containers:
      - name: my-quota
        image: ubuntu
        imagePullPolicy: IfNotPresent
        command: ["/bin/sh"]
        args: ["-c", "while true; do echo hello; sleep 10;done"]
        resources:
          limits:
            cpu: 500m
            memory: 200Mi
            
]# kubectl describe -n my-quota resourcequotas object-resource 
Name:                  object-resource
Namespace:             my-quota
Resource               Used   Hard
--------               ----   ----
count/deployment.apps  0      1
limits.cpu             2      2
limits.memory          800Mi  2Gi
pods                   4      10
services               0      1

# 如果当前空间中的任何一条匹配了，那么在获取资源便会失效
]# kubectl get pods -n my-quota 
NAME                            READY   STATUS    RESTARTS   AGE
quota-deploy-5545fc67bd-j4ptn   1/1     Running   0          16h
quota-deploy-5545fc67bd-mlcrm   0/1     Pending   0          16h
quota-deploy-5545fc67bd-mv8jg   0/1     Pending   0          16h
quota-deploy-5545fc67bd-wkjrh   1/1     Running   0          16h

  Warning  FailedScheduling  <unknown>  default-scheduler  0/3 nodes are available: 1 Insufficient memory, 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate, 2 Insufficient cpu.