K8s集群搭建实战：从零开始的完整指南

作者：渣渣辉2026.11.07 02:19浏览量：0

简介：本文面向初次接触Kubernetes的开发者，系统性地梳理了从环境准备、Master节点初始化、容器网络插件安装到Worker节点接入的完整流程。通过清晰的操作步骤与脚本化的实现思路，帮助读者理解K8s集群搭建的核心逻辑与常见问题的排查方法，最终获得一个健康可用的生产就绪型集群环境。

Kubernetes（简称K8s）作为当今云原生生态的基石，其集群搭建是每一位开发者迈向容器编排领域的第一步。然而，新手在初次尝试时往往会被繁琐的初始化步骤、网络插件选择以及节点间通信配置所困扰。本文将以一套经过验证的实操路径为主线，深入拆解K8s集群搭建的每一个关键环节，并结合常见的坑点提供排查思路，助你高效、平稳地完成从零到一的集群构建。

一、集群环境规划与前置准备

在动手执行任何命令之前，清晰的环境规划是成功的一半。K8s集群至少需要两个节点：一个作为控制平面（Master），负责API服务、调度与状态管理；另一个或多个作为工作节点（Worker），用于运行实际的应用负载。

1. 操作系统与硬件要求

  • 操作系统：推荐使用主流的Linux发行版（如CentOS 7.9、Ubuntu 20.04+），内核版本建议不低于3.10，以支持必要的网络与存储特性。
  • 资源要求：Master节点建议分配2核CPU、4GB内存以上；Worker节点则依据业务规模，通常建议2核4GB起步。
  • 网络互通：所有节点之间需保证内网互通，且关闭交换分区（swap），这是K8s调度器运行的硬性前提。若无法物理关闭，至少在系统层面通过swapoff -a临时禁用，并在/etc/fstab中注释相关挂载行。

2. 系统基础参数调整
K8s对系统参数有严格要求，通常需要调整以下内容：

  • 内核网络参数：启用net.bridge.bridge-nf-call-iptables和net.ipv4.ip_forward，以确保iptables规则能够正确作用于容器网络。
  • 防火墙策略：若使用云厂商安全组或本地firewalld，需放通Master的6443（API Server）、2379-2380（etcd）、10250（kubelet）等端口，以及Worker的10250端口。为简化初期部署，建议暂先关闭防火墙服务，待集群稳定后再进行精细化安全策略配置。

二、核心组件安装：脚本化实践

为了使安装过程可重复、少出错，将组件安装步骤封装为脚本是最高效的做法。该脚本的核心职责是完成三件事：配置YUM源、安装容器运行时、安装K8s核心组件（kubelet、kubeadm、kubectl）。

脚本执行逻辑剖析（示意代码，非完整可执行脚本）：

  1. # 1. 配置镜像仓库源（此处省略具体仓库地址，请使用你所在区域的可用源）
  2. cat <<EOF > /etc/yum.repos.d/kubernetes.repo
  3. [kubernetes]
  4. name=Kubernetes
  5. baseurl=https://mirrors.xxx.com/kubernetes/yum/repos/kubernetes-el7-x86_64
  6. enabled=1
  7. gpgcheck=0
  8. EOF
  10. # 2. 安装容器运行时（以containerd为例，需提前配置其Cgroup驱动为systemd）
  11. yum install -y containerd.io
  12. mkdir -p /etc/containerd
  13. containerd config default > /etc/containerd/config.toml
  14. sed -i 's/SystemdCgroup = false/SystemdCgroup = true/g' /etc/containerd/config.toml
  15. systemctl restart containerd
  17. # 3. 安装K8s组件
  18. yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes
  20. # 4. 启动kubelet服务（此时尚未初始化，kubelet会不断重启等待集群指令，属正常现象）
  21. systemctl enable kubelet && systemctl start kubelet

在Master和Worker节点上依次执行该脚本，是构建集群的基石。请务必检查脚本执行后的输出日志，确保无报错。

三、Master节点初始化与控制平面部署

Master节点的初始化是集群搭建的核心环节，其过程决定了集群的CIDR网段、API Server的广播地址以及各类证书的生成。

1. 生成初始化配置文件
直接使用kubeadm init命令虽可快速启动，但为了后续的扩展与定制，更推荐先生成一份配置文件，再基于该文件执行初始化。关键配置项集中在controlPlaneEndpoint（用于高可用场景或设置固定的API Server访问地址）和podSubnet（Pod 网络的CIDR，需与后续安装的CNI插件要求匹配）上。

  1. # 生成默认配置文件到当前目录
  2. kubeadm config print init-defaults > kubeadm-init.yaml
  4. # 编辑该文件，将advertiseAddress改为本机IP，并设置podSubnet
  5. vim kubeadm-init.yaml

2. 执行初始化并验证
编辑完毕后，执行kubeadm init --config kubeadm-init.yaml。初始化成功后，控制台会输出三部分关键信息：

  • kubectl配置指令：需要执行mkdir -p $HOME/.kube和cp命令，以便当前用户有权限管理集群。
  • 安装CNI插件的提示：这一步骤至关重要，初始化成功后节点状态为NotReady正是由于缺少网络插件。
  • 加入集群的Token指令：此命令会包含一个固定Token和CA证书哈希，需妥善保存以备Worker节点加入。

完成初始化后，运行kubectl get nodes，你会看到Master节点状态为NotReady，这是预期内的现象，下一步即为修复的重点。

四、容器网络插件（CNI）的选择与部署

NotReady状态的根源在于节点间的Pod网络尚未打通。Kubernetes本身不提供网络解决方案，需要借助CNI插件来实现跨节点通信。

目前行业主流的CNI方案有两个方向：

1. Calico——推荐的生产级选择
Calico基于BGP路由协议，性能损耗小，支持精细化的网络策略（NetworkPolicy），能够满足复杂的企业安全合规需求。其部署只需一条命令：

  1. kubectl apply -f calico.yaml

注意：calico.yaml中的CALICO_IPV4POOL_CIDR必须与初始化时配置的podSubnet保持一致，否则网络无法互通。等待Pod拉取镜像并启动，通常1-2分钟内即可完成。

2. Flannel——轻量但坑点较多
Flannel使用VXLAN或host-gw模式构建overlay网络，配置简单，但存在跨主机通信效率相对较低、对NetworkPolicy支持不完善等局限性。其部署方式为：

  1. kubectl apply -f kube-flannel.yml

部署后，你需要持续关注kube-flannel命名空间下的Pod状态，它们需要从Init状态过渡到Running，此过程受网络环境拉取镜像速度影响，可能需要稍长时间。

观察与验证：
执行kubectl get pods -A，当所有Pod呈现Running状态后，再次执行kubectl get nodes，此时应当看到Master节点的状态变为Ready。

补充场景：从Flannel迁移至Calico
若早期选择了Flannel但遇到问题较多，切换至Calico并不复杂：先删除旧的Flannel资源配置，再清理容器内的残留路由规则；最后应用Calico的YAML文件。核心在于确保集群Node上无旧虚拟网卡（如flannel.1）残留，否则新插件会因地址冲突而无法正常工作。

五、Worker节点接入与集群验证

Master节点就绪后，工作节点的接入就是一条线性命令的操作。

1. 获取加入令牌
在Master节点上执行：

  1. kubeadm token create --print-join-command

该命令会输出完整的kubeadm join指令，其中包含了全新的Token及用于校验的CA证书的SHA256哈希值。

2. Worker节点执行加入
将Master输出的指令复制到Worker节点终端执行。加入过程会拉取必要的镜像并启动kubelet服务。若遇到超时或证书校验失败，多数情况下与系统时间不同步有关，请确保各节点时间一致。

3. 终态验证
返回Master节点，运行kubectl get nodes，你应看到Worker节点状态逐步转为Ready。此时，一个具备高可用基础（单控制平面）的K8s集群已经完全搭建完成。可以通过以下命令做一次端到端验证：

  1. kubectl run nginx-test --image=nginx
  2. kubectl get pods -o wide

观察Pod能否被调度到Worker节点并成功运行，从而确认整个集群的调度与网络转发链路均正常。

六、常见故障排查与经验总结

集群搭建过程中的“坑”往往集中在时间同步、镜像拉取和网络转发三层。以下梳理三条高频排障锦囊：

  • 镜像拉取失败：由于网络隔离原因，默认的镜像仓库可能无法访问。解决思路是配置镜像加速器，或通过离线镜像包导入到各节点。例如，可提前在能连通公网的环境用docker pull拉取所需镜像，然后使用ctr -n k8s.io images import导入到对应节点的containerd中。
  • CoreDNS 一直CrashLoopBackOff：通常是podSubnet配置错误或CNI插件未就绪导致。检查CNI的Pod日志，并核对初始化配置中的网段与CNI YAML中的网段是否一致。
  • 证书过期问题：若集群闲置较久，kubeadm生成的证书（默认一年有效期）可能过期。在正式使用前，建议通过kubeadm certs check-expiration检查证书有效期，并规划好续期机制。

结语

K8s集群的搭建不仅是执行几条命令，更是一次对容器编排底层逻辑的梳理。从系统核心参数调优到CNI网络模型选型，再到节点间的信任建立，每一步都在为后续的稳定运行奠定基础。希望这篇实战指南能帮助你跨过初期的门槛，顺利进入容器编排的广阔世界。在完成本集群搭建后，下一步便可着手研究应用发布策略、服务发现与持久化存储等高阶议题了。

最热文章