本文围绕 Kubernetes 集群的证书体系架构展开，清晰梳理了集群内部各类证书的签发机构、持有者及核心作用。

一、Kubernetes CA 签发的证书

1. 管理员用户客户端证书 → API Server

• 用途：人类管理员或自动化脚本通过 kubectl 等工具访问 API Server，执行集群管理操作（如创建 / 删除资源、查看状态、执行命令等）。

• 认证方式：API Server 验证客户端证书，确认管理员身份与权限。

2. Scheduler 客户端证书 → API Server

• 用途：Kubernetes Scheduler 向 API Server 上报调度决策、获取待调度的 Pod 信息、更新 Pod 的调度状态。

• 认证方式：API Server 验证 Scheduler 身份，确保只有合法的调度器能修改 Pod 调度信息。

3. Controller Manager 客户端证书 → API Server

• 用途：Controller Manager 中的各类控制器（如 Deployment、ReplicaSet、Node 控制器）向 API Server 监听资源变化、执行 reconcile 操作、更新资源状态。

• 认证方式：API Server 验证 Controller Manager 身份，确保控制器操作的合法性。

4. Kubelet 客户端证书 → API Server

• 用途：

  • 节点注册：Kubelet 首次启动时向 API Server 注册节点。

  • 状态上报：定期上报节点资源使用情况、节点健康状态、Pod 运行状态。

  • 事件上报：向 API Server 发送节点和 Pod 的事件信息。

• 认证方式：API Server 验证 Kubelet 身份，确保只有合法的节点才能加入集群并上报信息。

5. API Server 客户端证书 → Kubelet

• 用途：API Server 主动向 Kubelet 发起操作，如：

  • 获取容器日志（kubectl logs）

  • 在容器内执行命令（kubectl exec）

  • 端口转发（kubectl port-forward）

  • 附加到容器（kubectl attach）

• 认证方式：Kubelet 验证 API Server 身份，确保只有合法的控制平面才能执行这些操作。

二、Etcd CA 签发的证书

1. etcd client 客户端证书（持有者：API Server） → etcd server

• 用途：API Server 作为 etcd 的客户端，读写集群的核心状态数据（所有 Kubernetes 对象的定义与状态）。

• 认证方式：etcd server 验证 API Server 身份，确保只有合法的控制平面组件能访问集群数据存储。

2. etcd peer 对等通信证书（持有者：etcd 节点） → 其他 etcd 节点

• 用途：etcd 集群内部节点之间的数据同步、选举、故障转移等对等通信。

• 认证方式：etcd 节点之间相互验证身份，确保集群数据一致性和安全性。

三、Front Proxy CA 签发的证书

Front Proxy Client 客户端证书（持有者：聚合层 API 服务器） → API Server

• 用途：聚合层 API 服务器（如 metrics-server、自定义 APIService）向主 API Server 注册扩展 API，并处理来自用户的扩展 API 请求。

• 认证方式：API Server 验证聚合层客户端身份，确保只有合法的扩展 API 服务能接入集群。

四、ServiceAccount 密钥对

• 用途：

  • 为 Pod 中的服务账户（ServiceAccount）签发 ServiceAccount Tokens。

  • Pod 内的应用使用这些 Token 向 API Server 进行身份认证，执行授权操作（如访问集群资源）。

• 认证方式：API Server 验证 Token 签名，确认服务账户的身份与权限。

整体来看，Kubernetes 证书体系通过分层的信任链设计，实现了核心组件间的安全通信、身份认证与扩展能力，是保障集群安全稳定运行的关键基础设施。