kubeadm 是 Kubernetes 官方提供的集群引导工具，它把控制平面组件以静态 Pod 的方式部署在 master 节点上，并通过一套标准化的证书、令牌和 kubelet 配置流程，让集群初始化从一堆手工步骤收敛成两条核心命令：kubeadm init 和 kubeadm join。理解这条初始化链路，是判断 kubeadm 是否适合自己业务场景的前提，也是在遇到 init 失败时能够快速定位问题的关键。
一、kubeadm 初始化集群的底层流程与优缺点
kubeadm init 执行后并不会直接帮你启动一个完整的 Kubernetes 集群，而是按照固定顺序完成预检、证书生成、静态 Pod 写入、kubelet 启动、控制平面组件拉起、bootstrap token 生成、kube-proxy 和 CoreDNS 安装等步骤。预检阶段会检查操作系统、内核参数、容器运行时、端口占用、swap 状态以及 kubelet 版本是否满足要求，任何一项不通过都会直接终止初始化。证书阶段会生成 CA、apiserver、apiserver-kubelet-client、front-proxy 等一组证书，默认存放在 /etc/kubernetes/pki 目录下，有效期通常为一年。
随后 kubeadm 会把 apiserver、controller-manager、scheduler、etcd 等控制平面组件以 YAML 文件的形式写入 /etc/kubernetes/manifests 目录。kubelet 启动后会读取该目录，把这些组件作为静态 Pod 拉起来。此时整个控制平面还没有完全可用，kubeadm 会继续生成 bootstrap token，并等待 kubelet 完成控制平面 Pod 的健康检查。最后安装 kube-proxy 和 CoreDNS，完成默认网络 DNS 组件的部署。整个过程看似简单，但每一步都依赖容器运行时、镜像仓库和 kubelet 配置的一致性，任何一个细节错位都可能让 init 卡住。
从优点看，kubeadm 最大的价值是官方维护、标准化程度高、学习成本低。相比纯二进制部署需要手动管理证书、systemd 服务文件和组件配置，kubeadm 把这些动作收敛成可重复执行的命令。对于中小规模集群、测试环境和学习场景，kubeadm 足够稳定，而且社区资料丰富。它不绑定云厂商，可以在物理机、虚拟机、裸金属上运行，给用户保留较大的底层控制权。缺点也很明显：kubeadm 不负责底层基础设施的高可用，多控制平面需要自行搭建负载均衡器；升级虽然可以通过 kubeadm upgrade 完成，但 etcd 备份、版本兼容和滚动升级策略仍需自己规划；网络插件必须另外选择安装；大规模生产环境下，etcd 性能、证书轮换、安全加固等事项都需要团队具备一定运维能力。
二、使用 kubeadm 创建集群的完整步骤与关键配置
创建集群前，需要先完成节点基础环境准备。以 Ubuntu 或 CentOS 为例，每台节点都要设置唯一主机名，关闭 swap，加载 br_netfilter 模块，并开启内核参数 net.bridge.bridge-nf-call-iptables=1。容器运行时推荐使用 containerd，安装后需要确认 /etc/containerd/config.toml 中的 Cgroup Driver 与 kubelet 保持一致，通常都设置为 systemd。接着通过 Kubernetes 官方软件源安装 kubeadm、kubelet 和 kubectl，并固定版本，避免误升级导致集群版本不一致。
初始化控制平面时，最简单的做法是直接执行如下命令：
sudo kubeadm init \ --pod-network-cidr=10.244.0.0/16 \ --kubernetes-version=v1.28.0 \ --image-repository=registry.aliyuncs.com/google_containers
这里使用 --pod-network-cidr 指定 Pod 网段，后续安装 Flannel 时需要保持网段一致。--image-repository 用于替换默认的 k8s.gcr.io，避免国内网络无法拉取镜像。如果希望把配置固化下来，可以使用 kubeadm-config.yaml 文件：
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.28.0
imageRepository: registry.aliyuncs.com/google_containers
controlPlaneEndpoint: "172.16.10.10:6443"
networking:
podSubnet: 10.244.0.0/16
serviceSubnet: 10.96.0.0/12
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
nodeRegistration:
criSocket: unix:///var/run/containerd/containerd.sock
name: master01
taints:
- effect: NoSchedule
key: node-role.kubernetes.io/control-plane执行 sudo kubeadm init --config kubeadm-config.yaml 后，kubeadm 会按照文件内容初始化。完成后需要根据提示创建 kubeconfig 文件：mkdir -p $HOME/.kube && sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config && sudo chown $(id -u):$(id -g) $HOME/.kube/config。接下来安装网络插件，Flannel 可以使用 kubectl apply -f 安装官方的 kube-flannel.yml，Calico 则根据 Pod 网段调整 manifest。网络插件就绪后，控制平面节点会从 NotReady 变为 Ready。
工作节点加入集群时，先在控制平面执行 kubeadm token create --print-join-command 获取完整 join 命令，然后在工作节点上以 root 权限执行。命令包含 apiserver 地址、bootstrap token、discovery-token-ca-cert-hash 以及可选的 criSocket 参数。加入成功后，控制平面会签发节点证书，kubelet 开始向 apiserver 注册节点信息。可以通过 kubectl get nodes 查看节点状态，通过 kubectl get pods -A 确认 kube-system 命名空间下所有 Pod 均处于 Running 状态。
三、常见问题与注意事项
kubeadm init 失败最常见的原因是容器运行时未就绪或 Cgroup Driver 不一致。如果 containerd 配置中使用了 cgroupfs，而 kubelet 默认使用 systemd，就会导致 kubelet 反复重启。可以通过 systemctl status kubelet 和 journalctl -xeu kubelet 查看日志，确认 containerd 的 socket 文件是否存在，以及 /etc/containerd/config.toml 中 SystemdCgroup 是否为 true。另一个高频问题是镜像拉取失败，表现为 init 卡在 pulling image 阶段。解决办法是先执行 sudo kubeadm config images pull --image-repository=registry.aliyuncs.com/google_containers 验证镜像源连通性，再重新初始化。
节点加入集群后长期处于 NotReady，通常是因为网络插件没有安装成功，或者 CNI 配置文件与插件版本不匹配。可以先检查 kube-system 命名空间下网络插件的 DaemonSet 是否已经调度到该节点，再查看对应 Pod 日志。如果节点已经 Ready，但 CoreDNS 一直 Pending，多半是 Pod 网络尚未通，或者 kube-proxy 没有正常启动。证书过期也是 kubeadm 集群绕不开的问题，默认 CA 有效期十年，但 apiserver、front-proxy 等证书只有一年。可以通过 kubeadm certs check-expiration 查看证书到期时间，使用 kubeadm certs renew all 批量续期，并重启控制平面组件使其生效。
生产环境使用 kubeadm 时还要注意高可用配置。单控制平面一旦宕机，集群 API 将不可用。多控制平面部署需要在前面放置一个 TCP 负载均衡器，把 6443 端口分发到多个 master 节点，并在 ClusterConfiguration 中设置 controlPlaneEndpoint 为负载均衡地址。etcd 可以选择与 master 节点堆叠部署，也可以使用外部 etcd 集群。无论哪种方式，都建议使用 SSD 磁盘并定期执行 etcd 快照备份，防止数据损坏后无法恢复。此外，所有节点的时钟应通过 NTP 保持同步，避免证书验证和日志时间错乱。
四、选购建议：从测试到生产的硬件与方案选择
测试环境可以选择 2 核 CPU、4GB 内存、40GB 磁盘的虚拟机，部署一个控制平面和两个工作节点即可。控制平面节点内存建议不低于 4GB，因为 apiserver、etcd、controller-manager、scheduler 以及 kubelet 本身都会占用内存，资源不足容易导致 Pod 驱逐。工作节点根据业务容器数量分配，一般 4 核 8GB 可以支撑几十个轻量 Pod。磁盘方面，etcd 对 IO 敏感，建议使用 SSD，即使测试环境也尽量避免使用网络存储挂载根分区。
生产环境推荐控制平面至少 3 个节点，工作节点根据业务规模横向扩展。控制平面节点建议 4 核 8GB 起步，工作节点 8 核 16GB 以上。etcd 如果独立部署，建议 3 或 5 个节点，使用高性能 SSD，并在不同物理机或机架分散部署。网络插件选择上，Flannel 配置简单、资源占用低，适合中小集群；Calico 支持网络策略、性能较好，适合对安全隔离有要求的场景；Cilium 基于 eBPF，可观测性强，适合大规模和云原生网络需求。负载均衡器可以使用 HAProxy、Nginx 或云厂商的 TCP 负载均衡，关键是要支持健康检查和会话保持。
如果团队没有专职 Kubernetes 运维人员，或者业务对 SLA 要求极高，可以考虑在云平台上使用托管 Kubernetes 服务，把控制平面和 etcd 交给云厂商维护。但如果需要保留底层控制权、满足合规要求或运行在私有化环境中，kubeadm 仍然是成本最低、透明度最高的选择。无论选择哪种方案，都要提前规划好镜像仓库、日志收集、监控告警和备份恢复机制，这些能力才是集群长期稳定运行的核心保障。
Kuberneteskubeadm集群初始化修改时间：2026-08-30 14:43:22