kube-apiserver
集群的唯一对外网关
底座认知 · 第 04 篇
所有请求的唯一入口，承载认证、授权与准入
目 录
一、apiserver 的定位
二、一次请求的必经三关
2.1 认证（Authentication）
2.2 授权（Authorization）
2.3 准入控制（Admission Control）
三、与 etcd 的关系
四、高可用部署
五、常用排障命令
一、apiserver 的定位
kube-apiserver 是整个集群的「大脑中枢」与「唯一网关」。集群内所有组件的通信、所有用户/管理工具的请求，都必须经过它，不存在旁路。
- 用户：kubectl、Dashboard、各种 operator 通过它管理集群
- 组件：scheduler、controller-manager、kubelet 都通过它读写状态
- etcd：只有 apiserver 能直接读写 etcd，其他组件均绕行 apiserver
正因如此，apiserver 是认证、授权、准入控制的集中执行点，也是安全加固的核心。
二、一次请求的必经三关
任何请求进入 apiserver，都要依次通过三道关卡，全部通过才会真正作用于集群状态。
2.1 认证（Authentication）
确认「你是谁」。apiserver 支持多种认证方式，典型包括：
- 客户端证书（X.509，kubeadm 默认用此方式）
- Bearer Token（含 ServiceAccount 的 JWT）
- 用户名/密码、OpenID Connect 等
2.2 授权（Authorization）
确认「你能做什么」。默认采用 RBAC（基于角色的访问控制），核心概念是 Role / ClusterRole 与 RoleBinding / ClusterRoleBinding。
2.3 准入控制（Admission Control）
在对象「落库前」做最后一道校验或修改，是安全与策略的守门员。
- 校验类：LimitRanger、ResourceQuota 等检查配额
- 修改类：MutatingAdmissionWebhook、默认标签注入等
- 安全类：Pod Security Admission（PSA）强制 Pod 安全级别
三、与 etcd 的关系
apiserver 是 etcd 唯一的前端。它把请求转换为对 etcd 的读写，并负责：
- 将声明式对象持久化到 etcd
- watch etcd 的变更，主动通知其他组件（如 scheduler、kubelet）
- 提供数据的缓存与聚合，减轻 etcd 压力
理解这一点对排障极重要：状态变更「以 etcd 为准」，但访问永远走 apiserver。
四、高可用部署
生产环境通常部署多个 apiserver 副本，前置负载均衡（如 HAProxy + VIP（虚拟 IP））对外提供稳定入口。在 Rocky9 高可用集群中：
- controlPlaneEndpoint 指向 VIP，使 kubeadm 初始化的集群对外暴露统一入口
- 多个 apiserver 共享同一 etcd 集群，保证状态一致
- apiserver 是水平可扩展的：多副本只是负载分担，无主从之分
五、常用排障命令
- kubectl get --raw=/healthz：apiserver 健康检查
- kubectl auth can-i get pods：检查当前用户权限
- journalctl -u kube-apiserver -f：查看 apiserver 日志
- kubectl logs -n kube-system <apiserver-pod>：容器方式查看日志
下一篇《etcd》，看看 apiserver 背后的这个「状态权威」如何存储与保证一致。