节点与控制面之间的通信
本文列举控制面节点（确切地说是 API 服务器）和 Kubernetes 集群之间的通信路径。目的是让用户能够自定义安装，以实现对网络配置的加固，使集群能够在不可信的网络上（或者在一个云服务商完全公开的 IP 上）运行。
节点与控制面通信的整体拓扑是典型的星型结构，控制面（API 服务器）是唯一的枢纽：
官方文档参考
| 文档 | 链接 |
|---|---|
| 节点与控制面之间的通信（官方中文） | https://kubernetes.io/zh-cn/docs/concepts/architecture/control-plane-node-communication/ |
Hub and spoke 模型
集群的所有通信模式都遵循 hub-and-spoke（星型/轮毂-辐条）模式：API 服务器是中心枢纽（hub），所有其他组件（kubelet、控制器、调度器等）作为辐条（spoke）只与 API 服务器通信，组件之间互不直连。
| 通信方向 | 发起方 | 说明 |
|---|---|---|
| kubelet → API 服务器 | kubelet 主动发起 | 节点侧无需暴露端口给控制面 |
| 控制器/调度器 → API 服务器 | 控制面组件主动发起 | 同上 |
| API 服务器 → kubelet | API 服务器主动发起 | 需要能反向连到节点，是最需要加固的路径 |
hub-and-spoke 意味着：只要节点能访问 API 服务器的 443 端口，"节点 → 控制面"方向就天然安全。真正需要专门加固的是"控制面 → 节点"方向（API 服务器主动连 kubelet 10250 端口），这也是本文的重点。
API 服务器到 kubelet
API 服务器到 kubelet 的连接用于两类操作：
| 路径类型 | 典型操作 | 说明 |
|---|---|---|
| 读路径 | 取 Pod 日志、kubectl exec -c 的输出流、attach、port-forward | 从节点上的 kubelet 拉取数据 |
| 写路径 | kubectl exec、kubectl run、kubectl drain、kubectl port-forward 等派生的操作 | API 服务器向 kubelet 下发指令 |
这些连接终结于 kubelet 的 HTTPS 端点。默认情况下，Kubernetes API 服务器不校验 kubelet 的服务证书，这使连接容易受到中间人攻击，在不可信/公开网络上不安全。
启用 kubelet 证书校验的方式：
- kubelet 侧：给 kubelet 配置
--tls-cert-file和--tls-private-key-file，提供用于服务证书的证书签发（自定义 CA）。 - API 服务器侧：配置
--kubelet-certificate-authority，提供用于校验 kubelet 服务证书的 CA 根证书。
若 API 服务器尚未启用 --kubelet-certificate-authority，可通过 webhook 方式加固：
- kubelet 认证：API 服务器使用 kubelet 的客户端证书与其通信（
--kubelet-client-certificate/--kubelet-client-key）。 - kubelet 授权：API 服务器通过
--authorization-mode=Webhook将 RBAC 判定委托出去，对发起请求的主体（如system:kubelet-api-admin组）做授权检查，避免任何能访问 API 服务器的人都获得 kubelet API 权限。
如果 kubelet 的授权模式仍是默认的 AlwaysAllow，那么任何拿到 kubelet API 访问权的人都可以在节点上执行任意容器命令（exec 进入任意容器、读取任意 Pod 日志）。生产环境务必启用 webhook 认证/授权 + TLS 证书校验。
API 服务器到节点、Pod 和 Service
API 服务器除了连 kubelet，还会主动连接节点、Pod 和 Service：
| 目标 | 默认行为 | 说明 |
|---|---|---|
| 节点 | API 服务器直接连接节点的 IP | 需要网络允许此方向连通 |
| Pod | 直接连接 Pod IP | 经过 CNI 网络可达 |
| Service | 先经过 kube-proxy 维护的转发规则 | 访问 Service 的 ClusterIP |
默认的连接方式是普通的 HTTP 明文连接（通过 IP + 端口直连），没有加密与身份认证。在不可信网络上，这种连接存在的问题：
- 数据包路由问题：数据包可能被路由到错误的目的地（如跨网络路径上被劫持）。
- 重定向绕过：目标返回的重定向可能把请求引向非预期的主机，绕过预期的安全边界。
- 不安全模式：直连 IP 的方式缺乏端到端加密，容易受到中间人攻击。
如果需要在不可信网络上安全地运行，可以开启 API 服务器的 --enable-aggregator-routing=false 之外的措施，或使用加密通道（如对连接进行 TLS 加密、使用 mTLS）。
kubelet 到 API 服务器
kubelet 连接 API 服务器的方式是标准的客户端-服务器模式：
| 要素 | 说明 |
|---|---|
| 连接发起方 | kubelet（节点侧）主动连接 API 服务器 |
| 端点 | API 服务器的 HTTPS 端口（默认 443） |
| 认证 | kubelet 使用客户端证书（--kubeconfig 指定的凭据）向 API 服务器认证 |
| 连通性要求 | 节点必须能访问 API 服务器的 443 端口；反向不需要 |
kubelet 通过这条连接完成：注册节点、上报节点状态与心跳（Lease 续约）、watch 与自身相关的对象（Pod 清单变化、Secret 挂载等）、上报事件与指标。
控制器和调度器到 API 服务器
与 kubelet 类似，控制器（包括 节点控制器在内的 kube-controller-manager 内的各类控制器）和调度器也都通过 API 服务器提供的 watch 机制来观察资源状态：
| 组件 | 通信机制 |
|---|---|
| 控制器（kube-controller-manager） | 通过 API 服务器 watch 资源（如 Node、Pod、Deployment），基于观察到的差异执行调和（reconcile） |
| 调度器（kube-scheduler） | watch 未调度 Pod，完成调度决策后写回 nodeName 绑定结果 |
这些连接同样需要认证与授权，通常使用 ServiceAccount 或客户端证书进行身份认证。
在高可用部署中，kube-controller-manager 和 kube-scheduler 都通过 Lease（kube-system 命名空间下如 kube-controller-manager、kube-scheduler Lease 对象）来选主，只有 leader 副本实际执行调和与调度；同时节点心跳也用 Lease 对象替代高频的 .status 更新，显著降低了大规模集群下 API 服务器与 etcd 的压力。
通信路径加固速查
| 路径 | 默认状态 | 加固手段 |
|---|---|---|
| API 服务器 → kubelet | HTTPS，但不校验服务证书 | kubelet 配 --tls-cert-file/--tls-private-key-file，API 服务器配 --kubelet-certificate-authority；启用 webhook 认证/授权 |
| API 服务器 → 节点/Pod/Service | HTTP 明文直连 | 不可信网络中改为加密通道（TLS/mTLS）或经认证代理 |
| kubelet → API 服务器 | HTTPS + 客户端证书 | 正常即安全，确保 --kubeconfig 凭据保管妥当 |
| 控制器/调度器 → API 服务器 | HTTPS + 认证 | 同上，按 RBAC 最小授权 |
我的总结与避坑清单
- 整个集群只有一种通信模式：一切连 API 服务器（hub-and-spoke）。排查通信问题先分清方向——"节点 → apiserver"不通通常是证书/网络策略问题，"apiserver → kubelet"不通则看 10250 端口与防火墙。
- 生产环境必须补齐
--kubelet-certificate-authority，否则 apiserver 到 kubelet 的 HTTPS 连接不校验服务端证书，中间人攻击可截获kubectl logs、kubectl exec的全部内容。 - kubelet 的
AlwaysAllow授权是高危默认值；开启 webhook 授权后，谁能在节点上 exec/attach 全部由 RBAC 管，记得给运维角色配nodes/proxy等最小权限。 - apiserver 直连 Pod IP / Service 的路径默认是明文 HTTP 且存在重定向绕过风险，跨不可信网络（如公网多集群、云上公开 IP）时要用 mTLS 或网络层加密兜底。
- 大规模集群优先用 Lease 心跳而非高频
.status更新，kube-controller-manager 的--node-monitor-period保持默认 5 秒即可，盲目调小会把 apiserver 打爆。 - 节点只需要出方向访问 apiserver 443 端口，安全组不必给节点开入站 10250；入站 10250 仅控制面需要。
- 多副本 controller-manager/scheduler 靠 Lease 选主，看到 LeaderElection 日志轮转属于正常现象，不要手动干预。
