上一篇【第59篇】K8s安全审计——用CIS Benchmark和扫描工具给集群“体检“下一篇【第61篇】etcd——K8s的记忆中枢深度解析摘要从这篇文章开始咱们进入K8s的内核——核心组件原理。第一个也是最重要的一个API Server。你可以把整个K8s想象成一个公司。etcd是档案室唯一存数据的地方各个控制器是各部门员工而API Server就是前台兼总机——所有电话请求都先打到前台前台验证身份、查权限、做登记再去档案室取放文件。没有前台公司就乱套了。为什么K8s要这么设计因为解耦。所有组件都只跟API Server说话不直接访问etcd也不互相直接调用。这让K8s的扩展性和健壮性上了大台阶。这篇文章拆开API Server的架构、它的REST API设计、版本管理以及最关键的Watch机制。一、为什么只有一个API Server逻辑上1.1 所有流量都过它【K8s 的星型拓扑——API Server是绝对中心】 kubectl / Dashboard / Operator / Controller │ │ │ │ └──────┼──────┼──────┘ ▼ ┌──────────────┐ │ API Server │ ← 唯一入口 └──────┬───────┘ ▼ ┌──────────────┐ │ etcd │ ← 唯一存储 └──────────────┘ 其他组件(kubelet/scheduler/controller-manager): • 不直接写etcd • 通过API Server的REST API操作资源 • 通过Watch监听资源变化要点这种所有组件只跟API Server交互的设计叫枢纽模式。好处巨大(1)统一的安全边界——所有认证授权只在API Server做一处(2)统一的一致性校验——所有写入都过Admission(3)etcd可以藏在后面只需给API Server授权。坏处是API Server成了瓶颈所以要高性能、可水平扩展。二、API Server的架构2.1 请求处理链一个请求进API Server要经过一条精心设计的处理链【API Server 请求处理流水线】 请求 ──► [Handler Chain] │ ├─ 1. TLS终止 (HTTPS解密) ├─ 2. Authentication (你是谁) ├─ 3. Authorization (你能干啥) ├─ 4. Admission Control (改/拒) │ ▼ [Mutation Admission] ← MutatingWebhook改请求 │ ▼ [Validation Admission]← ValidatingWebhook校验 │ ▼ [Schema校验] ← OpenAPI校验字段合法性 │ ▼ [etcd读写] ← 真正落地 │ ▼ 响应返回2.2 Aggregator层扩展API【API Server 还能挂外挂——Aggregated API】 核心API Server 管内置资源(Pod/Service/Deployment...) │ ├── 普通请求 → 自己处理 │ └── apis/custom.example.com/* → 转发给 扩展API Server (你自己的服务!) │ ▼ 你的Custom Resource由你的服务处理 (这就是CRD/Operator的底层机制见第072篇)三、REST API设计3.1 资源与子资源K8s的API是典型的REST风格【K8s REST API 结构】 GET /api/v1/namespaces/default/pods └ 列出default ns的所有Pod POST /api/v1/namespaces/default/pods └ 创建一个Pod GET /api/v1/namespaces/default/pods/nginx └ 获取名为nginx的Pod DELETE /api/v1/namespaces/default/pods/nginx └ 删除它 子资源 (Subresource)——不是完整资源是资源的某个方面 GET /api/v1/namespaces/default/pods/nginx/log └ 子资源: 这个Pod的日志 GET /api/v1/namespaces/default/pods/nginx/status └ 子资源: 状态(由kubelet更新用户改不了spec) POST /api/v1/namespaces/default/pods/nginx/exec └ 子资源: 进入容器执行命令概念说明例子资源(Resource)顶级对象pods, services, deployments子资源(Subresource)资源的某方面status, log, exec, scale集合(Collection)一类资源的列表/pods命名资源单个实例/pods/nginx要点spec和status是分开的——spec是你期望的状态用户改status是实际状态kubelet/控制器更新。这个分离是声明式API的核心你只声明想要啥API Server存你的声明控制器负责让现实靠拢声明。exec/log这些子资源让用户能进容器、看日志但背后也是API Server转发给kubelet。四、API版本管理4.1 为什么有这么多版本【API 版本演进——稳定分三六九等】 alpha (v1alpha1): 实验性可能随时删默认关闭 beta (v1beta1): 基本稳定但API可能变默认开启 stable(v1): 稳定承诺不会随便改 例子 apps/v1 ← Deployment稳定版(现在都用它) apps/v1beta1 ← 老beta版(已废弃) networking.k8s.io/v1 ← Ingress稳定版 networking.k8s.io/v1beta1 ← 老版(字段不一样)# 看集群支持哪些API版本kubectl api-versions# apps/v1# networking.k8s.io/v1# rbac.authorization.k8s.io/v1# ...# 看某资源支持的版本kubectl explain deployment.apiVersion4.2 废弃策略K8s对API废弃有严格规则一个API版本至少要保留两个小版本才能删。比如v1beta1在1.22废弃1.25才彻底移除。这给了用户充足迁移时间。升级集群前务必检查有没有用到即将删除的API用kubectl deprecations或pluto工具。五、Watch机制——实时同步的秘密5.1 List-Watch【Watch——别轮询了我变了通知你】 传统轮询(低效): client每5秒 GET /pods → 99%的请求返回没变化 → 浪费带宽和API Server性能 K8s Watch(高效): client发 GET /pods?watchtrue (长连接) API Server保持连接打开 当Pod有变化(增删改) → 立刻推一条事件给client event: {type: ADDED/ MODIFIED/ DELETED, object: {...}} 这就是所有控制器实时感知变化的基础 (Informer机制见第063篇就是基于Watch)# 自己体验Watchkubectl get pods-w# NAME READY STATUS ...# nginx 1/1 Running ← 开了watch# 另一个终端 kubectl delete pod nginx# → 这里立刻看到 DELETED 事件# 底层就是HTTP chunked传输curl-k-HAuthorization: Bearer$TOKEN\https://api-server/api/v1/namespaces/default/pods?watchtrue# 会持续收到JSON事件流要点Watch是K8s声明式自愈能力的通信基础。所有控制器scheduler、controller-manager、kubelet、Operator都通过Watch实时感知资源变化然后做出反应。它用HTTP长连接分块传输实现比轮询高效几个数量级。理解了Watch你就理解了为什么K8s能秒级响应变更。本篇小结API Server是K8s的逻辑中心——所有组件、工具、Operator只跟它对话它再和etcd交互。这种设计叫枢纽模式带来了统一安全边界、统一校验、etcd可隐藏三大好处。它的请求处理链是TLS→认证→授权→准入改/验→Schema校验→etcd读写。REST API用资源/子资源组织spec和status分离是声明式核心。API版本分alpha/beta/stable三级废弃有严格保护期。Watch机制长连接推送变更是所有控制器实时同步的底层秘密。下篇讲etcd——K8s唯一的记忆中枢。上一篇【第59篇】K8s安全审计——用CIS Benchmark和扫描工具给集群“体检“下一篇【第61篇】etcd——K8s的记忆中枢深度解析