3、节点通信链路分析：kubelet与apiserver、kube-proxy与apiserver、kubelet与kubelet之间的通信路径
在K8s集群中，证书轮换直接影响节点组件的通信链路。理解kubelet、kube-proxy与apiserver之间，以及kubelet与kubelet之间的通信路径，是排查证书兼容性问题的关键前提。每条链路使用的证书类型、认证方式、端口和协议均不同，轮换时需逐一验证。
3.1 通信链路总览
节点组件之间的通信分为三类：控制面通信（组件与apiserver）、节点间通信（kubelet ↔ kubelet）、代理通信（kube-proxy ↔ apiserver）。下表总结了每条链路的证书依赖和端口信息：
| 通信链路 | 源组件 | 目标组件 | 默认端口 | 协议 | 证书类型 | 认证方式 |
|---|---|---|---|---|---|---|
| kubelet → apiserver | kubelet | apiserver | 6443 | HTTPS | kubelet 客户端证书 | 双向 TLS（mTLS） |
| kube-proxy → apiserver | kube-proxy | apiserver | 6443 | HTTPS | kube-proxy 客户端证书 | 客户端证书认证 |
| kubelet ↔ kubelet | kubelet | kubelet | 10250 | HTTPS | kubelet 服务端证书 | 双向 TLS（mTLS） |
| apiserver → kubelet | apiserver | kubelet | 10250 | HTTPS | apiserver 客户端证书 | 双向 TLS（mTLS） |
证书轮换影响提示： 当 kubelet 客户端证书轮换后，apiserver 必须信任新的证书公钥；若 kubelet 服务端证书轮换，其他节点上的 kubelet 和 apiserver 都需要更新信任。任何一条链路的证书不匹配都会导致通信中断。
3.2 kubelet 与 apiserver 通信路径
kubelet 与 apiserver 之间的通信是节点最核心的控制面链路。kubelet 使用客户端证书向 apiserver 发起请求，apiserver 使用服务端证书响应。通信路径如下：
- kubelet 启动：加载客户端证书（通常位于
/var/lib/kubelet/pki/kubelet-client-current.pem）和 CA 证书。 - 建立 TLS 连接：kubelet 向 apiserver 的 6443 端口发起 HTTPS 请求，验证 apiserver 服务端证书的合法性。
- 双向认证：apiserver 要求 kubelet 提供客户端证书，验证其是否由集群 CA 签发且未过期。
- 请求授权：认证通过后，apiserver 检查 kubelet 的 RBAC 权限（如 Node 资源访问）。
- 数据交互：kubelet 上报节点状态、Pod 状态，接收 Pod 调度指令。
证书轮换关键点： kubelet 客户端证书轮换后，apiserver 必须信任新证书。如果轮换时未更新 apiserver 的 CA 信任列表，kubelet 将无法通过认证，导致节点状态变为
NotReady。
3.3 kube-proxy 与 apiserver 通信路径
kube-proxy 作为节点上的网络代理组件，需要从 apiserver 获取 Service 和 Endpoint 信息。其通信路径相对简单，但证书轮换同样关键：
- 认证方式：kube-proxy 使用客户端证书（或 ServiceAccount ）向 apiserver 发起请求。
- 通信方向：仅 kube-proxy → apiserver 单向，apiserver 不会主动连接 kube-proxy。
- 证书位置：客户端证书通常位于
/var/lib/kube-proxy/pki/kube-proxy-client-current.pem。 - 轮换影响：证书轮换后，kube-proxy 需要重新加载新证书，否则无法从 apiserver 同步 Service 规则，导致节点网络策略失效。
常见问题： kube-proxy 证书轮换后，如果未重启 kube-proxy Pod 或未触发证书重载，kube-proxy 会继续使用旧证书连接 apiserver，直到连接被 apiserver 拒绝（证书过期）。此时节点上 Service 的 iptables/IPVS 规则将停止更新。
3.4 kubelet 与 kubelet 通信路径
kubelet 之间的通信主要用于节点间 Pod 网络连通性检查和调试（如 kubectl exec、kubectl logs 跨节点场景）。通信路径如下：
- 目标端口：kubelet 监听 10250 端口（HTTPS），用于接收来自其他节点 kubelet 或 apiserver 的请求。
- 证书类型：每个 kubelet 持有服务端证书（用于对外提供 HTTPS 服务）和客户端证书（用于访问其他 kubelet）。
- 双向 TLS：发起方 kubelet 使用客户端证书，接收方 kubelet 使用服务端证书，双方互相验证。
- 轮换影响：当节点 A 的 kubelet 服务端证书轮换后，节点 B 的 kubelet 必须信任新的证书。如果节点 B 的 CA 信任列表未更新，节点间通信将失败。
排查技巧： 使用
openssl s_client -connect <node_ip>:10250 -cert /var/lib/kubelet/pki/kubelet-client-current.pem -CAfile /etc/kubernetes/pki/ca.crt 测试 kubelet 间 TLS 握手是否成功。
3.5 证书轮换兼容性检查清单
在证书轮换作业中，针对上述三条通信链路，建议按以下清单逐项排查：
| 链路 | 检查项 | 验证方法 | 轮换后预期行为 |
|---|---|---|---|
| kubelet → apiserver | kubelet 客户端证书是否被 apiserver 信任 | kubectl get nodes 查看节点状态 |
节点状态为 Ready，kubelet 日志无 x509 错误 |
| kube-proxy → apiserver | kube-proxy 客户端证书是否有效 | kubectl logs -n kube-system <kube-proxy-pod> |
kube-proxy 成功同步 Service 规则，无认证错误 |
| kubelet ↔ kubelet | 节点间 kubelet 服务端证书互信 | kubectl exec -it <pod> -- <command> 跨节点执行 |
跨节点 exec/logs 正常，无 TLS 握手失败 |
| apiserver → kubelet | apiserver 客户端证书是否被 kubelet 信任 | kubectl logs -n kube-system <kube-apiserver-pod> |
apiserver 日志无 kubelet 连接错误 |
证书轮换顺序建议： 先轮换 kubelet 客户端证书（影响 kubelet → apiserver），再轮换 kubelet 服务端证书（影响 kubelet ↔ kubelet 和 apiserver → kubelet），最后轮换 kube-proxy 客户端证书。每次轮换后至少等待一个证书轮换周期（默认 1 小时）确认链路稳定。