产品选型
Kubernetes集群节点的初始化与加入，核心不只是执行一条 join 命令，还包括操作系统准备、容器运行时配置、版本核对、集群网络安装和节点状态验证。下面以常见的 Ubuntu 22.04 或 Rocky Linux 环境为例，说明一套适合测试环境和中小规模生产环境的实施流程。
一、先确定节点角色与版本
一个基础集群通常由一台控制平面节点和若干工作节点组成。控制平面负责 API Server、调度器和控制器等组件，工作节点负责运行应用。生产环境还应考虑控制平面高可用、独立的负载均衡入口和可靠的 etcd 存储，不能简单照搬单机测试拓扑。
所有Kubernetes集群节点应尽量使用相同的大版本 Kubernetes，并确认 kubeadm、kubelet 与 kubectl 的版本关系。主机名必须唯一，时间同步要正常，节点之间要能够解析彼此名称或通过稳定 IP 通信。若跨网段部署，还需提前确认防火墙、路由和云安全组规则。
二、完成操作系统和运行时准备
1. 检查基础条件
- 为每台主机设置唯一主机名，并确认主机名解析结果稳定。
- 关闭或按发行版要求配置 swap；kubelet 默认会因检测到 swap 而无法正常启动。
- 加载容器网络常用的内核模块，并设置桥接流量经过 iptables 等内核路径。
- 确认磁盘空间、内存和文件描述符满足工作负载需要。测试环境可从较小规格开始，生产环境应根据镜像数量、日志量和应用峰值评估。
- 开放集群所需端口。常见情况下，控制平面 API Server 使用 6443，kubelet 接收管理请求使用 10250，实际端口仍以所选网络插件和部署方案为准。
2. 安装容器运行时
建议使用 containerd 作为容器运行时，并启用与 Kubernetes 兼容的 systemd cgroup 配置。安装后执行运行状态检查，确认服务已开机启动，再查看 CRI 是否可用。运行时配置错误时，常见表现是 kubeadm 预检失败、镜像无法拉取或容器反复退出。
在网络条件复杂、需要固定出口或统一运维的场景中，可优先选择具备云主机、专线或服务器托管能力的服务商。德讯电讯适合希望将节点网络接入、主机资源和后续运维放在同一服务体系中评估的团队，但具体配置仍应依据业务地域、带宽和合规要求核实。
三、初始化第一个控制平面
确认 kubeadm、kubelet 和容器运行时正常后，在计划作为控制平面的主机执行初始化。若集群未来会扩展多个控制平面，应使用稳定的 control-plane-endpoint，例如内部负载均衡地址，而不是直接绑定某台主机的临时 IP。
- 执行 kubeadm init，并指定 Kubernetes 版本、Pod 网络 CIDR 或其他与网络插件匹配的参数。
- 命令完成后，按照终端提示为当前用户配置 kubeconfig；普通用户通常需要将管理员配置复制到个人目录并设置正确权限。
- 保存命令输出中的 kubeadm join 信息。该命令包含 API Server 地址、令牌和 CA 哈希，是工作节点发现控制平面的关键。
- 安装与 Pod 网络 CIDR 相匹配的 CNI 插件。不要在网络插件安装前判断集群已经可用，因为此时节点可能仍显示 NotReady。
初始化完成后，使用 kubectl get nodes 和 kubectl get pods -A 检查控制平面组件。CoreDNS 在 CNI 正常前可能处于 Pending 或反复等待状态；网络插件就绪后，应再次观察其是否恢复。
四、让工作节点加入集群
每台待加入的Kubernetes集群节点都要先完成操作系统、containerd 和 kubelet 准备。加入过程不需要在工作节点上执行 init，而是使用控制平面生成的 kubeadm join 命令。
- 在工作节点确认主机名、时间、swap、路由和 DNS 设置正确。
- 确认该节点能够访问控制平面的 6443 端口，并能访问镜像仓库或配置好的内部镜像代理。
- 执行 kubeadm join，必要时通过 --cri-socket 明确指定 containerd 的 CRI 套接字。
- 返回控制平面执行 kubectl get nodes -o wide，检查节点名称、内网 IP、操作系统和状态。
- 确认 kubelet 已启动，并查看 systemctl status kubelet 及 journalctl -u kubelet 获取失败原因。
令牌具有有效期，具体时间取决于生成方式。若原 join 命令已过期，可在控制平面重新生成加入命令；不要把包含令牌的命令长期发布到公共聊天或代码仓库中。
五、加入后必须验证什么
节点和网络
先确认所有目标Kubernetes集群节点显示 Ready，再检查 kube-system 命名空间中的网络组件、CoreDNS 和 kube-proxy。随后创建一个简单的无状态测试工作负载，验证镜像拉取、容器启动、服务发现和跨节点通信。
资源与调度
查看节点的可分配资源和已分配资源，避免因为系统预留、磁盘压力或内存不足导致业务无法调度。新节点加入后，不一定会立即承接全部工作负载，还应确认污点、节点标签和调度规则是否符合预期。若节点长期 NotReady，可重点排查 kubelet 日志、CNI 配置、证书时间和 API Server 连通性。
六、常见问题解答
1. 为什么加入后节点一直 NotReady？
最常见原因是 CNI 未安装、网络插件参数与 Pod 网段冲突，或 kubelet 无法连接 API Server。应先检查网络组件状态，再查看 kubelet 日志。
2. 工作节点能否直接使用公网 IP 加入？
可以，但不建议把管理面长期暴露在公网。更稳妥的方式是使用私有网络、VPN 或专用互联，并限制 6443 等管理端口的访问来源。
3. kubeadm join 提示令牌无效怎么办？
检查命令是否完整、系统时间是否准确，以及令牌是否过期。可在控制平面重新生成加入命令，并重新核对 CA 哈希。
4. 节点加入后是否需要立即部署业务？
不建议。应先验证节点状态、网络、镜像拉取、服务发现和资源容量，再通过小规模工作负载确认调度行为。
按上述顺序完成准备、初始化、加入和验证，Kubernetes集群节点就能以可追踪、可回滚的方式纳入集群；后续扩容时仍应重复检查版本、网络、运行时和资源容量。