Kubeadm join与Kubernetes API创建节点的区别及纯API建Worker节点的可行性

• 流程覆盖范围不同：Kubeadm join是面向节点接入的全流程自动化工具，覆盖从节点本地组件配置、双向身份认证、集群注册到连通性校验的完整链路；通过Kubernetes API直接创建Node资源对象，仅完成集群控制平面侧的节点元数据占位登记，不涉及节点本地的任何配置动作。
• 身份关联逻辑不同：Kubeadm join会自动为接入节点生成专属的客户端证书、配置kubelet的访问凭证，完成节点实体与控制平面的双向信任校验；直接通过API创建的Node对象不携带任何实体节点的身份标识，控制平面无法将其他来源上报的节点状态与这个占位对象做匹配。
• 状态映射关系不同：Kubeadm接入的节点启动后，本地kubelet会自动将自身硬件资源、运行状态、健康检查结果同步到对应注册的Node对象上，形成真实主机与集群资源的一一映射；单独通过API创建的Node对象如果没有对应实体节点上报状态，会长期处于NotReady状态，不会自动关联真实主机的任何信息。
• 前置配置处理不同：Kubeadm join会自动完成集群CA证书的信任关系配置、控制平面网络连通性的前置校验、节点接入所需的临时令牌校验逻辑；直接调用API创建Node的方式不会处理这些接入必需的前置依赖，需要使用者手动完成所有配置。

从技术原理上完全可以实现，不存在不可逾越的门槛——只要把kubeadm自动化完成的所有步骤手动拆解落地，就可以完成Worker节点的全流程接入，具体需要手动完成的动作包括：

• 在集群控制平面侧创建对应Node资源的基础元数据，完成资源占位
• 为新Worker节点签发专属的kubelet客户端证书，配置对应的RBAC授权规则，将集群CA证书写入节点的系统信任存储
• 在Worker节点本地配置容器运行时、网络插件依赖项，编写kubelet的启动配置文件，写入控制平面API Server的访问地址、证书路径、节点身份标识，启动kubelet服务
• 校验节点与控制平面的网络连通性、节点状态是否转为Ready，确认工作负载可以正常调度到该节点

注：这种纯手动接入的方式技术上等价于kubeadm的接入流程，但操作复杂度远高于使用自动化工具，容易因漏配环节导致节点运行异常，仅适用于定制化部署场景，不建议日常通用场景使用。

内容的提问来源于stack exchange，提问作者Justin