4. kube-proxy 证书体系：客户端证书、kubeconfig 结构与 TLS 握手
kube-proxy 作为运行在每个工作节点上的关键组件，负责维护节点上的网络规则并代理 Service 流量。它与 kube-apiserver 之间的通信依赖 客户端证书认证，理解其证书体系是进行证书轮换与规则迁移测试的前提。
4.1 kube-proxy 使用的客户端证书
kube-proxy 使用由集群 CA 签发的 客户端证书 向 kube-apiserver 发起 TLS 连接。该证书通常包含以下关键属性：
| 属性字段 | 典型值 / 说明 |
|---|---|
| Common Name (CN) | system:kube-proxy — 标识该证书属于 kube-proxy 组件 |
| Organization (O) | system:node-proxier — 用于 RBAC 绑定，授予代理相关权限 |
| Key Usage | Digital Signature, Key Encipherment |
| Extended Key Usage | Client Authentication — 仅用于客户端身份验证 |
| 签发者 | 集群 CA（如 kubernetes-ca） |
运维要点： 证书轮换时需确保新证书的 CN 和 O 字段与旧证书完全一致，否则 RBAC 绑定可能失效，导致 kube-proxy 无法正常 watch EndpointSlice 或 Node 资源。
4.2 kubeconfig 文件结构分析
kube-proxy 的客户端凭据存储在 /etc/kubernetes/kube-proxy.conf 或由 kubeadm 生成的 /var/lib/kube-proxy/kubeconfig 文件中。该 kubeconfig 包含三个核心段：
apiVersion: v1
kind: Config
clusters:
- cluster:
certificate-authority-data: <base64-CA-cert> # 信任的集群 CA
server: https://<apiserver-endpoint>:6443
name: kubernetes
users:
- name: kube-proxy
user:
client-certificate-data: <base64-client-cert> # kube-proxy 客户端证书
client-key-data: <base64-client-key> # 对应的私钥
contexts:
- context:
cluster: kubernetes
user: kube-proxy
name: kube-proxy-context
current-context: kube-proxy-context
| 配置段 | 作用 | 轮换影响 |
|---|---|---|
| clusters[].certificate-authority-data | 验证 apiserver 服务端证书的签发者 | CA 轮换时需同步更新 |
| users[].client-certificate-data | kube-proxy 向 apiserver 出示的身份凭证 | 客户端证书轮换时替换 |
| users[].client-key-data | 与客户端证书配对的私钥 | 必须与证书同时轮换 |
| contexts[].context | 绑定集群与用户，定义当前生效配置 | 通常不变，除非集群名称变更 |
轮换风险提示： 直接修改 kubeconfig 文件时，务必使用
kubectl config set-credentials 或原子替换方式，避免因文件写入中断导致 kube-proxy 读取到不完整的凭据，造成代理规则丢失。
4.3 证书与 kube-apiserver 的 TLS 握手过程
kube-proxy 启动后持续与 kube-apiserver 建立 TLS 连接，以 watch EndpointSlice、Service、Node 等资源。完整的 TLS 握手流程如下：
- TCP 连接建立： kube-proxy 向 apiserver 的 6443 端口发起 TCP 三次握手。
- Client Hello： kube-proxy 发送支持的 TLS 版本、密码套件列表。
- Server Hello + 服务端证书： apiserver 返回选定的 TLS 参数及其服务端证书（含公钥）。
- 证书验证（kube-proxy 侧）： kube-proxy 使用 kubeconfig 中的
certificate-authority-data验证 apiserver 证书的签名链与有效期。 - Client Certificate + CertificateVerify： kube-proxy 将自己的客户端证书发送给 apiserver，并用私钥对握手摘要签名。
- 服务端验证客户端证书： apiserver 使用集群 CA 验证客户端证书的签名，并检查 CN/O 字段是否匹配 RBAC 绑定。
- 对称密钥协商完成： 双方通过密钥交换算法生成会话密钥，后续通信使用对称加密。
关键结论： 握手过程中任何一方的证书过期、CA 不信任、CN/O 不匹配都会导致 TLS 握手失败，kube-proxy 将无法从 apiserver 获取最新的 Service 和 Endpoint 信息，进而造成节点上的 iptables/ipvs 规则无法更新。
4.4 证书轮换对 kube-proxy 规则迁移的影响
在集群升级过程中，证书轮换与 kube-proxy 规则迁移存在以下关联风险点：
| 风险场景 | 现象 | 验证方法 |
|---|---|---|
| 客户端证书过期 | kube-proxy 日志报 tls: bad certificate，无法 watch 资源 |
openssl x509 -in /var/lib/kube-proxy/pki/kube-proxy.crt -noout -dates |
| CA 证书轮换未同步 | kube-proxy 无法验证 apiserver 新证书，连接被拒绝 | 检查 kubeconfig 中 certificate-authority-data 是否与集群 CA 一致 |
| CN/O 字段变更 | RBAC 绑定失效，kube-proxy 无权限访问 EndpointSlice | kubectl auth can-i --as=system:kube-proxy list endpointslices |
| 私钥与证书不匹配 | TLS 握手阶段 CertificateVerify 失败 | openssl x509 -noout -modulus -in cert.crt | openssl md5 与私钥比对 |
最佳实践： 在证书轮换前，先使用
kubectl --kubeconfig=/etc/kubernetes/kube-proxy.conf get nodes 验证当前 kubeconfig 可用性；轮换后立即重启 kube-proxy Pod 并观察日志，确认 TLS 握手成功且规则同步正常。