4. kube-apiserver 架构：API Server 请求处理流程、认证模块选型

kube-apiserver 是 Kubernetes 控制平面的前端网关与数据总线。所有对集群状态的查询、变更、监听操作都必须经过 apiserver。理解其请求处理流水线，以及认证模块的选型策略，是构建生产级集群的基石。

4.1 请求处理全流程

一个典型的 kubectl apply -f pod.yaml 请求，从客户端到达 etcd 存储，会依次经过以下 6 个阶段：

1. HTTP(S) 接收：apiserver 监听 6443（安全端口）或 8080（非安全端口，生产禁用）。
2. 认证（Authentication）：从请求中提取身份信息，验证客户端身份合法性。
3. 授权（Authorization）：判断已认证的用户/ServiceAccount 是否有权限执行请求操作。
4. 准入控制（Admission Control）：通过一系列插件对请求对象进行修改或校验。
5. 对象校验与持久化：对资源对象进行 schema 校验，并序列化写入 etcd。
6. 响应返回：将操作结果或 watch 事件返回给客户端。

4.2 认证模块选型对比

Kubernetes 支持多种认证策略，可同时启用多个 authenticator。请求到达时，apiserver 按顺序尝试每个 authenticator，只要有一个成功即通过认证。生产环境最常用的三种策略如下：

4.3 X509 客户端证书认证详解

X509 认证是 Kubernetes 最底层的身份验证机制。apiserver 启动时通过 --client-ca-file 指定 CA 证书，所有携带由该 CA 签发的客户端证书的请求均被信任。

• 身份提取规则：证书的 CN（Common Name）作为用户名，O（Organization）作为用户组。例如 CN=admin, O=system:masters 会被识别为 admin 用户，属于 system:masters 组。
• 典型用途：kubelet 使用 kubelet-client 证书向 apiserver 注册节点；kube-controller-manager 和 kube-scheduler 使用独立的客户端证书与控制面通信。
• 证书轮换：Kubernetes 1.20+ 支持 kubelet 证书自动轮换（--rotate-certificates），但管理员证书仍需手动或通过 cert-manager 管理。

# 使用 openssl 生成客户端证书示例
openssl genrsa -out admin.key 2048
openssl req -new -key admin.key -out admin.csr -subj "/CN=admin/O=system:masters"
openssl x509 -req -in admin.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out admin.crt -days 365

# 将证书写入 kubeconfig
kubectl config set-credentials admin --client-certificate=admin.crt --client-key=admin.key
kubectl config set-context admin-context --cluster=my-cluster --user=admin

4.4 ServiceAccount 认证详解

ServiceAccount 是 Pod 内应用访问 API 的标准方式。每个 Namespace 会自动创建一个 default ServiceAccount，并挂载对应的 JWT 到 Pod 中。

• 类型：Kubernetes 1.24+ 默认使用 Bound Service Account ，该 绑定到特定 ServiceAccount、Pod 和节点，具有更短的过期时间（默认 1 年）且支持自动轮换。
• 验证：apiserver 使用 --service-account-key-file 指定的公钥验证 签名。 中携带 ServiceAccount 名称和 Namespace，apiserver 将其映射为 user: system:serviceaccount:<ns>:<sa-name>。
• 安全实践：每个应用使用独立的 ServiceAccount，并通过 RBAC 授予最小权限。禁止使用 default ServiceAccount 执行敏感操作。

# 创建专用 ServiceAccount 并绑定 RBAC
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: production
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-app-sa-binding
  namespace: production
subjects:
- kind: ServiceAccount
  name: my-app-sa
  namespace: production
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

4.5 OIDC 认证详解

OIDC 允许 Kubernetes 集群信任外部身份提供商（IdP），实现单点登录（SSO）和集中式用户管理。apiserver 通过 OIDC 发现端点获取 IdP 的公钥和配置，验证客户端提交的 ID 。

• 核心参数：--oidc-issuer-url（IdP 地址）、--oidc-client-id（集群在 IdP 注册的客户端 ID）、--oidc-username-claim（从 中提取用户名的字段，通常为 email 或 sub）。
• 验证流程：客户端从 IdP 获取 ID （JWT 格式），在 kubectl 或 API 请求中通过 -- 或 Authorization: Bearer 头传递。apiserver 使用 IdP 的 JWKS 端点验证签名、issuer 和 audience。
• 组映射：通过 --oidc-groups-claim 指定从 中提取用户组的字段（如 groups），Kubernetes 将其映射为 RBAC 绑定的组名。

4.6 认证模块组合策略

生产集群通常同时启用 X509 和 ServiceAccount 认证，并根据企业需求叠加 OIDC。以下推荐组合：