what-happens-in-kubernetes-when-a-request-hits-kube-apiserver.md

当一个请求到达 kube-apiserver 时，Kubernetes 内部发生了什么？

我们通常使用 kubectl 来与我们的 Kubernetes 集群进行交互作业。当 kubectl 构造的一个 REST 请求到达 kube-apiserver 时，它会经历多个阶段。

与通用的 API 安全性和可靠性规范一样，请求到达 apiserver 时，也需要经过经典的三个步骤，如下图所示：

1. 认证：验证发起 API 请求的用户的身份；

2. 鉴权：鉴别发起 API 请求的用户的权限；

3. 准入控制：变更（Mutating）和验证（Validating）传入的请求数据；

认证

kube-server 支持多个类型的身份认证方式，包含客户端证书、密码、普通令牌、引导令牌和 JSON Web 令牌等。具体使用哪一种（或者哪几种）认证方式是由集群管理员设置的。 如果请求认证不通过，服务器将以 HTTP 状态码 401 拒绝该请求。 反之，该用户被认证为特定的 username，并且该用户名可用于后续步骤以在其决策中使用。

鉴权

如上图的步骤 2 所示，将请求验证为来自特定的用户后，请求必须被鉴权。 请求必须包含请求者的用户名、请求的行为以及受该操作影响的对象。 如果现有策略声明用户有权完成请求的操作，那么该请求被鉴权通过。反之，服务器将以 HTTP 状态码 403 拒绝该请求。

准入控制

准入控制器是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API 服务器的请求，如上图的步骤 3 所示。 准入控制器可以执行 “验证（Validating）” 和/或 “变更（Mutating）” 操作。 变更（mutating）控制器可以修改被其接受的对象；验证（validating）控制器则不行。 准入控制过程分为两个阶段。第一阶段，运行变更准入控制器。第二阶段，运行验证准入控制器。 再次提醒，某些控制器既是变更准入控制器又是验证准入控制器。 如果任何一个阶段的任何控制器拒绝了该请求，则整个请求将立即被拒绝，并向终端用户返回一个错误。