Pinxian Li第一次手工部署 k8s 时，我只用一天就意识到，如果每个节点都靠手动 copy 二进制、自签证书、维护 systemd 服务，这套系统注定只能停留在测试环境。kubeadm 是目前把“单 master 多 node”集群搭建成本压到最低的工具，它把证书生成、组件静态 Pod 编排、kubeconfig 下发、token 引导这一整套流程封装成了可复现的命令。这篇作为系列第一篇，目标就一个：带你把一套能正常跑业务、能扩容 worker 节点的集群搭起来，同时把每个步骤背后的原因讲透。适合对容器有基本了解、还没有完整搭建过集群的同学，也适合搭完一次但踩过不少坑想回头补概念的人。
1. 动手前先把架构盘明白：kubeadm、master、node 各管一摊
1.1 单 master 集群的部件构成
kubeadm 搭出来的集群，本质上还是那套标准 Kubernetes 控制面组件，只不过它把这些组件从二进制进程变成了容器形态去托管。一个单 master 多 node 集群里，职责分两层：
- 控制平面（master）：跑着 kube-apiserver、kube-controller-manager、kube-scheduler，以及 etcd 存储。所有对集群的读写请求都要经过 apiserver，它是整个集群的“调度总机”。
- 工作节点（node）：跑着 kubelet、kube-proxy 和容器运行时。kubelet 负责跟 apiserver 通信、接收 Pod 调度请求、监控本机容器状态；kube-proxy 负责维护节点的网络规则，让 Service 能转发流量。
kubeadm 做的事情，就是把这些组件的配置文件、证书、静态 Pod 清单全部生成好，再交给 kubelet 以静态 Pod 方式启动。也就是说，你不需要手工装 etcd、手工签 CA 证书，只要 init 一下，控制面自己就起来了。
1.2 为什么选 kubeadm 而不是二进制和 minikube
很多新手会问：我直接下二进制手动部署行不行？行，但对入门阶段的人来说成本极高。二进制方式需要自己处理 CA 证书、kubeconfig、etcd 集群、组件启动顺序，任何一个环节错了都要看日志追半天。kubeadm 的好处是：
- 流程标准化：一条 init 命令完成控制面初始化，一条 join 命令让节点加入，证书和 token 机制都内置。
- 升级可控：kubeadm upgrade 可以按版本逐级升级控制面组件，比手改配置稳得多。
- 可审计、可回滚：init 生成的配置在 /etc/kubernetes 下，关键动作都有清晰输出。
minikube 适合单机学习，但它只有一个节点，没办法体会多节点调度、Pod 漂移、节点 NotReady 这类真实运维场景。生产环境里大量线上集群也是 kubeadm 或者基于 kubeadm 思路的部署工具（比如 RKE、Kubespray）搭出来的，所以从这个工具入门，后续要往生产方向走也不吃亏。
1.3 k8s 和 docker 经常被放在一起问，到底什么关系
搜索里经常出现“k8s 和 docker 区别”，这里花一点篇幅说清楚：Docker 是容器运行时，负责把镜像变成运行中的容器；Kubernetes 是容器编排平台，负责决定这些容器跑在哪台机器、挂了怎么拉起、流量怎么负载均衡。两者不是二选一的关系，而是一个管单机、一个管集群。
具体到新版 kubeadm 集群，默认使用的容器运行时已经不是 Docker Engine，而是 containerd。因为 containerd 更轻，也原生兼容 CRI（Container Runtime Interface）。即便你安装镜像是用 docker build 打出来的，只要符合 OCI 标准，containerd 就能直接跑。实际搭建中，你只需要保证容器运行时正常工作，不用纠结 k8s 是不是需要用 docker 命令来管理容器。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 规划阶段决定后面的成功率：版本、资源、网段三件事
2.1 版本选择和组件一致性
kubeadm、kubelet、kubectl 这三个二进制最好装同一个版本，控制平面版本和节点 kubelet 版本也不能相差超过一个小版本。我自己遇到过 kubelet 比 apiserver 新两个小版本导致节点反复 NotReady 的情况，日志看着像证书问题，其实根源就是版本不对称。
建议用当前稳定版本，比如 v1.30.x 或 v1.31.x，具体以你操作时的官方 release 为准。小版本号不必刻意追最新，选一个已经迭代过几个 patch 的版本更稳妥。有个细节：kubeadm init 默认会拉取最新稳定版，但如果你的网络环境对特定版本拉取失败，可以显式指定 --kubernetes-version=v1.30.0 这样的参数，避免版本变化带来干扰。
2.2 资源底线
单 master 多 node 集群虽然比单机复杂，但对资源要求并没有想象中高。我这边实测的最低配置参考：
| 角色 | CPU | 内存 | 磁盘 |
|---|---|---|---|
| master | 2 核 | 2 GB 以上，推荐 4 GB | 40 GB |
| node | 2 核 | 2 GB 以上 | 40 GB |
注意这里说的是“能跑起来”的最低配置，如果你还要部署数据库、日志采集、监控这些组件，内存建议翻倍。etcd 对磁盘 IO 敏感，机械盘在频繁写入时容易造成 apiserver 请求变慢，有条件的话 master 用 SSD。
2.3 网络规划：Pod 网段、Service 网段、节点 IP 怎么分配
Kubernetes 集群有三层网络叠加，很多