Kubernetes 组件——API Server 专栏导览
专栏定位
API Server 是 Kubernetes 的中枢神经系统——集群中的所有组件（kubelet、Scheduler、Controller Manager、kubectl、CRD 控制器）都通过 API Server 交互，没有任何组件之间的直接通信。理解 API Server，就理解了 K8s 的”通信总线”和”门禁系统”。
本专栏深入 API Server 的内部工作机制：一个 HTTP 请求从进入 API Server 到写入 etcd 再到通过 Watch 通知其他组件，经历了哪些处理阶段？认证（Authentication）、授权（Authorization）、准入控制（Admission Control）这三道关卡各自解决什么问题？List-Watch 机制如何保证最终一致性？
前置知识：架构原则与对象设计专栏（API 对象模型、GVR/GVK、etcd 基础）。
目录
| 序号 | 文章 | 核心内容 |
|---|---|---|
| 01 | 01 API Server 的角色与整体架构 | API Server 作为唯一的 etcd 入口、RESTful API 设计、请求处理管线（Handler Chain）、聚合 API Server（Aggregation Layer） |
| 02 | 02 认证机制深度解析 | X.509 客户端证书、Bearer Token、ServiceAccount Token、OIDC 集成、认证代理、Bootstrap Token、认证链的执行逻辑 |
| 03 | 03 授权机制——RBAC 深度解析 | RBAC 模型（Role/ClusterRole/RoleBinding/ClusterRoleBinding）、权限粒度（verbs × resources × namespace）、内置角色、最小权限设计模式、Node 授权器 |
| 04 | 04 准入控制器深度解析 | Mutating vs Validating Admission、内置准入控制器（LimitRanger、ResourceQuota、PodSecurity）、Webhook 动态准入（MutatingWebhookConfiguration / ValidatingWebhookConfiguration）、准入控制的执行顺序 |
| 05 | 05 List-Watch 机制与 Informer 框架 | Watch 的 HTTP 长连接实现、ResourceVersion 与乐观并发、Informer 的本地缓存与事件分发（Reflector → DeltaFIFO → Indexer）、SharedInformer 的设计、Watch Bookmark 优化 |
| 06 | 06 API Server 性能调优与高可用 | 请求限流（APF: API Priority and Fairness）、etcd 请求优化、多实例部署与负载均衡、审计日志、API Server 的关键指标与告警 |
推荐阅读路径
- 理解请求全链路：01 → 02 → 03 → 04（一个请求从进入到落地）
- 深入事件驱动：01 → 05（Watch/Informer 是控制器专栏的前置）
- 生产运维：01 → 06