Kubernets——准入控制器（LimitRange、ResourceQuota 和 PSP）

准入控制器（LimitRange、ResourceQuota 和 PSP）

  在经由认证插件和授权插件分别完成身份认证和权限检查之后，准入控制器将拦截那些创建、更新和删除相关的操作请求以强制实现控制器中定义的功能，包括执行对象的语义验证、设置缺失字段的默认值、限制所有容器使用的镜像文件必须来自某个特定的 Registry、检查 Pod 对象的资源需求是否超出了指定的限制范围等。

  对于在数据持久化以前，拦截到 Kubernetes API server 的请求，Admission controllers 是很是有用的工具。然而，因为其须要由集群管理员在 kube-apiserver 中编译成二进制文件，因此使用起来不是很灵活。从 Kubernetes 1.7 起，引入了 Initializers 和 External Admission Webhooks，用以解决这个问题。在 Kubernetes 1.9 中，Initializers 依然停留在 alpha 版本，然而 External Admission Webhooks 被提高到了 beta 版，且被分红了 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。linux

  MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 两者合起来就是一个特殊类型的 admission controllers，一个处理资源更改，一个处理验证。验证是经过匹配到 MutatingWebhookConfiguration 中定义的规则完成的。

  在运行时，以下任何一阶段中的任何控制器拒绝请求，则立即拒绝整个请求，并向用户返回错误。准入控制可分为两个阶段：

• 第一阶段，串行运行各 MutatingAdmissionWebhook。
• 第二阶段，串行运行各 ValidatingAdmissionWebhook。

一、LimitRange资源与LimitRanger准入控制器

  LimitRange 资源在每个名称空间指定最小及最大计算资源用量，甚至是设置默认的计算资源需求和计算资源限制。

  在名称空间上定义了 LimitRange 对象之后，客户端提交创建或修改的资源对象将受到 LimitRanger 控制器的检查，任何违反 LimitRange 对象定义的资源最大用量的请求将被直接拒绝。

  LimitRange 资源支持限制 容器、Pod 和 PVC 三种资源对象的系统资源用量。LimitRange.spec.limits 字段嵌套定义如下：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

[root@k8s-master01-test-2-26 pki]# kubectl explain LimitRange.spec.limits KIND:     LimitRange VERSION:  v1   RESOURCE: limits <[]Object>   DESCRIPTION:      Limits is the list of LimitRangeItem objects that are enforced.        LimitRangeItem defines a min/max usage limit for any resource that matches      on kind.   FIELDS:    default  <map[string]string>      Default resource requirement limit value by resource name if resource limit      is omitted.      defaultRequest   <map[string]string>      DefaultRequest is the default resource requirement request value by      resource name if resource request is omitted.      max  <map[string]string>      Max usage constraints on this kind by resource name.      maxLimitRequestRatio <map[string]string>      MaxLimitRequestRatio if specified, the named resource must have a request      and limit that are both non-zero where limit divided by request is less      than or equal to the enumerated value; this represents the max burst for      the named resource.      min  <map[string]string>      Min usage constraints on this kind by resource name.      type <string> -required-      Type of resource that this limit applies to.   [root@k8s-master01-test-2-26 pki]#

  下面我们举个示例，以容器的 CPU 资源为例，default 用于定义默认的资源限制，defaultRequest 定义默认的资源需求，min 定义最小的资源用量，而最大的资源用量既可以使用 max 给出固定值，也可以使用 maxLimitRequestRatio 设定为最小值的指定倍数：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

apiVersion: v1 kind: LimitRange metadata:   name: cpu-limit-range spec:   limits:   - default:       cpu: 1000m     defaultRequest:       cpu: 1000m     min:       cpu: 500m     max:       cpu: 2000m     maxLimitRequestRatio:       cpu: 4     type: Container

　　将配置清单中的资源创建于集群的 default 名称空间之中了。

 二、ResourceQuota 资源与准入控制器

  LimitRange 资源能限制单个容器、Pod 及 PVC 等相关计算资源或存储资源的用量，但用户依然可以创建数量众多的此类资源，最终导致资源耗尽。那有什么办法可以限制呢？Kubernetes 提供了 ResourceQuota 资源用于定义名称空间的对象数量或系统资源配额。

  ResourceQuota 支持限制每种资源类型的对象总数，以及所有对象所能消耗的计算资源及存储资源总量等。ResourceQuota 准入控制器负责观察传入的请求，并确保它没有违反相应名称空间中 ResourceQuota 对象定义的任何约束。

  ResourceQuota 的字段嵌套定义如下：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

[root@k8s-master01-test-2-26 pki]#  kubectl explain resourcequota KIND:     ResourceQuota VERSION:  v1   DESCRIPTION:      ResourceQuota sets aggregate quota restrictions enforced per namespace   FIELDS:    apiVersion   <string>      APIVersion defines the versioned schema of this representation of an      object. Servers should convert recognized schemas to the latest internal      value, and may reject unrecognized values. More info:      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources      kind <string>      Kind is a string value representing the REST resource this object      represents. Servers may infer this from the endpoint the client submits      requests to. Cannot be updated. In CamelCase. More info:      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds      metadata <Object>      Standard object's metadata. More info:      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata      spec <Object>      Spec defines the desired quota.      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status      status   <Object>      Status defines the actual enforced quota and its current usage.      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status   [root@k8s-master01-test-2-26 pki]#

  resourcequota.spec 字段嵌套定义如下：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

[root@k8s-master01-test-2-26 pki]#  kubectl explain resourcequota.spec KIND:     ResourceQuota VERSION:  v1   RESOURCE: spec <Object>   DESCRIPTION:      Spec defines the desired quota.      https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status        ResourceQuotaSpec defines the desired hard limits to enforce for Quota.   FIELDS:    hard <map[string]string>      hard is the set of desired hard limits for each named resource. More info:      https://kubernetes.io/docs/concepts/policy/resource-quotas/      scopeSelector    <Object>      scopeSelector is also a collection of filters like scopes that must match      each object tracked by a quota but expressed using ScopeSelectorOperator in      combination with possible values. For a resource to match, both scopes AND      scopeSelector (if specified in spec), must be matched.      scopes   <[]string>      A collection of filters that must match each object tracked by a quota. If      not specified, the quota matches all objects.   [root@k8s-master01-test-2-26 pki]#

  下面的配置清单示例定义一个 ResourceQuota 资源对象，它配置了计算资源、存储资源及对象技术几个纬度的限额：

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14

apiVersion: v1 kind: ResourceQuota metadata:   name: quota-example spec:   hard:     pods: "5"     requests.cpu: "1"     requests.memory: "1Gi"     limits.cpu: "2"     limits.memory: "2Gi"     count/deployments.apps: "1"     count/deployments.extensions: "1"     persistentvolumeclaims: "2"

　　ResourceQuota 对象创建之后，只会对之后创建的资源对象有效，对于已经存在的对象不会产生任何限制。

 三、PodSecurityPolicy

  PodSecurityPolicy（简称 PSP）是集群级别的资源类型，用于控制用户在配置 Pod 资源的期望状态时可以设定的特权类的属性，例如：是否可以使用特权容器、命名空间、主机文件系统，以及可使用主机网络和端口、卷类型和 Linux Capabilites 等。

  PSP 对象定的策略本身并不会直接发生作用，它们需要经由 PodSecurityPolicy 准入控制器检查并强制生效。

  PSP 准入控制器默认是出于未启用状态，原因是在未创建任何 PSP 对象的情况下启用此准入控制器将组织在集群中创建任何 Pod 对象，因此管理员可以事先定义好所需要的 Pod 安全策略，再设置 kube-apiserver 启用 PSP 准入控制器。

 启用 PSP 准入控制器后，若是要部署任何 Pod 对象，则相关的 User Account 及 Service Account 必须全部获得了恰当的 Pod 安全策略授权。不然希望创建 Pod 资源对象，但不存在任何策略支持创建 Pod 对象时，则会拒绝相关的操作。

  即使是在启用了 PSP 准入控制器的情况下创建的 PSP 对象也依然不会发生效用，而是要由授权插件（如 RBAC）将 "use" 操作权限授权给特定的 Role 或 ClusterRole，而后将 Use Account 或 Service Account 完成角色绑定才行。

  这里我们就不细说了，原因如下：

?

1 2 3 4

[root@k8s-master01-test-2-26 pki]# kubectl get podsecuritypolicy Warning: policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+ No resources found [root@k8s-master01-test-2-26 pki]#