download： 14小时吃透Spring5新特性,重点讲解WebFlux响应式编程

如上图所示，每个 API 的请求从开始被 kube-apiserver 接收到最终持久化到 ETCD 的过程，即为 Kubernetes API 的请求处理流程。

它主要包含了以下几个部分：

API Handler -- 主要负责提供服务，接收请求。

对于其内部实现而言，请求会先到 FullHandlerChain （它是由 DefaultBuildHandlerChain 构建出来的）是一个 director 对象

type director struct {
    name               string
    goRestfulContainer *restful.Container
    nonGoRestfulMux    *mux.PathRecorderMux
}

director根据配置进行初始化，如果 goRestfulContainer的 WebServices 的 RootPath 是 /apis，或者请求前缀与 RootPath 匹配，则进入 Restful 处理链路。

Authentication -- 认证的流程。

在TLS 连接建立后，会进行认证处理，如果请求认证失败，会拒绝该请求并返回 401 错误码；如果认证成功，将进行到鉴权的部分。目前支持的客户端认证方式有很多，例如：x509 客户端证书、Bearer Token、基于用户名密码的认证、OpenID 认证等。由于这些内容不是本篇的重点我们暂且跳过，感兴趣的小伙伴可以在评论区留言讨论。

Authorization -- 鉴权的流程。

对于 Kubernetes 而言，支持多种的鉴权模式，例如，ABAC 模式，RBAC 模式和 Webhook 模式等。我们在创建集群时，可以直接为 kube-apiserver 传递参数进行配置，这里也不赘述了。

Mutating Admission -- 指执行可用于变更操作的准入控制器，下文中会详细介绍。

Object Schema Validation -- 对资源对象的 schema 校验。

Validating Admission -- 指执行可用于验证操作的准入控制器，下文中会详细介绍。

ETCD -- ETCD 实现资源的持久化存储。

上面便是一个请求的处理流程，其中 Mutating Admission 和 Validating Admission 便是我们今天的主角。我们来详细的看一看。

什么是准入控制器（Admission Controller）

准入控制器是指在请求通过认证和授权之后，可用于对其进行变更操作或验证操作的一些代码或功能。

准入控制的过程分为两个阶段：

第一阶段，运行变更准入控制器（Mutating Admission）。它可以修改被它接受的对象，这就引出了它的另一个作用，将相关资源作为请求处理的一部分进行变更；

第二阶段，运行验证准入控制器（Validating Admission）。它只能进行验证，不能进行任何资源数据的修改操作；

需要注意的是，某些控制器可以既是变更准入控制器又是验证准入控制器。如果任一个阶段的准入控制器拒绝了该请求，则整个请求将立即被拒绝，并向终端用户返回错误。

为什么需要准入控制器 Admission Controller

我们主要从两个角度来理解为什么我们需要准入控制器：

从安全的角度

- 我们需要明确在 Kubernetes 集群中部署的镜像来源是否可信，以免遭受攻击；
- 一般情况下，在 Pod 内尽量不使用 root 用户，或者尽量不开启特权容器等；

从治理的角度

- 比如通过 label 对业务/服务进行区分，那么可以通过 admission controller 校验服务是否已经有对应的 label 存在之类的；
- 比如添加资源配额限制，以免出现资源超卖之类的情况；

准入控制器

考虑到这些需求比较有用 & 确实也比较需要，所以 Kubernetes 目前已经实现了很多内置的 Admission Controller 。可以参考官方文档来获取详细列表： kubernetes.io/docs/re...

这些内置的 Admission Controller 都是以插件的方式与 kube-apiserver 构建到一起的，你可以对其进行启用和关停。比如用如下参数进行控制：

这么多的准入控制器中有两个比较特别，分别是 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。它们并没有真正执行相应的策略，而是为 kube-apiserver 提供了一种可扩展的方式，用户可以通过配置 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 来使用自构建的服务，而且这种方式是无需对 kube-spiserver 执行编译或者重启，完全是动态的，非常的方便。