2. Kubernetes 证书体系:集群内部证书类型、用途与生命周期管理

Kubernetes 集群的安全通信依赖于一套完整的 PKI(公钥基础设施)体系。集群内部各组件之间、组件与 API Server 之间、以及 kubelet 与 API Server 之间的所有通信都通过 TLS 加密。理解证书的类型、用途和生命周期管理,是排查证书轮换导致服务故障(如 kube-proxy 规则失效)的基础。

2.1 集群内部证书类型与用途

Kubernetes 集群主要使用以下四类证书,它们分别服务于不同的通信链路和身份验证场景:

证书类型 用途 签发对象 典型文件名称
CA 证书 集群信任根,用于签发其他所有证书 集群自身 ca.crt / ca.key
API Server 证书 客户端(kubectl、kubelet、scheduler、controller-manager)验证 API Server 身份 API Server apiserver.crt / apiserver.key
kubelet 证书 API Server 验证 kubelet 身份;kubelet 与 API Server 双向 TLS 通信 每个 Node 上的 kubelet kubelet.crt / kubelet.key
Service Account 密钥 Pod 内应用访问 API Server 时使用的 JWT 签名密钥 Service Account 控制器 sa.key / sa.pub
关键点: kube-proxy 本身不直接持有独立证书,它通过 kubeconfig 文件中的客户端证书(通常由 kubelet 证书或管理员证书签发)与 API Server 通信,获取 Service 和 Endpoint 信息。当 kubelet 证书轮换后,若 kube-proxy 未同步更新其使用的 kubeconfig,将导致规则失效。

2.2 证书生命周期管理

Kubernetes 证书的生命周期包括签发、分发、轮换和吊销四个阶段。证书轮换是运维中最容易引发故障的环节。

  • 签发: 集群初始化时由 kubeadm 或手动使用 openssl / cfssl 生成 CA 和组件证书。
  • 分发: 证书文件通过静态文件、Secret 或 kubeconfig 注入到各组件配置中。
  • 轮换: 证书到期前(默认 1 年)进行更新。kubelet 支持自动轮换,API Server 证书通常需要手动或通过 cert-manager 处理。
  • 吊销: 节点下线或证书泄露时,通过 CRL(证书吊销列表)或重新签发使旧证书失效。

2.3 证书轮换对 kube-proxy 的影响链路

下图展示了证书轮换如何通过 kubelet 证书影响 kube-proxy 的规则同步流程:

证书轮换影响 kube-proxy 规则链路 证书轮换影响 kube-proxy 规则链路 kubelet 证书轮换 kubeconfig 未同步 kube-proxy 连接失败 iptables/ipvs 规则未更新 Service 访问异常 常见原因 • kube-proxy 使用静态 kubeconfig • 证书轮换后未重启 kube-proxy • kubeconfig 中证书路径未更新

2.4 证书文件与 kubeconfig 的对应关系

kube-proxy 通常通过 /etc/kubernetes/kubelet.conf 或独立的 /var/lib/kube-proxy/kubeconfig 文件获取证书。以下表格展示了证书文件与 kubeconfig 中字段的映射:

kubeconfig 字段 对应证书文件 说明
clusters[].certificate-authority-data ca.crt 验证 API Server 证书的 CA 公钥
users[].client-certificate-data kubelet.crt 或 admin.crt kube-proxy 向 API Server 证明身份的客户端证书
users[].client-key-data kubelet.key 或 admin.key 客户端证书对应的私钥
故障排查提示: 当 kubelet 证书轮换后,/etc/kubernetes/kubelet.conf 中的客户端证书数据会自动更新。但如果 kube-proxy 使用的是独立 kubeconfig(如 /var/lib/kube-proxy/kubeconfig),且该文件引用了旧证书路径或嵌入了旧证书的 base64 数据,则 kube-proxy 会持续使用过期证书,导致 API Server 拒绝连接,进而无法同步 Service 规则。

2.5 证书轮换的典型时间线

以下流程图展示了从证书到期到服务故障的典型时间线:

证书轮换故障时间线 证书轮换故障时间线 T0: 证书到期前 30 天 kubelet 自动轮换证书 T1: 轮换后 0-5 分钟 kubelet 更新本地 kubeconfig T2: 轮换后 5-60 分钟 kube-proxy 仍使用旧证书 T3: 旧证书过期 kube-proxy 连接中断 故障窗口 从旧证书过期到 kube-proxy 重启/重新加载 kubeconfig 之间的时间窗口 此窗口内 Service 规则无法更新,新 Pod 无法被访问

2.6 证书管理最佳实践

  • 使用自动轮换: 启用 kubelet 的 RotateKubeletServerCertificate 特性,让 kubelet 自动申请和更新证书。
  • 统一 kubeconfig 管理: 确保 kube-proxy 使用与 kubelet 共享的 kubeconfig(如 /etc/kubernetes/kubelet.conf),避免独立维护。
  • 监控证书过期时间: 使用 kubeadm certs check-expiration 或 Prometheus 监控证书剩余有效期。
  • 轮换后验证: 证书轮换后,检查 kube-proxy 日志是否出现 certificate has expired 或 tls: bad certificate 错误。
  • 设置告警: 对证书过期时间设置告警阈值(如 30 天、7 天、1 天),提前介入。
快速验证命令: 使用 openssl x509 -in /etc/kubernetes/pki/kubelet.crt -noout -text | grep -E "Not Before|Not After" 查看证书有效期。使用 kubectl --kubeconfig=/var/lib/kube-proxy/kubeconfig get nodes 测试 kube-proxy 的 kubeconfig 是否仍然有效。