{
"CN": "kubernetes",
"hosts": [
"127.0.0.1",
"10.96.0.1",
"kubernetes",
"kubernetes.default",
"kubernetes.default.svc",
"kubernetes.default.svc.cluster.local",
"<MASTER_API_IP>",
"<MASTER_HOSTNAME_OR_DNS>"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "Beijing",
"L": "Beijing",
"O": "kubernetes",
"OU": "kube-apiserver"
}
]
}
各项详细解释（为什么需要它们）
1. CN（Common Name）
含义：证书主体（Subject）的“通用名”。传统上用于表示证书持有者的名称。
在服务器证书中常用 "kubernetes"（很多官方/社区教程/bootstrapping 使用这个），也有人用 "kube-apiserver"。
注意：现代 TLS 名称验证主要依赖 SAN（Subject Alternative Names），而不是 CN。但写上 CN 仍然是有价值的（兼容旧客户端/显示友好）。
2. hosts（SAN 列表）
含义：证书的 Subject Alternative Names（IP 和 DNS 名称）。这是 TLS 客户端在验证服务器证书时匹配的关键字段。
为什么必须：当客户端（如 kubectl、kubelets、API 代理等）访问 apiserver 时它们会用某个主机名或 IP 连接，TLS 验证会检查该连接名是否出现在证书的 SAN 中。如果不匹配，会报证书名不匹配错误（例如 x509: certificate is valid for ..., not <used-host>）。
常见条目说明：
127.0.0.1：本机访问（比如在 master 节点上本地测试）。
10.96.0.1：默认 Kubernetes service 的 ClusterIP（在很多集群中 apiserver 通过这个 service IP 暴露给集群内客户端）。非常重要，因为集群内的服务和组件有时会通过这个 service IP 访问 apiserver。
kubernetes / kubernetes.default / kubernetes.default.svc / kubernetes.default.svc.cluster.local：集群 DNS 名称（短名与全称都放上更保险）。
<MASTER_API_IP> 或 多个 Master IP / VIP：如果你从外部或其他节点通过 Master 的 IP 或负载均衡 VIP 访问 apiserver，必须把这些 IP/DNS 放入 SAN。
小结：把所有客户端可能用于访问 apiserver 的主机名/IP 都列进去。
3. key（算法与长度）
algo: rsa 或 ecdsa。
RSA：兼容性最广。
ECDSA：证书更短、签名速度快、密钥更短，但某些老客户端/工具可能对某些曲线支持不好。
size: RSA 推荐至少 2048；生产上可选 3072 或 4096（更强，但私钥/签名较慢）。Ecdsa 常见 curve 在 cfssl 里用默认即可（在 CSR 里通常只写 algo/size）。
选型建议：
小型测试环境可用 rsa 2048。
生产建议 rsa 3072 或 rsa 4096，或使用 ecdsa（如果你确认所有客户端都支持）。
4. names（X.509 Subject 的各字段：C/ST/L/O/OU）
C：国家（Country）。
ST：省/州（State）。
L：城市（Locality）。
O：组织（Organization）。在 Kubernetes 中，组织字段有时候会被用作 RBAC 绑定的判断依据（但通常是针对客户端证书）。对于 服务器证书，O 主要是信息性字段，可以写 kubernetes 或 Kubernetes 等。
注意：不要随意把 O 设置为 system:masters —— 那个组名是用来给客户端证书赋予 cluster-admin 权限（system:masters 属于特殊 RBAC 授权组）。服务器证书不应当用于身份授权。
OU：组织单元（可选），便于识别用途（例如 kube-apiserver）。
5. 证书有效期（expiration）
CSR 本身通常不包含过期时间；过期由 CA 的签发配置（例如 cfssl 的 -config profile 或 ca-config.json 中的 profiles）决定。生成时注意设置合理的有效期（例如 1 年、2 年，或按公司策略）。
如果使用自动化工具（kubeadm/kubespray），有默认策略。手工签发时请与团队策略对齐。
6. 为何 SAN 比 CN 更重要
现代 TLS 验证会先检查 SAN（hosts 列表），CN 用于兼容旧标准。一定要把所有要访问的主机名/IP 放到 hosts，否则会出现“证书名称不匹配”错误。
7. 当心的几件事
把 cluster IP（service IP）包含进去：否则集群内某些服务访问 api server 会因名称不匹配失败。
列出所有 Master 节点 IP / LB VIP / 域名：如果你通过负载均衡器或外网域名访问 apiserver，也要放入 SAN。
不要把 server cert 用作 client cert 的权限凭证：server cert 的 O/OU 不应该赋予 RBAC 管理权限（例如 system:masters）。客户端证书（用于管理员或用户）如果想要 admin 权限，签发时才把 CN/O 设置为相应组/用户。
密钥安全：生成后的私钥要妥善保管，尤其是在生产环境。