k8s 准入控制器【1】-介绍_配置文件

文章目录

1. 背景

Kubernetes 提供了需要扩展其内置功能的方法，最常用的可能是自定义资源类型和自定义控制器了，除此之外，Kubernetes 还有一些其他非常有趣的功能，比如 ​​admission webhooks​​​ 或者 ​​initializers​​​，这些也可以用于扩展 API，它们可以用于修改某些 Kubernetes 资源的基本行为，接下来我们来看看那些引入了 ​​admission webhooks​​ 的动态准入控制。

2. 什么是准入控制器插件

大概意思就是说准入控制器是在对象持久化之前用于对 ​​Kubernetes API Server​​​ 的请求进行拦截的代码段，在请求经过身份验证和授权之后放行通过。准入控制器可能正在​​validating​​​、​​mutating​​或者都在执行，Mutating 控制器可以修改他们的处理的资源对象，Validating 控制器不会，如果任何一个阶段中的任何控制器拒绝了请求，则会立即拒绝整个请求，并将错误返回给最终的用户。

这意味着有一些特殊的控制器可以拦截 Kubernetes API 请求，并根据自定义的逻辑修改或者拒绝它们。Kubernetes 有自己实现的一个控制器列表：​​https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#what-does-each-admission-controller-do​​​，当然你也可以编写自己的控制器，虽然这些控制器听起来功能比较强大，但是这些控制器需要被编译进 ​​kube-apiserver​​，并且只能在 apiserver 启动时启动。

由于上面的控制器的限制，我们就需要用到“动态”的概念了，而不是和 apiserver 耦合在一起，​​Admission webhooks​​​和​​initializers​​就通过一种动态配置方法解决了这个限制问题。对于这两个功能，initializers属于比较新的功能，而且平时用得非常少，还是一个alpha特性，所以更多的我们会来了解下Admission webhooks的使用方法。

在新版本(1.14+) kubernetes 集群中已经移除了对initializers的支持，所以可以不用考虑这种方式。

最后，除了对对象进行变更外，准入控制器还可以有其它作用：将相关资源作为请求处理的一部分进行变更。 增加使用配额就是一个典型的示例，说明了这样做的必要性。 此类用法都需要相应的回收或回调过程，因为任一准入控制器都无法确定某个请求能否通过所有其它准入控制器。

k8s 准入控制器【1】-介绍_kubernetes_02

3. 为什么需要准入控制器？

安全性：通过在整个命名空间和集群中强制设置合理的安全基线，准入控制器可以帮助提高整体安全性。

如内置的 PodSecurityPolicy 准入控制器可以禁止容器以特权身份运行或确保容器的根文件系统始终以只读方式安装。基于 webhooks 的准入控制器也可以实现其他的安全功能，如：

  • 只允许从企业已知的特定镜像仓库提取镜像，拒绝未知镜像仓库；
  • 拒绝不符合安全标准的部署，如可以通过拒绝请求和用 false 覆盖 privileged 参数，降低容器使用特权身份绕过安全检查的风险。

IT 治理：准入控制器可以帮助遵守某些规范，例如使用标签、注释、资源限制或其他设置，一些常见方案包括：

  • 对不同对象强制执行标签验证，确保始终将正确的标签用于各种对象；
  • 自动向对象添加注释，例如为“dev”部署资源指定正确的 cost center。

**配置管理：准入控制器可以帮助工程师验证集群中运行时对象的配置，防止错误配置影响集群。**它对检测和修复不带语义标签的镜像很有用，例如：

  • 自动添加资源限制或验证资源限制；
  • 确保将合理的标签添加到 Pod；
  • 确保在生产部署中使用的镜像引用不使用 latest 标签，或带有 -dev 后缀的标签。

通过以上方式，准入控制器和策略管理有助于确保应用程序在不断变化的控制环境中保持一致。

4. 如何启用一个准入控制器？

Kubernetes API 服务器的 enable-admission-plugins 标志接受一个用于在集群修改对象之前 调用的（以逗号分隔的）准入控制插件顺序列表。

例如，下面的命令就启用了 NamespaceLifecycle 和 LimitRanger 准入控制插件：

kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ...

说明： 根据你 Kubernetes 集群的部署方式以及 API 服务器的启动方式的不同，你可能需要以不同的方式应用设置。 例如，如果将API 服务器部署为 systemd 服务，你可能需要修改 systemd 单元文件； 如果以自托管方式部署Kubernetes，你可能需要修改 API 服务器的清单文件。

5. 怎么关闭准入控制器？

Kubernetes API 服务器的 disable-admission-plugins 标志，会将传入的（以逗号分隔的） 准入控制插件列表禁用，即使是默认启用的插件也会被禁用。

kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...

6. 哪些插件是默认启用的？

下面的命令可以查看哪些插件是默认启用的：

kube-apiserver -h | grep

在目前版本中，它们是：

NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota

而在 Kubernetes 自带的 30 多个准入控制器中，有两个因其灵活性扮演着特殊角色（它们在 1.13 版本中都是 beta）：

  • ValidatingAdmissionWebhooks
  • MutatingAdmissionWebhooks

虽然本身并不实现任何决策，但它们将准入控制器的逻辑与 Kubernetes API Server 解耦，使工程师当在 Kubernetes 集群中创建、更新或删除资源时，能够实现要执行的自定义逻辑。

  • ​​ValidatingAdmissionWebhook​​：该准入控制器调用与请求匹配的任何验证 webhook。匹配的 webhooks是并行调用的；如果其中任何一个拒绝请求，则请求失败。
  • ​​MutatingAdmissionWebhook​​：该准入控制器调用与请求匹配的任何变更 webhook。匹配的 webhook是串行调用的；如果需要，每个人都可以修改对象。

7. 每个准入控制器的作用是什么？

AlwaysAdmit

FEATURE STATE: Kubernetes v1.13 [deprecated]

该准入控制器会允许所有的 pod 接入集群。已废弃，因为它的行为根本就和没有准入控制器一样。

AlwaysPullImages

该准入控制器会修改每一个新创建的 Pod 的镜像拉取策略为 ​​Always​​ 。 这在多租户集群中是有用的，这样用户就可以放心，他们的私有镜像只能被那些有凭证的人使用。 如果没有这个准入控制器，一旦镜像被拉取到节点上，任何用户的 Pod 都可以通过已了解到的镜像 的名称（假设 Pod 被调度到正确的节点上）来使用它，而不需要对镜像进行任何授权检查。 当启用这个准入控制器时，总是在启动容器之前拉取镜像，这意味着需要有效的凭证。

AlwaysDeny

FEATURE STATE: Kubernetes v1.13 [deprecated]

拒绝所有的请求。由于没有实际意义，已废弃。

CertificateApproval

此准入控制器获取“审批” ​​CertificateSigningRequest​​ 资源的请求并执行额外的授权检查， 以确保审批请求的用户有权限审批 ​​spec.signerName​​​ 请求 ​​CertificateSigningRequest​​ 资源的证书请求。

有关对证书签名请求资源执行不同操作所需权限的详细信息， ​​请参阅证书签名请求​​

CertificateSigning

此准入控制器获取 CertificateSigningRequest 资源的 ​​status.certificate​​ 字段更新请求并执行额外的授权检查， 以确保签发证书的用户有权限为 spec.signerName 请求 CertificateSigningRequest 资源的证书请求签发证书。

有关对证书签名请求资源执行不同操作所需权限的详细信息， ​​请参阅证书签名请求​​

CertificateSubjectRestrictions

此准入控制器获取具有 ​​kubernetes.io/kube-apiserver-client​​​ 的 ​​spec.signerName​​​ 的 ​​CertificateSigningRequest​​​ 资源创建请求， 它拒绝任何包含了 ​​system:masters​​ 一个“组”（或者“组织”）的请求。

DefaultStorageClass

该准入控制器监测没有请求任何特定存储类的 ​​PersistentVolumeClaim​​​ 对象的创建， 并自动向其添加​​默认存储类​​。 这样，没有任何特殊存储类需求的用户根本不需要关心它们，它们将获得默认存储类。

当未配置默认存储类时，此准入控制器不执行任何操作。如果将多个存储类标记为默认存储类， 它将拒绝任何创建 PersistentVolumeClaim 的操作，并显示错误。 此时准入控制器会忽略任何 PersistentVolumeClaim 更新操作，仅响应创建操作。 要修复此错误，管理员必须重新访问其 StorageClass 对象，并仅将其中一个标记为默认。

关于持久化卷和存储类，以及如何将存储类标记为默认，请参见 ​​持久化卷​​。

DefaultTolerationSeconds

该准入控制器为 Pod 设置默认的容忍度，在 5 分钟内容忍 ​​notready:NoExecute​​​ 和 ​​unreachable:NoExecute​​​ 污点。 （如果 Pod 尚未容忍 ​​node.kubernetes.io/not-ready：NoExecute​​​ 和 ​​node.kubernetes.io/unreachable：NoExecute​​ 污点的话）

DenyExecOnPrivileged

FEATURE STATE: Kubernetes v1.13 [deprecated]

如果一个 pod 拥有一个特权容器，该准入控制器将拦截所有在该 pod 中执行 exec 命令的请求。

此功能已合并至 ​​DenyEscalatingExec​​​。 而 ​​DenyExecOnPrivileged​​​ 准入插件已被废弃，并将在 ​​v1.18​​ 被移除。

建议使用基于策略的准入插件（例如 ​​PodSecurityPolicy​​ 和自定义准入插件）， 该插件可以针对特定用户或名字空间，还可以防止创建权限过高的 Pod。

DenyEscalatingExec

FEATURE STATE: Kubernetes v1.13 [deprecated]

该准入控制器将拒绝在由于拥有升级特权，而具备访问宿主机能力的 Pod 中执行 exec 和 attach 命令。这包括在特权模式运行的 Pod，可以访问主机 IPC 名字空间的 Pod， 和访问主机 PID 名字空间的 Pod 。

​​DenyExecOnPrivileged​​ 准入插件已被废弃，并将在 v1.18 被移除。

建议使用基于策略的准入插件（例如 PodSecurityPolicy 和自定义准入插件）， 该插件可以针对特定用户或名字空间，还可以防止创建权限过高的 Pod。

EventRateLimit

FEATURE STATE: Kubernetes v1.13 [alpha]

该准入控制器缓解了事件请求淹没 API 服务器的问题。集群管理员可以通过以下方式指定事件速率限制：

启用 ​​EventRateLimit​​​ 准入控制器；
从文件中引用 EventRateLimit 配置文件，并提供给 API 服务器命令的 --admission-control-config-file 标志：
apiserver.config.k8s.io/v1

apiserver.k8s.io/v1alpha1
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: EventRateLimit
  path: eventconfig.yaml
...

可以在配置中指定四种类型的限制：

  • ​​Server​​: API 服务器收到的所有事件请求共享一个桶。
  • ​​Namespace​​: 每个名字空间都有一个专用的桶。
  • ​​User​​: 给每个用户都分配一个桶。
  • ​​SourceAndObject​​: 根据事件的源和涉及对象的每种组合分配桶。

下面是一个配置示例 eventconfig.yaml：

apiVersion: eventratelimit.admission.k8s.io/v1alpha1
kind: Configuration
limits:
- type: Namespace
  qps: 50
  burst: 100
  cacheSize: 2000
- type: User
  qps: 10
  burst: 50

详情请参见 事件速率限制提案。

ExtendedResourceToleration

该插件有助于创建​​可扩展资源​​的专用节点。 如果运营商想创建可扩展资源的专用节点（如 GPU、FPGA 等）， 那他们应该以扩展资源名称作为键名， 为节点设置污点。 如果启用了该准入控制器，会将此类污点的容忍自动添加到请求扩展资源的 Pod 中， 用户不必再手动添加这些容忍。

ImagePolicyWebhook

ImagePolicyWebhook 准入控制器允许使用一个后端的 webhook 做出准入决策。

配置文件格式
​​​ImagePolicyWebhook​​ 使用配置文件来为后端行为设置配置选项。该文件可以是 JSON 或 YAML， 并具有以下格式:

imagePolicy:
  kubeConfigFile: /path/to/kubeconfig/for/backend
  # 以秒计的时长，控制批准请求的缓存时间
  allowTTL: 50
  # 以秒计的时长，控制批准请求的缓存时间
  denyTTL: 50
  # 以毫秒计的时长，控制重试间隔
  retryBackoff: 500
  # 确定 Webhook 后端失效时的行为
  defaultAllow: true

从文件中引用 ​​ImagePolicyWebhook​​​ 的配置文件，并将其提供给 API 服务器命令标志 –​​admission-control-config-file​​：

apiserver.config.k8s.io/v1
apiserver.k8s.io/v1alpha1
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ImagePolicyWebhook
  path: imagepolicyconfig.yaml
...

或者，你也可以直接将配置嵌入到文件中：

apiserver.config.k8s.io/v1
apiserver.k8s.io/v1alpha1
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: ImagePolicyWebhook
  configuration:
    imagePolicy:
      kubeConfigFile: <kubeconfig 文件路径>
      allowTTL: 50
      denyTTL: 50
      retryBackoff: 500
      defaultAllow: true

​​ImagePolicyWebhook​​​ 的配置文件必须引用 ​​kubeconfig​​ 格式的文件；该文件设置了到后端的连接参数。 要求后端使用 TLS 进行通信。

kubeconfig 文件的 cluster 字段需要指向远端服务，user 字段需要包含已返回的授权者。

# clusters 指的是远程服务。
clusters:
- name: name-of-remote-imagepolicy-service
  cluster:
    certificate-authority: /path/to/ca.pem    # CA 用于验证远程服务
    server: https://images.example.com/policy # 要查询的远程服务的 URL。必须是 'https' 。

# users 指的是 API 服务器的 Webhook 配置。
users:
- name: name-of-api-server
  user:
    client-certificate: /path/to/cert.pem # webhook 准入控制器使用的证书
    client-key: /path/to/key.pem          # 证书匹配的密钥

关于 HTTP 配置的更多信息，请参阅 ​​kubeconfig 文档​​。

请求载荷
当面对一个准入决策时，API 服务器发送一个描述操作的 JSON 序列化的 ​​​imagepolicy.k8s.io/v1alpha1 ImageReview​​ 对象。 该对象包含描述被审核容器的字段，以及所有匹配 .image-policy.k8s.io/ 的 Pod 注解。

注意，​​Webhook API​​​ 对象与其他 ​​Kubernetes API​​​ 对象一样受制于相同的版本控制兼容性规则。 实现者应该知道对 ​​alpha​​​ 对象的更宽松的兼容性，并检查请求的 “​​apiVersion​​​” 字段， 以确保正确的反序列化。 此外，API 服务器必须启用 ​​imagepolicy.k8s.io/v1alpha1​​​ API 扩展组 （​​--runtime-config=imagepolicy.k8s.io/v1alpha1=true​​）。

请求载荷示例：

{
  "apiVersion":"imagepolicy.k8s.io/v1alpha1",
  "kind":"ImageReview",
  "spec":{
    "containers":[
      {
        "image":"myrepo/myimage:v1"
      },
      {
        "image":"myrepo/myimage@sha256:beb6bd6a68f114c1dc2ea4b28db81bdf91de202a9014972bec5e4d9171d90ed"
      }
    ],
    "annotations":{
      "mycluster.image-policy.k8s.io/ticket-1234": "break-glass"
    },
    "namespace":"mynamespace"
  }
}

远程服务将填充请求的 ImageReviewStatus 字段，并返回允许或不允许访问的响应。 响应体的 “spec” 字段会被忽略，并且可以省略。一个允许访问应答会返回：

{
  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
  "kind": "ImageReview",
  "status": {
    "allowed": true
  }
}
若不允许访问，服务将返回：

{
  "apiVersion": "imagepolicy.k8s.io/v1alpha1",
  "kind": "ImageReview",
  "status": {
    "allowed": false,
    "reason": "image currently blacklisted"
  }
}

更多的文档，请参阅 imagepolicy.v1alpha1 API 对象和 plugin/pkg/admission/imagepolicy/admission.go。

使用注解进行扩展
一个 Pod 中匹配 .image-policy.k8s.io/ 的注解都会被发送给 Webhook。 这样做使得了解后端镜像策略的用户可以向它发送额外的信息，并为不同的后端实现 接收不同的信息。

你可以在这里输入的信息有：

  • 在紧急情况下，请求 “break glass” 覆盖一个策略。
  • 从一个记录了 break-glass 的请求的 ticket 系统得到的一个 ticket 号码。
  • 向策略服务器提供一个提示，用于提供镜像的 imageID，以方便它进行查找。

在任何情况下，注解都是由用户提供的，并不会被 Kubernetes 以任何方式进行验证。 在将来，如果一个注解确定将被广泛使用，它可能会被提升为 ImageReviewSpec 的一个命名字段。

LimitPodHardAntiAffinityTopology

该准入控制器拒绝（定义了 ​​AntiAffinity​​​ 拓扑键的）任何 Pod （​​requiredDuringSchedulingRequiredDuringExecution​​​ 中的 ​​kubernetes.io/hostname​​ 除外）。

LimitRanger

该准入控制器会观察传入的请求，并确保它不会违反 Namespace 中 ​​LimitRange​​​ 对象枚举的任何约束。 如果你在 Kubernetes 部署中使用了 ​​LimitRange​​​ 对象，则必须使用此准入控制器来 执行这些约束。 LimitRanger 还可以用于将默认资源请求应用到没有指定任何内容的 Pod； 当前，默认的 ​​LimitRanger​​​ 对 default 名字空间中的所有 Pod 都应用了 ​​0.1 CPU​​ 的需求。

请查看 ​​limitRange 设计文档​​​ 和 ​​LimitRange​​ 例子 以了解更多细节。

NamespaceAutoProvision

该准入控制器会检查名字空间资源上的所有传入请求，并检查所引用的名字空间是否确实存在。 如果找不到，它将创建一个名字空间。 此准入控制器对于不想要求名字空间必须先创建后使用的集群部署中很有用。

NamespaceExists

该准入控制器检查除 Namespace 以外的名字空间作用域资源上的所有请求。 如果请求引用的名字空间不存在，则拒绝该请求。

NamespaceLifecycle

该准入控制器禁止在一个正在被终止的 Namespace 中创建新对象，并确保 使用不存在的 Namespace 的请求被拒绝。 该准入控制器还会禁止删除三个系统保留的名字空间，即 ​​default​​​、 ​​kube-system​​​ 和 ​​kube-public​​。

删除 Namespace 会触发删除该名字空间中所有对象（Pod、Service 等）的一系列操作。 为了确保这个过程的完整性，我们强烈建议启用这个准入控制器。

NodeRestriction

该准入控制器限制了 kubelet 可以修改的 Node 和 Pod 对象。 为了受到这个准入控制器的限制，kubelet 必须使用在 ​​system:nodes​​​ 组中的凭证， 并使用 ​​system:node:<nodeName>​​ 形式的用户名。 这样，kubelet 只可修改自己的 Node API 对象，只能修改绑定到节点本身的 Pod 对象。

在 Kubernetes 1.11+ 的版本中，不允许 kubelet 从 Node API 对象中更新或删除污点。

在 Kubernetes 1.13+ 的版本中，NodeRestriction 准入插件可防止 kubelet 删除 Node API 对象，并对 kubernetes.io/ 或 k8s.io/ 前缀标签的 kubelet 强制进行如下修改：

  • 防止 kubelet 添加/删除/更新带有​​node-restriction.kubernetes.io/​​​ 前缀的标签。
    保留此前缀的标签，供管理员用来标记 Node 对象以隔离工作负载，并且不允许 kubelet 修改带有该前缀的标签。
  • 允许 kubelet 添加/删除/更新这些和这些前缀的标签：
kubernetes.io/hostname
kubernetes.io/arch
kubernetes.io/os
beta.kubernetes.io/instance-type
node.kubernetes.io/instance-type
failure-domain.beta.kubernetes.io/region （已弃用）
failure-domain.beta.kubernetes.io/zone (已弃用）
topology.kubernetes.io/region
topology.kubernetes.io/zone
kubelet.kubernetes.io/-prefixed labels
node.kubernetes.io/-prefixed labels

kubelet 保留 ​​kubernetes.io​​​ 或 ​​k8s.io​​​ 前缀的所有标签，并且将来可能会被 ​​NodeRestriction​​ 准入插件允许或禁止。

将来的版本可能会增加其他限制，以确保 kubelet 具有正常运行所需的最小权限集。

OwnerReferencesPermissionEnforcement

该准入控制器保护对 ​​metadata.ownerReferences​​​ 对象的访问，以便只有对该对象具有 “删除” 权限的用户才能对其进行更改。 该准入控制器还保护对 ​​metadata.ownerReferences[x].blockOwnerDeletion​​​ 对象的访问， 以便只有对所引用的 属主（owner） 的 ​​finalizers​​ 子资源具有 “更新” 权限的用户才能对其进行更改。

PersistentVolumeLabel

FEATURE STATE: Kubernetes v1.13 [deprecated]

该准入控制器会自动将区（region）或区域（zone）标签附加到由云提供商（如 GCE、AWS） 定义的 PersistentVolume。这有助于确保 Pod 和 PersistentVolume 位于相同的区或区域。 如果准入控制器不支持为 PersistentVolumes 自动添加标签，那你可能需要手动添加标签， 以防止 Pod 挂载其他区域的卷。 PersistentVolumeLabel 已被废弃，标记持久卷已由 云管理控制器接管。 从 1.11 开始，默认情况下禁用此准入控制器。

PodNodeSelector

该准入控制器通过读取​​名字空间注解​​​和​​全局配置​​，来为名字空间中可以使用的节点选择器 设置默认值并实施限制。

配置文件格式
PodNodeSelector 使用配置文件来设置后端行为的选项。 请注意，配置文件格式将在将来某个版本中改为版本化文件。 该文件可以是 JSON 或 YAML，格式如下：

podNodeSelectorPluginConfig:
 clusterDefaultNodeSelector: name-of-node-selector
 namespace1: name-of-node-selector
 namespace2: name-of-node-selector

基于提供给 API 服务器命令行标志 ​​--admission-control-config-file​​ 的文件名， 从文件中引用 PodNodeSelector 配置文件：

apiserver.config.k8s.io/v1
apiserver.k8s.io/v1alpha1
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodNodeSelector
  path: podnodeselector.yaml
...

配置注解格式
PodNodeSelector 使用键为 ​​​scheduler.alpha.kubernetes.io/node-selector​​ 的注解 为名字空间设置节点选择算符。

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    scheduler.alpha.kubernetes.io/node-selector: name-of-node-selector
  name: namespace3

内部行为
该准入控制器行为如下：

  • 如果 Namespace 的注解带有键​​scheduler.alpha.kubernetes.io/node-selector​​​，
    则将其值用作节点选择算符。
  • 如果名字空间缺少此类注解，则使用 PodNodeSelector 插件配置文件中定义的
    ​​​clusterDefaultNodeSelector​​ 作为节点选择算符。
  • 评估​​Pod 节点选择算符​​​和​​名字空间节点选择算符​​是否存在冲突。存在冲突将导致拒绝。
  • 评估​​pod 节点选择算符​​​和​​名字空间的白名单定义的插件配置文件​​是否存在冲突。 存在冲突将导致拒绝。

说明： PodNodeSelector 允许 Pod 强制在特定标签的节点上运行。 另请参阅
PodTolerationRestriction 准入插件，该插件可防止 Pod 在特定污点的节点上运行。

PersistentVolumeClaimResize

该准入控制器检查传入的 PersistentVolumeClaim 调整大小请求，对其执行额外的验证操作。

说明： 对调整卷大小的支持是一种 Alpha 特性。管理员必须将特性门控 ExpandPersistentVolumes 设置为 true才能启用调整大小。

启用 ​​ExpandPersistentVolumes​​​ 特性门控之后，建议将 ​​PersistentVolumeClaimResize​​​ 准入控制器也启用。除非 PVC 的 ​​StorageClass​​​ 明确地将 ​​allowVolumeExpansion​​ 设置为 true 来显式启用调整大小。否则，默认情况下该准入控制器会阻止所有对 PVC 大小的调整。

例如：由以下 StorageClass 创建的所有 PersistentVolumeClaim 都支持卷容量扩充：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gluster-vol-default
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://192.168.10.100:8080"
  restuser: ""
  secretNamespace: ""
  secretName: ""
allowVolumeExpansion: true

关于持久化卷申领的更多信息，​​请参见 PersistentVolumeClaims​​。

PodPreset

该准入控制器根据与 PodPreset 中条件的匹配情况，将指定字段注入一个 Pod。 另请参见 PodPreset 概念和 ​​使用 PodPreset 将信息注入 Pod 了解更多信息​​。

PodSecurityPolicy

此准入控制器负责在创建和修改 Pod 时根据请求的安全上下文和可用的 Pod 安全策略确定是否可以执行请求。

​​查看 Pod 安全策略文档 了解更多细节。​​

PodTolerationRestriction

准入控制器 ​​PodTolerationRestriction​​ 检查 Pod 的容忍度与其名字空间的容忍度之间 是否存在冲突。如果存在冲突，则拒绝 Pod 请求。 然后，它将名字空间的容忍度合并到 Pod 的容忍度中，之后根据名字空间的容忍度 白名单检查所得到的容忍度结果。如果检查成功，则将接受 Pod 请求，否则拒绝该请求。

如果 Pod 的名字空间没有任何关联的默认容忍度或容忍度白名单，则使用集群级别的 默认容忍度或容忍度白名单（如果有的话）。

名字空间的容忍度通过注解健 ​​scheduler.alpha.kubernetes.io/defaultTolerations​​​ 来设置。可接受的容忍度可以通过 ​​scheduler.alpha.kubernetes.io/tolerationsWhitelist​​ 注解键来添加。

名字空间注解的示例：

apiVersion: v1
kind: Namespace
metadata:
  name: apps-that-need-nodes-exclusively
  annotations:
    scheduler.alpha.kubernetes.io/defaultTolerations: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]'
    scheduler.alpha.kubernetes.io/tolerationsWhitelist: '[{"operator": "Exists", "effect": "NoSchedule", "key": "dedicated-node"}]'

优先级

优先级准入控制器使用 priorityClassName 字段并用整型值填充优先级。 如果找不到优先级，则拒绝 Pod。

ResourceQuota

该准入控制器会监测传入的请求，并确保它不违反任何一个 Namespace 中的 ResourceQuota 对象中枚举出来的约束。 如果你在 Kubernetes 部署中使用了 ResourceQuota，你必须使用这个准入控制器来强制 执行配额限制。

请查看 resourceQuota 设计文档和 ​​Resource Quota 例子 了解更多细节。​​

容器运行时类

FEATURE STATE: Kubernetes v1.16 [alpha]

RuntimeClass 定义描述了与运行 Pod 相关的开销。此准入控制器将相应地设置 ​​pod.spec.overhead​​ 字段。

​​详情请参见 Pod 开销​​。

SecurityContextDeny

该准入控制器将拒绝任何试图设置特定提升 SecurityContext 字段的 Pod，正如任务 为 Pod 或 Container 配置安全上下文 中所展示的那样。 如果集群没有使用 Pod 安全策略 来限制安全上下文所能获取的值集，那么应该启用这个功能。

ServiceAccount

此准入控制器实现了 ​​ServiceAccount​​ 的自动化。 如果你打算使用 Kubernetes 的 ServiceAccount 对象，我们强烈建议你使用这个准入控制器。

StorageObjectInUseProtection

​​StorageObjectInUseProtection​​​ 插件将 ​​kubernetes.io/pvc-protection​​​ 或 ​​kubernetes.io/pv-protection finalizers​​ 添加到新创建的持久化卷声明（PVC） 或持久化卷（PV）中。 如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除 finalizers，否则 PVC/PV 不会被删除。 有关更多详细信息，请参考 保护使用中的存储对象。

TaintNodesByCondition

FEATURE STATE: Kubernetes v1.12 [beta]

该准入控制器为新创建的节点添加 ​​NotReady​​​ 和 ​​NoSchedule​​ 污点。 这些污点能够避免一些竞态条件的发生，这类静态条件可能导致 Pod 在更新节点污点以准确 反映其所报告状况之前，就被调度到新节点上。

ValidatingAdmissionWebhook

FEATURE STATE: Kubernetes v1.13 [beta]

该准入控制器调用与请求匹配的所有验证 Webhook。 匹配的 Webhook 将被并行调用。如果其中任何一个拒绝请求，则整个请求将失败。 该准入控制器仅在验证（Validating）阶段运行；与 MutatingAdmissionWebhook 准入控制器 所调用的 Webhook 相反，它调用的 Webhook 应该不会使对象出现变更。

如果以此方式调用的 Webhook 有其它作用（如，降低配额），则它必须具有协调机制。 这是因为无法保证后续的 Webhook 或其他有效的准入控制器都允许请求完成。

如果你禁用了 ValidatingAdmissionWebhook，还必须通过 --runtime-config 标志来禁用 admissionregistration.k8s.io/v1beta1 组/版本中的 ValidatingWebhookConfiguration 对象（默认情况下在 1.9 版和更高版本中均处于启用状态）

MutatingAdmissionWebhook

FEATURE STATE: Kubernetes v1.13 [beta]

该准入控制器调用任何与请求匹配的变更 ​​Webhook​​。匹配的 Webhook 将被串行调用。 每一个 Webhook 都可以根据需要修改对象。

​​MutatingAdmissionWebhook​​，顾名思义，仅在变更阶段运行。

如果由此准入控制器调用的 Webhook 有副作用（如降低配额）， 则它 必须 具有协调系统，因为不能保证后续的 Webhook 和验证准入控制器都会允许完成请求。

如果你禁用了 ​​MutatingAdmissionWebhook​​​，那么还必须使用 ​​--runtime-config​​​ 标志禁止 ​​admissionregistration.k8s.io/v1beta1​​​ 组/版本中的 ​​MutatingWebhookConfiguration​​​ 对象（版本 ​​>=1.9​​ 时，这两个对象都是默认启用的）。

谨慎编写和安装变更 webhook
当用户尝试创建的对象与返回的对象不同时，用户可能会感到困惑。
当它们回读的对象与尝试创建的对象不同，内建的控制环可能会出问题。
与覆盖原始请求中设置的字段相比，使用原始请求未设置的字段会引起问题的可能性较小。 应尽量避免前面那种方式。
这是一个 beta 特性。Kubernetes 未来的版本可能会限制这些 Webhook 可以进行的变更类型。
内建资源和第三方资源的控制回路未来可能会受到破坏性的更改，使现在运行良好的 Webhook 无法再正常运行。即使完成了 Webhook API 安装，也不代表会为该 webhook 提供无限期的支持。