4. 证书兼容性检查清单
Kubernetes 集群证书轮换的核心风险并非生成新证书本身，而是新证书与集群内各组件、客户端及遗留系统之间的兼容性。一份结构化的检查清单能够帮助运维人员在轮换前识别潜在断裂点，避免因证书属性不匹配导致节点间 TLS 握手失败、kubelet 无法注册或 API Server 拒绝连接。
以下清单从四个维度展开：有效期、签名算法、密钥长度与曲线、X.509 v3 扩展。每个维度均包含检查项、风险等级及推荐操作。
4.1 有效期检查
| 检查项 | 风险等级 | 说明 |
|---|---|---|
| 证书剩余有效期 < 30 天 | 高 | kubelet 与 API Server 双向 TLS 可能提前中断；kube-controller-manager 自动轮换可能因时间偏差失败。 |
| 证书有效期 > 5 年 | 中 | 长期证书违反最小权限原则；轮换周期过长导致密钥泄露风险累积。 |
| CA 证书过期早于叶子证书 | 高 | 叶子证书在 CA 过期后无法被信任链验证，需确保 CA 有效期覆盖所有已签发证书。 |
| 集群节点时间偏差 > 5 分钟 | 高 | NTP 不同步会导致证书“未生效”或“已过期”误判，尤其在使用短生命周期证书时。 |
最佳实践： 生产集群建议将 kubelet 证书有效期设为 1 年，CA 证书设为 10 年。使用
kubeadm certs check-expiration 定期扫描所有证书剩余时间。
4.2 签名算法检查
签名算法决定了证书的加密强度与兼容性。Kubernetes 1.24+ 已默认禁用 SHA-1 签名算法，但部分遗留客户端或硬件负载均衡器可能仍依赖 SHA-1。
| 签名算法 | K8s 版本支持 | 风险等级 | 兼容性影响 |
|---|---|---|---|
| SHA-1 (RSA) | ≤ 1.23 | 高 | Go 1.18+ 默认拒绝 SHA-1 证书；kubelet 与 API Server 握手失败；etcd 3.5+ 拒绝连接。 |
| SHA-256 (RSA) | 全部 | 低 | 当前主流算法，所有组件均支持。 |
| SHA-384 / SHA-512 | 全部 | 低 | 兼容性良好，但部分旧版 OpenSSL 1.0.2 可能不支持 SHA-512。 |
| ECDSA (P-256 / P-384) | 1.19+ | 中 | 需要 kubelet 和 API Server 均启用 ECDSA 支持；旧版 etcd 可能不兼容。 |
注意： 如果集群中仍存在运行 Kubernetes 1.22 或更早版本的节点，轮换证书时务必保留 SHA-256 作为最低签名算法。直接切换到 ECDSA 可能导致旧节点 kubelet 无法启动。
4.3 密钥长度与曲线检查
密钥强度直接影响 TLS 握手性能与安全性。RSA 密钥长度不足 2048 位已被 NIST 视为不安全；ECDSA 曲线选择不当则可能导致兼容性断裂。
| 密钥类型 | 推荐长度/曲线 | 最低要求 | 兼容性风险 |
|---|---|---|---|
| RSA | 2048 或 4096 位 | 2048 位 | 1024 位证书被 Go 1.16+ 拒绝；4096 位增加握手延迟约 30-50ms。 |
| ECDSA | P-256 或 P-384 | P-256 | P-521 曲线在部分 FIPS 模式下不可用；旧版 OpenSSL 1.0.2 不支持 P-384。 |
| Ed25519 | — | — | Kubernetes 官方 CA 工具 kubeadm 暂不支持；需手动生成并配置。 |
性能对比： ECDSA P-256 的握手速度约为 RSA 2048 的 3-5 倍，且密钥体积小 80%。如果集群所有节点均已升级至 Kubernetes 1.24+，建议逐步迁移至 ECDSA。
4.4 X.509 v3 扩展检查
X.509 v3 扩展定义了证书的使用范围与约束。Kubernetes 组件对扩展字段有严格校验，缺失或错误配置将直接导致 TLS 握手失败。
| 扩展字段 | K8s 组件要求 | 常见错误 | 影响 |
|---|---|---|---|
| Key Usage | Digital Signature, Key Encipherment | 缺少 Key Encipherment | API Server 无法使用证书进行密钥交换，TLS 握手失败。 |
| Extended Key Usage | Server Auth, Client Auth | 仅包含 Server Auth | kubelet 无法作为客户端向 API Server 发起注册请求。 |
| Subject Alternative Name (SAN) | 包含节点 IP、主机名、Service DNS 名称 | 缺少节点 IP 或 Cluster IP | kubelet 与 API Server 之间的 IP 直连通信被拒绝。 |
| Basic Constraints | CA: FALSE（叶子证书） | 误设为 CA: TRUE | 证书可被用作中间 CA，产生严重安全风险。 |
验证命令： 使用
openssl x509 -in /etc/kubernetes/pki/apiserver.crt -text -noout 查看证书扩展字段。重点关注 X509v3 Subject Alternative Name 是否包含所有节点 IP 和 Service Cluster IP。
4.5 兼容性检查流程总览
以下 SVG 图展示了证书轮换前兼容性检查的完整流程，从有效期扫描到扩展字段验证，最终输出“通过/阻断”决策。
4.6 常见兼容性故障案例
- 案例 A：SHA-1 证书导致 etcd 连接中断
集群升级至 Kubernetes 1.25 后，etcd 日志持续报错tls: failed to verify certificate: x509: certificate signed by unknown authority。排查发现 etcd 对等证书仍使用 SHA-1 签名，Go 1.19 运行时拒绝加载。解决方案：重新签发 etcd 证书，指定-sha256参数。 - 案例 B：SAN 缺失节点 IP 导致 kubelet 注册失败
新节点加入集群时，kubelet 日志显示Unauthorized。使用openssl x509 -in node.crt -text检查发现 SAN 字段仅包含主机名，未包含节点 IP 地址。重新签发证书并添加IP:192.168.1.100后问题解决。 - 案例 C：RSA 1024 位证书被 API Server 拒绝
遗留 CI 环境使用自签发 RSA 1024 位证书连接集群。Kubernetes 1.24 升级后，API Server 返回tls: handshake failure。升级证书至 RSA 2048 位后恢复。
关键提醒： 证书兼容性检查应在轮换窗口前至少 48 小时完成。如果发现不兼容项，预留足够时间重新签发证书并更新所有受影响的 kubeconfig 文件。切勿在生产集群中直接使用
--tls-min-version 或 --insecure-skip-tls-verify 绕过检查。