2. K8s 证书体系基础：K8s 中 TLS 证书的作用、CA 证书、服务端证书、客户端证书、kubeconfig 中的证书

2.1 为什么 Kubernetes 需要 TLS 证书

Kubernetes 控制面组件（API Server、etcd、kubelet、scheduler、controller-manager）之间以及组件与客户端（kubectl、Pod）之间的所有通信，默认都要求双向 TLS 加密。证书体系解决了三个核心问题：

• 身份认证：确认通信对方的身份，防止中间人攻击。
• 传输加密：确保 API 请求和响应在传输过程中不被窃听或篡改。
• 授权基础：证书中的 CN（Common Name）或组织（O）字段通常映射到 RBAC 用户或组，是权限控制的起点。

2.2 证书体系核心角色

K8s 证书体系分为三个层次：CA 证书（签发者）、服务端证书（提供服务的组件）、客户端证书（调用服务的组件）。

2.3 证书签发与信任链

K8s 采用自签名 CA 模式，不依赖外部公共 CA。信任链如下：

1. 根 CA 自签生成 ca.crt（公钥）和 ca.key（私钥）。
2. 根 CA 使用自己的私钥为每个组件签发组件证书（服务端或客户端）。
3. 组件证书中携带签发者信息（Issuer = 根 CA 的 Subject）。
4. 验证时，验证方使用本地信任的 ca.crt 检查组件证书的签名是否匹配。

2.4 kubeconfig 中的证书结构

kubeconfig 文件（如 admin.conf、kubelet.conf）是集群访问的“连接配置包”，内部以 YAML 格式存储了三个关键证书字段：

典型 kubeconfig 片段示例：

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRV...   # CA 证书 base64
    server: https://192.168.1.100:6443
  name: kubernetes
users:
- name: kubernetes-admin
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRV...     # 客户端证书 base64
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVk...     # 客户端私钥 base64
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes

2.5 证书与 RBAC 的映射关系

证书中的 CN（Common Name） 和 O（Organization） 字段直接映射到 Kubernetes 的 RBAC 系统：

• CN → 映射为用户名（User）。例如 CN=system:kube-controller-manager 对应 system:kube-controller-manager 用户。
• O → 映射为用户所属组（Group）。例如 O=system:masters 对应 system:masters 组，该组默认绑定 cluster-admin 角色。

常见组件证书的 CN/O 约定：

2.6 证书轮换的常见触发场景

在 K8s 集群生命周期中，以下场景会触发证书轮换：

• 证书到期：kubeadm 默认签发 1 年有效期的证书，到期前需要手动或自动轮换。
• 集群升级：K8s 版本升级时，CA 或组件证书的签名算法、SAN 要求可能变化。
• 节点重加入：节点被重置后重新加入集群，需要签发新的 kubelet 证书。
• 安全合规：私钥泄露或安全策略要求定期更换证书。