VMware虚拟机部署三节点Kubernetes 1.29.14集群完整教程

这次我们不说概念，直接给一套能照着落地的环境：在 VMware Workstation 虚拟机里，部署一个由 3 个节点组成的 Kubernetes 1.29.14 集群。这套环境适合做什么？适合快速验证 Kubernetes 调度、跑小型工作负载、练习 kubeadm 命令、给本地开发提供一套与云环境隔离的测试集群。如果你正准备学 K8s，又不想直接在本机装组件污染系统，这篇文章可以直接收藏。

为什么要用 VMware 虚拟机而不是直接在本机装 Kubernetes？原因很简单：隔离性好、快照可回滚。三台虚拟机分别承担控制平面和 worker 节点角色，误操作之后恢复快照就能继续跑，比重新初始化集群省太多时间。而且 VMware Workstation 对虚拟化支持很成熟，NAT 网络开箱即用，不需要额外配置复杂路由。

这篇教程会从虚拟机创建开始，一直写到部署 Nginx 验证集群可用，覆盖系统初始化、containerd 安装、kubeadm 初始化、节点加入、CNI 网络插件安装、资源占用观察和常见故障排查。想直接看核心规格的，看第 1 节；想照着搭的，从第 3 节开始；只关心排错的，可以直接跳到第 9 节。

先说结论：这套三节点集群对宿主机的要求不算高，核心是内存够用。建议宿主机 16GB 内存起步，每个节点分配 2 核 CPU、4GB 内存、40GB 磁盘。节点操作系统推荐 Ubuntu Server 22.04 LTS 或兼容的 Linux 发行版，容器运行时使用 containerd，集群初始化工具使用 kubeadm。

1. 核心能力速览

先看这套三节点 Kubernetes 1.29.14 运行环境的整体规格，方便判断它是否适合你的使用场景。

从这些规格能看出，它的定位不是生产级高可用集群，而是本地可重复搭建的运行环境。控制平面只有一份，master 节点挂掉整个集群就无法调度，但这正好适合学习场景：三节点可以完整演示 K8s 的调度、Pod 分布、NodePort 服务暴露等核心机制。

网络方面，VMware NAT 模式天然支持虚拟机组网。三台虚拟机处于同一个 NAT 网段，既可以把集群对外通信收敛到宿主机，又可以模拟一个独立的局域网环境。后面配置静态 IP 时，只需要在 VMware 的 NAT 设置里确认网段和网关即可。

2. 适用场景与使用边界

这套 VMware 虚拟机三节点集群环境，最值得用的场景有三种。

第一，Kubernetes 入门和认证练习。CKA 考试里常见的操作，比如部署工作负载、配置 Service、管理 ConfigMap、查看 Pod 日志，全部可以在三节点环境里练。考试前打一个干净快照，练坏了直接回滚，体验比租云服务器好很多。

第二，本地中间件集群测试。项目标题和热搜词里大量出现 Kafka、Redis、Spark 集群，这类中间件在单机上很难验证真正的分布式行为。用三节点 K8s 环境部署一个 Redis Cluster 或 Kafka 集群，可以完整观察数据分片、故障转移和集群调度过程。

第三，CI/CD 流水线联调。本地或内网开发时，把构建产物通过镜像推送到私有仓库，再部署到这个 K8s 环境里，可以模拟一套接近生产的小型发布流程。

不适用什么场景？如果追求极致性能或做高并发压测，VMware 虚拟机并不合适，虚拟化层会带来额外开销。如果要做生产级高可用，这套单 master 三节点架构也达不到要求，至少需要 3 个控制平面节点和负载均衡层。

使用边界方面，集群内跑的应用、镜像、中间件必须确保来源合规。涉及版权素材、人脸、敏感数据时，不要在本地测试集群里直接处理。快照虽然能方便回滚，但它不是备份系统，磁盘损坏或 VMware 数据文件丢失时，快照同样救不回来。

3. 环境准备与前置条件

这套环境不需要特殊的网络设备，一台带虚拟化支持的普通电脑或工作站就够。但有几个前置条件需要先确认。

3.1 宿主机硬件建议

建议按以下配置准备宿主机：

内存是这套环境的决定性因素。三台虚拟机如果每台分配 4GB，加上宿主机本身系统占用，16GB 内存会偏紧张，32GB 体验更好。磁盘方面，Ubuntu Server 系统本身占用约 10GB，加上 containerd 镜像缓存、K8s 组件日志和快照文件，三台虚拟机很容易吃掉 80GB 以上空间。

3.2 VMware 软件与系统镜像

宿主机安装 VMware Workstation Pro 17 或更新版本。创建虚拟机前准备好 Ubuntu Server 22.04 LTS 的 ISO 镜像，下载 ubuntu-22.04.x-live-server-amd64.iso 即可。如果已经习惯 CentOS Stream 或 Rocky Linux，同样可以用，只需把后面命令中基于 apt 的安装步骤替换成对应的 dnf/yum 版本。

安装 Ubuntu Server 时不要选太多额外组件。建议最小安装，只启用 OpenSSH server。这样后续操作可以全部通过 SSH 完成，虚拟机窗口关掉也不影响。

3.3 三节点资源规划

三台虚拟机规划如下，IP 地址以 VMware NAT 实际网段为准：

这里需要特别注意，三台虚拟机的 IP 必须保持在同一个 VMware NAT 网段内。可以在 VMware 的「编辑 -> 虚拟网络编辑器」里查看 NAT 网段的网关地址和掩码，后面配置静态 IP 时要用到。

3.4 网络模式选择

虚拟机创建时选择 NAT 模式。NAT 模式的好处是虚拟机可以访问外网拉取软件包和镜像，同时集群内部节点之间的通信天然互通。相比桥接模式，NAT 不依赖宿主机所在局域网的具体环境，换一个 WiFi 或办公室网络也不会导致虚拟机 IP 失效。

4. 虚拟机创建与系统初始化

从这一节开始，逐步搭建三节点集群。后面所有命令都是基于 Ubuntu Server 22.04 LTS 写的，IP 和主机名需要按你的实际环境替换。

4.1 在 VMware Workstation 中创建三台虚拟机

操作步骤：

1. 新建虚拟机，选择「典型」安装。
2. 安装来源选择「安装程序光盘映像文件」，指向 Ubuntu Server ISO。
3. 自定义硬件：内存 4GB，处理器 2 核，磁盘 40GB。
4. 网络类型选 NAT。
5. 启动虚拟机，完成 Ubuntu Server 最小安装，勾选 OpenSSH server。

三台虚拟机可以一台一台安装，也可以安装完第一台后，在关机状态下右键「管理 -> 克隆」创建链接克隆，再分别修改主机名和 IP。链接克隆能大幅节省磁盘空间，但要注意如果通过快照继续克隆，后续 IP 和主机名冲突问题要仔细处理。第一次搭建建议老老实实逐台创建，避免踩坑。

4.2 设置主机名与 hosts 映射

三台虚拟机分别设置主机名：

bash复制# master 节点
sudo hostnamectl set-hostname master-node

# node1 节点
sudo hostnamectl set-hostname node1

# node2 节点
sudo hostnamectl set-hostname node2

然后在三台虚拟机的 /etc/hosts 中加入同样的内容，把 IP 换成实际地址：

bash复制sudo tee -a /etc/hosts > /dev/null <<EOF
192.168.x.10 master-node
192.168.x.11 node1
192.168.x.12 node2
EOF

这样后续 kubeadm join 和 kubectl 通过主机名访问节点时，就不会依赖 DNS 解析。

4.3 配置静态 IP

Ubuntu Server 22.04 使用 netplan 管理网络。先查看网卡名称，一般是 ens33：

bash复制ip addr show

然后编辑 netplan 配置文件，示例内容如下：

yaml复制network:
  version: 2
  renderer: networkd
  ethernets:
    ens33:
      addresses:
        - 192.168.x.10/24
      routes:
        - to: default
          via: 192.168.x.2
      nameservers:
        addresses:
          - 192.168.x.2
          - 8.8.8.8

注意，网关地址要写成 VMware NAT 虚拟网络的网关，通常和虚拟机 IP 同网段且以 .2 结尾。应用配置：

bash复制sudo netplan apply
ip addr show ens33

确认 IP 修改生效后，退出当前 SSH 会话重新连接，避免后续操作连错节点。

4.4 内核模块与系统参数

Kubernetes 需要开启网络过滤和 IP 转发。三台节点都要执行。

加载内核模块：

bash复制cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

配置系统参数：

bash复制cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF

sudo sysctl --system

检查配置是否生效：

bash复制sysctl net.bridge.bridge-nf-call-iptables
sysctl net.ipv4.ip_forward

如果两个值都输出 1，说明内核准备完成。

4.5 关闭 swap

kubelet 默认要求关闭 swap。关闭当前 swap 并注释掉永久挂载配置：

bash复制sudo swapoff -a
sudo sed -i '/ swap / s/^/#/' /etc/fstab

使用 free -h 确认 swap 为 0。检查 /etc/fstab，确保 swap 行已被注释。

4.6 安装 containerd

Kubernetes 1.29 默认通过 CRI 调用 containerd。Ubuntu 官方 apt 源里有 containerd，直接安装：

bash复制sudo apt-get update
sudo apt-get install -y containerd

生成默认配置：

bash复制sudo mkdir -p /etc/containerd
sudo containerd config default | sudo tee /etc/containerd/config.toml

修改配置，启用 SystemdCgroup。这是 kubelet 和 containerd 协作关键项：

bash复制sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/g' /etc/containerd/config.toml

sudo systemctl restart containerd
sudo systemctl status containerd

注意，如果 containerd 的 cgroup 驱动与 kubelet 不一致，后面节点会一直处于 NotReady 状态。这一步不要跳过。

4.7 安装 kubeadm、kubelet、kubectl 1.29.14

先安装依赖工具：

bash复制sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gpg

添加 Kubernetes apt 源。1.29 版本的软件源路径如下：

bash复制curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.29/deb/Release.key | \
  sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.29/deb/ /' | \
  sudo tee /etc/apt/sources.list.d/kubernetes.list

然后安装版本固定的组件：

bash复制sudo apt-get update
apt-cache madison kubeadm
sudo apt-get install -y kubelet=1.29.14-00 kubeadm=1.29.14-00 kubectl=1.29.14-00

apt-cache madison 会列出仓库中实际的 1.29.14 对应版本号，以它为准。安装后用 apt-mark hold 锁定版本，防止系统更新时误升级：

bash复制sudo apt-mark hold kubelet kubeadm kubectl

检查版本：

bash复制kubeadm version
kubectl version --client
kubelet --version

三个客户端版本一致，才能避免后续初始化参数不匹配。

5. 控制平面初始化与节点加入

基础环境准备完后，先初始化 master 节点，再让 node1 和 node2 加入集群。

5.1 初始化 master 节点

在 master 节点执行 kubeadm init。这里以 Calico 网络插件为例，pod 网段使用 192.168.0.0/16：

bash复制sudo kubeadm init \
  --kubernetes-version v1.29.14 \
  --apiserver-advertise-address=192.168.x.10 \
  --pod-network-cidr=192.168.0.0/16 \
  --service-cidr=10.96.0.0/12

如果你的网络方案选择 Flannel，把 --pod-network-cidr 改成 10.244.0.0/16。初始化过程中 kubeadm 会拉取 pause、etcd、coredns 等镜像，耗时取决于网络环境。

如果这一步出现镜像拉取超时，可以先手动预拉取：

bash复制sudo kubeadm config images pull --kubernetes-version v1.29.14

初始化成功后，终端末尾会输出一段 kubeadm join 命令，务必保存下来。内容包括 token 和 --discovery-token-ca-cert-hash，稍后 node 节点加入要用。

5.2 配置 kubectl

master 节点上配置 kubeconfig，让当前用户可以直接使用 kubectl：

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

验证当前用户能访问集群：

bash复制kubectl get nodes

此时 master 节点状态会是 NotReady，因为网络插件还没安装，这是正常现象。

5.3 安装 CNI 网络插件

这里选择 Calico。安装方式：

bash复制kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/master/manifests/calico.yaml

如果使用 Flannel，执行：

bash复制kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

CNI 插件 Pod 需要等待镜像拉取和启动。观察状态：

bash复制kubectl get pods -n kube-system -o wide

等到 calico-node 或 kube-flannel-ds 都处于 Running 状态，master 节点的 NotReady 会变成 Ready。

5.4 worker 节点加入集群

在 node1 和 node2 上执行之前保存的 join 命令。如果没有保存，可以在 master 上重新生成：

bash复制kubeadm token create --print-join-command

然后在两个 worker 节点执行生成的完整命令：

bash复制sudo kubeadm join 192.168.x.10:6443 --token xxx \
  --discovery-token-ca-cert-hash sha256:xxx

分别在 node1、node2 上执行完后，回到 master 节点查看节点状态：

bash复制kubectl get nodes -o wide

最终应该看到三个节点全部 Ready，每个节点的角色列中，master 显示 control-plane，node1 和 node2 显示 <none>。

6. 功能测试与效果验证

集群跑通之后，接下来验证它是否真的可用。这里按「工作负载部署 -> 服务暴露 -> DNS 解析 -> 节点分布」四个维度测试。

6.1 部署并暴露 Nginx 服务

创建测试命名空间，避免和系统任务混在一起：

bash复制kubectl create namespace demo

在 demo 命名空间部署 Nginx：

bash复制kubectl -n demo create deployment nginx-demo --image=nginx:1.25
kubectl -n demo scale deployment nginx-demo --replicas=2

查看 Pod 调度分布：

bash复制kubectl -n demo get pods -o wide

如果镜像拉取慢，可以先在节点上手动执行 docker pull nginx:1.25 或 ctr images pull nginx:1.25 预热镜像。Pod 处于 Running 状态后，用 NodePort 暴露服务：

bash复制kubectl -n demo expose deployment nginx-demo --port=80 --target-port=80 --type=NodePort
kubectl -n demo get svc nginx-demo

输出结果里会出现一个 30000 到 32767 之间的 NodePort。然后打开浏览器，访问任意一个节点的 IP 加端口：

bash复制http://192.168.x.11:Port

如果页面出现 Nginx 欢迎页，说明容器网络、Pod 调度、Service 转发都正常。

6.2 验证集群 DNS

Pod 需要通过 DNS 访问集群内服务。在 demo 命名空间运行一个临时 Pod 测试：

bash复制kubectl -n demo run dns-test --image=busybox:1.36 --rm -it -- sh

进入容器后执行：

bash复制nslookup nginx-demo

正常情况下会解析出 ClusterIP。如果 nslookup 报错，大概率是 CoreDNS Pod 没有正常运行，回到第 5.3 节检查 kube-system 中的 coredns Pod 状态。

6.3 验证跨节点调度

继续观察 Pod 分布。看 demo 的 Pod 是否分布到不同节点：

bash复制kubectl -n demo get pods -o wide
kubectl top nodes

kubectl top nodes 需要部署 metrics-server，如果没有部署会报错。这里可以先看 Pod NODE 列，确认两个副本没有全部挤在一个节点上，说明调度器正常工作。

6.4 故障恢复测试

为了验证虚拟机快照的价值，可以手动停掉 node1 节点，观察集群反应：

bash复制# 在 VMware 中暂停或关闭 node1 虚拟机
kubectl get nodes

master 会标记 node1 为 NotReady，已调度到 node1 的 Pod 会处于 Terminating 状态，并在其他可用节点重新创建。重新启动 node1 虚拟机，几分钟后节点重新回到 Ready。

这一步测试不需要在正式环境频繁操作，但对理解 K8s 节点故障处理很有帮助。测试完成后关闭掉 node1，恢复快照即可。

7. 集群管理常用操作与接口说明

集群搭好之后，日常管理和 API 访问是重点。Kubernetes 的 API Server 默认监听 6443 端口，所有 kubectl 操作本质上都是通过 HTTPS 请求 API Server。这套环境的 API 能力完整可用，只要持有 kubeconfig 文件，外部机器也可以通过网络访问。

7.1 kubeconfig 分发到其他机器

在 master 节点上读取 /etc/kubernetes/admin.conf，内容格式如下：

yaml复制apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: xxx
    server: https://192.168.x.10:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
users:
- name: kubernetes-admin
  user:
    client-certificate-data: xxx
    client-key-data: xxx

把这部分内容复制到宿主机或其他机器的 ~/.kube/config，就可以通过 kubectl --kubeconfig 远程管理集群。注意，这个文件拥有管理员权限，不要泄露到公开仓库。

7.2 kubectl 常用操作

bash复制# 查看节点详情
kubectl get nodes -o wide

# 查看指定命名空间的 Pod
kubectl -n demo get pods -o wide

# 查看 Pod 事件
kubectl -n demo describe pod <pod-name>

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

# 查看全部资源类型
kubectl api-resources

# 查看集群事件
kubectl get events --sort-by='.lastTimestamp'

7.3 查看节点日志

节点级问题需要登录对应虚拟机查看 kubelet 日志：

bash复制journalctl -u kubelet -f

控制平面组件如果异常，先看 kube-system 中的 Pod 状态：

bash复制kubectl get pods -n kube-system -o wide
kubectl logs -n kube-system <pod-name>

7.4 使用浏览器访问 API Server

如果想把集群接口接到自己的工具或脚本里，不需要 kubectl 也可以。API Server 的地址是：

bash复制https://192.168.x.10:6443

使用 admin.conf 中的证书发起请求即可。举例，用 curl 查看集群版本：

bash复制curl --cacert ca.crt --cert client.crt --key client.key https://192.168.x.10:6443/version

实际开发中更推荐把 client-certificate-data 字段还原成 client.crt、client.key 文件，再做调用。

7.5 集群重置

如果集群配置乱了，最快的办法是恢复 VMware 快照。如果已经无法恢复快照，可以按顺序清理：

bash复制# 在需要重置的节点上执行
sudo kubeadm reset -f
sudo rm -rf /etc/cni/net.d
sudo rm -rf $HOME/.kube

然后重新从第 5.1 节开始初始化。注意重置只清理 K8s 相关数据和容器，不会影响系统本身。

8. 资源占用与性能观察

三节点集群在日常使用中的资源占用，是大多数人最关心的问题。这里给出一套观察方法，不写死具体数字，实际占用会随镜像缓存、Pod 数量变化。

8.1 观察宿主机与虚拟机资源

先看宿主机整体压力。Windows 用任务管理器，Linux 用 top、free -h。重点关注内存使用率，因为三台虚拟机各自占用独立内存配额。

然后在每台虚拟机内部执行：

bash复制free -h
top
df -h

free -h 看内存，注意 swap 已经关闭，内存用完会直接 OOM，所以要给每台虚拟机留出余量。df -h 看磁盘，重点看 / 根分区和 /var/lib/containerd 目录所在分区的剩余空间。

8.2 查看 K8s 集群内部资源请求

bash复制kubectl get nodes
kubectl describe node master-node | grep -A5 "Allocated resources"

这段输出会显示每个节点上 Pod 的 CPU、内存请求与节点总容量的比例。如果某个节点一直被调度大量 Pod，即使虚拟机本身内存充足，容器也会因资源请求约束而调度失败。

8.3 影响资源占用的关键因素

镜像拉取是磁盘增长的大头。nginx、busybox 这类镜像还好，如果测试中部署了 Kafka、Spark、Redis 等大数据组件，每个节点 /var/lib/containerd 很可能增长到 10GB 以上。这时建议：

• 不需要的 Deployment 和 Service 及时清理。
• 使用 kubectl delete namespace demo 清理命名空间及其资源。
• 避免一次创建太多副本，测试中 replicas=1 就够了。

快照文件也会持续增加。VMware 快照记录虚拟机磁盘变化，创建快照后继续写入的数据越多，快照文件越大。建议不要保留过多层级，一个干净初始快照加一个当前稳定快照就足够。

8.4 降低资源占用的方法

• 测试完中间件集群后，立刻删除对应命名空间。
• 把节点数从 3 降到 2 或 1 跑简单实验，需要多节点再恢复快照。
• 控制 Pod 的 limits，在 Deployment 中显式声明 CPU 和内存上限。
• 不要在一台虚拟机里同时跑多个重型服务，避免 OOM。

9. 常见问题与排查方法

下面列出这套 VMware 虚拟机三节点 K8s 集群搭建过程中最高频的问题。排查顺序一般是：先看虚拟机状态，再看节点状态，最后看 Pod 日志。

最典型的坑是 cgroup 驱动不一致。kubelet 默认使用 systemd cgroup 驱动，如果 containerd 配置里 SystemdCgroup 没有改成 true，节点会一直报 RuntimeReady 和 NetworkReady 不满足，Pod 无法创建。排查时优先看 containerd 配置。

另一个坑是 port 冲突。如果宿主机本身跑了 Docker Desktop 或云桌面软件，6443 端口、30000 段端口可能被占用。VMware 虚拟机通过 NAT 访问宿主机端口时，不会直接冲突，但 API Server 监听地址写错也会导致外部无法访问。确认集群内部通过 master 的 IP 能访问 6443 端口：

bash复制curl -k https://192.168.x.10:6443/healthz

10. 最佳实践与使用建议

到这步集群已经能正常使用，最后补充几条工程化建议，让这套环境更稳定、更好维护。

第一，三台虚拟机全部完成基础配置后，立即打一个「初始化前干净快照」。这个快照作为基准点，后面无论集群被折腾成什么样，都可以快速回滚到三台全新系统状态。创建快照前确认三台虚拟机处于关机或快照兼容状态，避免快照文件损坏。

第二，给每个节点固定静态 IP，并把 IP 和主机名的映射统一写到 /etc/hosts。不要依赖 DHCP 分配，否则节点重启后 IP 变化会导致 kubelet 无法连接 API Server，整个集群直接不可用。

第三，把 kubeadm join 命令、admin.conf、常用清单文件统一放到一个目录，例如 ~/k8s-env/。接新机器、新用户时直接分发，不需要重新从 master 节点复制。

第四，不要把测试集群当生产环境用。这套环境跑中间件、练习调度、验证配置文件都没问题，但不要在上面存重要数据，也不要随意对外暴露服务端口。kubeconfig 文件包含管理员权限，注意访问控制。

第五，涉及镜像和软件授权时要留意。Kubernetes 本身是开源项目，集群内跑的应用镜像、中间件软件需确认 license 是否允许在测试环境使用。涉及版权数据、个人敏感信息的内容不要在本地测试环境里存储和处理。

下一步可以继续扩展的方向：

• 部署 Ingress Controller，用域名访问集群服务。
• 部署 metrics-server，用 kubectl top 监控资源使用。
• 安装 Helm，用 Chart 快速部署中间件。
• 利用 DashBoard 可视化查看集群状态。
• 尝试把单 master 扩成 3 控制平面，模拟生产高可用架构。

这套 VMware 虚拟机三节点 Kubernetes 1.29.14 集群环境，最大的价值是提供了一条可反复试错的路径。第一次搭可能花一到两个小时，把整个流程走通后，后续恢复和扩展都很方便。建议收藏备用，也欢迎在评论区交流搭建过程中遇到的问题。