K8s集群搭建步骤：从环境准备到上线验证的完整清单

K8s集群搭建步骤，表面上看像是一串安装命令，真正落地时却更像一份平台交付清单。很多团队第一次搭集群时，容易把注意力放在 kubeadm init 这一条命令上，但最后出问题的往往不是初始化本身，而是主机规划、时间同步、容器运行时、网络插件、镜像源、节点加入和上线前验证这些前后环节没有串起来。

如果你现在要做一套测试环境、项目集群或生产前 PoC，本文更适合你按阶段执行。内容会以 kubeadm + containerd 这条常见路线为主，因为它最符合多数企业从 0 到 1 搭建 Kubernetes 集群时的实际路径。

写在前面

• 本文适用场景： 新建 Kubernetes 测试集群、PoC 集群或中小规模生产前验证环境。
• 本文前置知识： 需要知道 Linux 基础操作、网络连通、SSH、镜像仓库和容器基本概念。
• 本文环境说明： 示例以 Linux 服务器、containerd、kubeadm、单控制平面 + 多工作节点为主；如果你做高可用控制平面，可在相同步骤上扩展负载均衡和多控制平面节点配置。

如果把整个搭建过程压缩成一张图，通常会经过下面这些阶段：

你可以先把它理解成一条主线：先把节点准备好，再把控制平面拉起来，然后接入工作节点，最后通过网络、DNS、Service 和业务样例验证整套集群可用。

为什么 K8s 集群搭建不能只看安装命令

很多教程把重点写成“先执行什么命令，再执行什么命令”，这当然有帮助，但如果缺少上下文，团队很容易在下面几个地方反复返工：

• 机器规格不一致，导致节点表现不稳定
• 主机名、IP、DNS 没有提前规划，后续排障困难
• containerd 和 kubelet 的 cgroup 驱动不一致
• 镜像拉取路径没准备好，初始化阶段卡住
• 集群 Ready 了，但 CoreDNS、跨节点通信、Service 访问并不正常
• 测试环境能跑，生产上线后才发现日志、监控、备份完全没补齐

所以更合理的方式，不是把 K8s 搭建看成一次安装，而是把它看成四层任务：

1. 基础设施准备
2. 集群组件安装
3. 网络与节点接入
4. 最小可用与生产级验证

K8s 集群搭建前，先定这 4 个关键问题

在真正进入操作步骤前，建议先把下面四件事定下来，否则后面做的很多决定都会反复变动。

1. 这套集群到底是给谁用

先区分清楚它是：

• 个人学习 / 实验环境
• 项目测试环境
• 业务预发环境
• 生产环境

这个判断会直接决定：

• 是否需要高可用控制平面
• 是否需要独立镜像仓库
• 是否必须接监控、日志、告警
• 是否要做多租户和权限边界

2. 控制平面和工作节点怎么规划

最常见的起步方案通常可以这样理解：

如果只是测试环境，单控制平面可以快速起步；如果目标是生产，建议从一开始就按高可用思路规划 IP、域名和控制平面入口，否则后续扩展会比较痛苦。

3. 网络、主机名和地址段是否提前定好

Kubernetes 最怕“先装起来再说”。至少要先明确：

• 节点主机名规范
• 管理网 IP 规划
• Pod 网段
• Service 网段
• DNS 解析方案
• 是否要与现有 IDC / 云上网络互通

一个常见原则是：Pod 网段、Service 网段不要和现有业务网段冲突。 一旦冲突，后面 Service 访问、DNS 转发、跨网络互通都会变复杂。

4. 你打算用什么安装路径

当前企业里最常见的几条路线包括：

• kubeadm：最通用，适合理解原理和做标准化安装
• 各类发行版 / 企业平台：更适合平台化交付
• 托管 Kubernetes：更适合不想自己管控制平面的团队

如果你现在搜索的就是 K8s集群搭建步骤，大概率还是在做自建或半自建场景，因此本文默认用 kubeadm 作为主线。

步骤 1：准备节点基础环境

真正进入安装前，先把所有节点做成“适合安装 Kubernetes 的状态”。这一步做得越规范，后面越省时间。

基础检查清单

• 操作系统版本统一
• 内核能力满足容器运行要求
• 节点时间同步正常
• 主机名可区分且可解析
• 各节点之间 SSH 与网络互通
• 防火墙策略提前确认
• 磁盘空间足够存放镜像、日志和运行时数据
• 能访问所需镜像源或内部镜像仓库

必做初始化项

下面这些动作在大多数基于 kubeadm 的 Linux 环境里，通常都属于搭建前必做项。因为这些命令有明确的执行顺序和参数细节，这里保留标准 shell 代码块更合适，也建议发布时保留语法高亮，这样读者复制和排查都会更直接。

# 设置主机名（示例）
hostnamectl set-hostname k8s-master-01

# 确认时间同步状态
timedatectl status

# 关闭 swap（当前会话）
swapoff -a

# 注释掉 /etc/fstab 中的 swap，避免重启后恢复
sed -ri '/sswaps/s/^/#/' /etc/fstab

# 加载容器网络相关内核模块
modprobe overlay
modprobe br_netfilter

# 写入内核参数
cat > /etc/sysctl.d/k8s.conf <<'EOF'
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF

# 使配置生效
sysctl --system

这里最容易漏掉的是 swap、内核模块和转发参数。如果这些没处理好，后面 kubelet 或网络插件通常会直接报错。

如果你写的是偏操作型文章，像这类“读者很可能直接复制执行”的内容，应该保留代码块，不建议改写成纯正文或行内命令；只有在概念解释、选型分析这类文章里，才不需要强行补代码块。

步骤 2：安装容器运行时 containerd

Kubernetes 现在最常见的运行时选择是 containerd。相比历史上的 Docker Shim 路线，它更符合当前主流生产实践。

为什么这一步很关键

因为 Kubernetes 并不直接运行容器，它依赖 CRI 兼容运行时去完成：

• 镜像拉取
• 容器生命周期管理
• 日志与运行状态维护
• Pod Sandbox 创建

如果运行时本身没装好，后面即使 kubeadm init 能执行，节点也可能迟迟起不来业务 Pod。

containerd 配置重点

安装完成后，重点检查两件事：

1. containerd 服务是否正常启动
2. SystemdCgroup 是否与 kubelet 对齐

常见示例：

# 生成默认配置
mkdir -p /etc/containerd
containerd config default > /etc/containerd/config.toml

# 启用 systemd cgroup 驱动
sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml

# 重启并设置开机自启
systemctl restart containerd
systemctl enable containerd

# 查看运行时状态
systemctl status containerd --no-pager

> 在 kubeadm 场景下，kubelet 和 containerd 的 cgroup 驱动保持一致，是最基础也最容易被忽视的稳定性前提。

如果你所在环境访问公网镜像源受限，还应该提前准备镜像代理或私有镜像仓库。否则初始化阶段会卡在镜像拉取上，而不是卡在 Kubernetes 本身。

步骤 3：安装 kubeadm、kubelet 和 kubectl

这三个组件是标准安装路径的核心：

• kubeadm：负责初始化与节点加入
• kubelet：节点代理，负责和控制平面协同
• kubectl：命令行管理工具

安装完成后，先不要急着初始化，建议先确认版本：

kubeadm version
kubelet --version
kubectl version --client

这里有两个实践建议：

• 尽量锁定一个明确版本，不要所有机器直接拉最新。
• 控制平面和工作节点保持版本一致，再考虑后续升级路径。

如果你是企业环境，建议把版本、镜像源、内核参数、运行时配置都沉淀成自动化脚本或 Ansible 模板，不要靠人工一台台敲。

步骤 4：初始化控制平面节点

当所有前置条件都准备好后，才进入真正的控制平面初始化。

一个常见示例：

kubeadm init 
  --apiserver-advertise-address=10.0.0.10 
  --pod-network-cidr=10.244.0.0/16 
  --kubernetes-version=v1.29.0

这条命令背后做的事情包括：

• 初始化证书与集群配置
• 启动 API Server、Scheduler、Controller Manager
• 初始化 etcd
• 生成 admin.conf
• 输出工作节点加入命令

初始化成功后，别忘了为当前用户准备 kubectl 配置：

mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config

kubectl get nodes

如果你此时看到控制平面节点还不是 Ready，不要着急。在网络插件安装前，控制平面节点和 CoreDNS 组件还没有完全稳定，属于正常现象。

步骤 5：安装 CNI 网络插件

Kubernetes 集群初始化完成后，下一步几乎总是网络插件。没有 CNI，Pod 之间通常无法正常通信，CoreDNS 也经常会卡住。

常见选择包括：

• Calico：功能完整，企业场景常见
• Flannel：简单直接，适合轻量环境
• Cilium：eBPF 能力更强，适合更高要求场景

示例：

# 以 Calico 示例，实际 URL 与版本请按官方文档确认
kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/calico.yaml

# 查看关键组件状态
kubectl get pods -n kube-system

如果从集群架构角度看，控制平面、工作节点和网络插件的关系大致如下：

安装完成后，重点看这几类资源：

• coredns
• kube-proxy
• 网络插件自己的 DaemonSet / Pod

只要这些组件长期 Pending、CrashLoopBackOff 或 ContainerCreating，通常都说明网络、镜像或节点基础环境还有问题。

步骤 6：把工作节点加入集群

控制平面就绪后，再让工作节点通过 kubeadm join 接入集群。

示例命令通常会在 kubeadm init 的输出中直接给出：

kubeadm join 10.0.0.10:6443 
  --token <token> 
  --discovery-token-ca-cert-hash sha256:<hash>

加入完成后，在控制平面执行：

kubectl get nodes -o wide

这一阶段建议重点确认：

• 新节点能否正常注册
• 节点角色是否符合预期
• Ready 状态是否稳定
• kubelet 是否持续报错
• 容器运行时是否正常拉取基础镜像

如果你要给节点做污点、标签、专用资源池，也建议从这个阶段开始规范化处理，而不是业务跑起来后再补。

步骤 7：完成最小可用验证

很多团队把“节点都 Ready”当成集群搭建完成，但这还远远不够。至少还要做一轮最小可用验证，确认集群不只是装好了，而是真的能承载应用。

验证 1：创建测试 Deployment

kubectl create deployment nginx-test --image=nginx:1.27
kubectl scale deployment nginx-test --replicas=2
kubectl get pods -o wide

你要确认的不只是 Pod 是否启动，还要看：

• 是否能调度到不同节点
• 镜像拉取是否正常
• 是否存在探针或事件异常

验证 2：创建测试 Service

kubectl expose deployment nginx-test --port=80 --type=ClusterIP
kubectl get svc

如果 ClusterIP 已创建，下一步就该验证 DNS 和 Service 访问链路。

验证 3：检查集群 DNS

kubectl run dns-test --image=busybox:1.36 -it --rm --restart=Never -- nslookup kubernetes.default

如果这里解析失败，通常优先排查：

• CoreDNS 是否正常
• CNI 是否正常
• 节点到 Service 网段的访问是否有问题

验证 4：查看事件与节点状态

kubectl get events -A --sort-by=.lastTimestamp
kubectl describe node k8s-worker-01

> 新集群最应该养成的习惯，不是“出问题先重装”，而是先看事件、节点状态和系统组件日志。

步骤 8：补齐生产前必须完成的基础能力

如果你的目标不是实验环境，而是准备把真实业务迁进去，那么在“集群可用”之后，还要继续补下面这些能力。

权限和访问控制

至少要明确：

• 谁能看集群
• 谁能发版
• 谁能读日志
• 谁能操作命名空间
• 是否启用细粒度 RBAC

日志、监控和告警

新集群如果没有可观测性能力，线上问题会很难定位。最少应补：

• 节点与容器指标
• 应用日志采集
• 告警规则
• 容量水位观察

存储、备份与恢复

只要业务开始使用 PVC，就不能只盯着集群本身，还要看：

• StorageClass 是否稳定
• 动态供给是否正常
• 数据如何备份
• etcd 如何备份与恢复

升级与变更流程

真正稳定的 Kubernetes 集群，不是“第一次搭好”，而是后面还能：

• 平滑升级版本
• 替换节点
• 扩容缩容
• 回滚异常变更

K8s 集群搭建过程中最常见的 6 个坑

1. 节点基础环境不一致

A 节点能跑、B 节点异常，很多时候不是 Kubernetes 问题，而是 OS、内核、时钟、DNS 或磁盘条件本来就不一致。

2. 运行时和 kubelet 参数不匹配

尤其是 cgroup 驱动不一致，会带来一堆看似随机的问题。

3. 网络插件装了，但 Pod 还是不通

这时不要只看插件是否 Running，还要看：

• Pod 网段是否冲突
• 节点之间路由是否可达
• 防火墙是否放行
• 内核转发是否生效

4. 只验证了节点，不验证业务链路

kubectl get nodes 没问题，不代表应用真的能跑。Deployment、Service、DNS、跨节点通信都要验证。

5. 测试集群思路直接照搬生产

测试环境可以简化，生产环境不能忽略：

• 高可用
• 备份恢复
• 权限分层
• 监控告警
• 变更流程

6. 所有配置都靠人工操作

如果后续还要重复搭建、扩容或交付多个环境，强烈建议把基础配置脚本化。能自动化的步骤越多，后面排障和扩展越稳。

一个更实用的 K8s 集群验收清单

如果你想知道“这套集群现在到底算不算搭完”，可以直接对照下面这份清单：

总结：K8s 集群搭建步骤的重点，不是装完而是验收通过

回到 K8s集群搭建步骤 这个问题，最实用的理解方式不是背命令，而是按阶段推进：先规划节点和网络，再准备操作系统和 containerd，再安装 kubeadm / kubelet / kubectl，接着初始化控制平面、安装网络插件、加入工作节点，最后用 Deployment、Service、DNS 和事件检查完成验收。

如果你只是想快速起一个测试集群，做到“节点 Ready + 基础业务链路可验证”就已经够了；如果你准备承接真实业务，那么真正的完成标准还包括权限、监控、日志、备份和升级流程。Kubernetes 集群搭建，从来不是一次安装动作，而是一套可交付、可验证、可持续演进的平台建设过程。

FAQ

K8s 集群搭建一定要用 kubeadm 吗？

不一定。kubeadm 是最常见也最通用的自建路径，但企业也可以使用发行版、平台产品或托管 Kubernetes 服务。

单节点能不能算 K8s 集群？

学习环境可以，测试场景也可以临时使用；但只要承载正式业务，通常还是建议至少采用多节点方案。

集群节点显示 Ready 就代表可以上线吗？

还不够。至少还要验证 Pod 调度、Service 访问、DNS 解析、事件状态，以及后续日志监控和权限方案。

新集群最值得优先排查什么？

优先看 节点基础环境、containerd 状态、CNI 网络插件、CoreDNS 和集群事件，这些往往比重装更能定位问题。