基于本文回答

播面 播面

文图音视，全方位拆解八股文
0
评论
请从左侧选择一个分类

kube-apiserver 的主要功能是什么？它是如何处理请求的？

知识点图片

kube-apiserver 是 Kubernetes 控制平面（Control Plane）的核心组件，被视为 Kubernetes 集群的大脑或统一入口。

它是所有组件（包括用户命令、控制平面其他组件、工作节点）之间通信的枢纽。

以下是关于它的主要功能及请求处理流程的详细解析：

一、 kube-apiserver 的主要功能

  1. 集群的统一入口（API Gateway）

    • 它是集群中唯一对外暴露的组件。无论是用户通过 kubectl 操作，还是 Dashboard UI，或者是集群内部的组件（如 Scheduler, Controller Manager, Kubelet），都必须通过 API Server 进行交互。
    • 它提供了 RESTful API 接口，用于对 Kubernetes 资源（如 Pods, Services, Deployments 等）进行 CRUD（增删改查）操作。

  2. 状态存储与管理（唯一与 etcd 交互）

    • 关键点： 在 Kubernetes 架构中，只有 kube-apiserver 直接与后端存储 etcd 通信。
    • 其他所有组件如果需要读取或保存集群状态，都必须经过 API Server，绝不能直接访问 etcd。这确保了数据的一致性和访问控制。

  3. 安全网关（Security）

    • 它负责拦截所有请求，执行认证（Authentication）、鉴权（Authorization）和准入控制（Admission Control），确保只有合法的用户和组件才能操作集群资源。

  4. 数据版本控制与转换

    • Kubernetes API 支持多版本（如 v1, v1beta1）。API Server 负责处理不同 API 版本之间的数据转换，确保存储在 etcd 中的数据格式统一，同时兼容不同版本的客户端。

  5. 通知与协调机制（Watch 机制）

    • API Server 实现了 List-Watch 机制。当资源状态发生变化（例如创建一个 Pod）并写入 etcd 后，API Server 会主动通过长连接将变更事件“推送”给感兴趣的组件（如 Scheduler 或 Kubelet）。这是 Kubernetes 实现“声明式 API”和“最终一致性”的基石。

二、 kube-apiserver 是如何处理请求的？

当一个请求（例如 kubectl apply -f pod.yaml）发送到 API Server 时，它会经过一个严格的处理管道（Pipeline）。

流程如下图所示：

HTTP 请求 -> [认证] -> [鉴权] -> [准入控制(变更)] -> [格式验证] -> [准入控制(验证)] -> [存入 etcd]

1. 认证 (Authentication - AuthN)

  • 问题： "你是谁？"
  • 动作： API Server 检查请求中的凭证（如 TLS 客户端证书、Bearer Token、ServiceAccount 等）。
  • 结果： 如果认证失败，返回 401 Unauthorized；如果成功，提取出用户名（User）和组（Group）信息，进入下一步。

2. 鉴权 (Authorization - AuthZ)

  • 问题： "你有权限做这件事吗？"
  • 动作： 根据提取的用户信息，检查该用户是否有权限对目标资源执行特定操作（例如：用户 Bob 是否有权限在 default 命名空间下 create Pods）。
  • 机制： 最常用的是 RBAC (Role-Based Access Control)。
  • 结果： 如果无权限，返回 403 Forbidden；如果有权限，进入下一步。

3. 变更准入控制 (Mutating Admission Control)

  • 问题： "我需要修改这个请求吗？"
  • 动作： 在对象被验证之前，修改对象的内容。
  • 例子：
    • ServiceAccount 控制器：如果 Pod 没有指定 ServiceAccount，这里会自动补上 default。
    • Sidecar Injection（如 Istio）：自动在 Pod 定义中注入 Envoy 容器。
    • ResourceQuota：如果没有设置资源限制，可能会补上默认的 Limit/Request。

4. 格式验证 (Schema Validation)

  • 问题： "这个对象的格式对吗？"
  • 动作： 检查请求体中的 JSON/YAML 是否符合 Kubernetes API 对象的定义（Schema）。
  • 检查点： 必填字段是否存在？字段类型是否正确（是数字还是字符串）？

5. 验证准入控制 (Validating Admission Control)

  • 问题： "这个请求的内容逻辑合法吗？"
  • 动作： 进行复杂的逻辑校验，拒绝不合规的请求（此时不再修改对象，只做判断）。
  • 例子：
    • 检查集群是否有足够的配额（ResourceQuota）。
    • 检查是否符合 Pod 安全策略（如禁止以 root 运行）。
    • 自定义策略（如 OPA Gatekeeper）：检查标签是否符合公司规范。
  • 结果： 如果任何一个验证控制器拒绝，请求失败。

6. 数据持久化 (Storage / Registry)

  • 动作： 如果通过了上述所有关卡，API Server 会将对象转换为存储版本（Storage Version），并将其序列化（通常是 ProtoBuf 格式）。
  • 交互： 调用 etcd 接口，将数据写入 etcd 集群。

7. 响应与通知 (Response & Watch)

  • 响应： 一旦 etcd 写入成功，API Server 向客户端返回 HTTP 200/201 成功响应。
  • 通知： 同时，API Server 触发 Watch 机制，通知所有正在监听该资源变化的组件（例如 Scheduler 收到通知：有一个新 Pod 创建了，由于还没调度，Scheduler 开始工作）。

总结

kube-apiserver 是一个无状态的组件（状态都在 etcd 里），这使得它可以轻松地进行横向扩展（运行多个实例以实现高可用）。

它的处理流程设计体现了 Kubernetes 的核心哲学：

  1. 零信任（必须经过认证鉴权）。
  2. 可扩展性（通过准入控制 Webhook，用户可以介入请求处理流程）。
  3. 声明式（通过 Watch 机制驱动整个集群向期望状态收敛）。
00:00
00:00