准入控制器（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 字段嵌套定义如下：
[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 设定为最小值的指定倍数：
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 的字段嵌套定义如下：
[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 字段嵌套定义如下：
[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 资源对象，它配置了计算资源、存储资源及对象技术几个纬度的限额：
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 完成角色绑定才行。
这里我们就不细说了，原因如下：
[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]#