资讯动态

90DaysOfDevOps 第 52 天实战:用 Vagrant 在 VirtualBox 上搭建三节点 Kubernetes 集群

发布时间:2026/10/8 6:49:10 来源:尧图企业网站定制
文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载本篇文章来自 90DaysOfDevOps 学习路线图 2022 年系列的 第 52 天课程笔记主题是用 Vagrant VirtualBox 以基础设施即代码的方式一键搭建一个包含 1 个控制平面节点control plane与 2 个工作节点worker node的多节点 Kubernetes 集群。读完本文你将掌握 Vagrantfile 的完整写法、集群初始化与节点加入的脚本逻辑kubeadm init / kubeadm join以及如何把 kubeconfig 配置到本地工作台用 kubectl 从自己的电脑远程管理整个集群。为什么从 minikube 升级到多节点集群在 90DaysOfDevOps 前一天的课程中我们使用一个有趣的项目部署了第一个 Kubernetes 集群并用 kubectl 这个使用 Kubernetes 时最重要的 CLI 工具完成了实践。minikube 适合在单机上体验 Kubernetes但生产环境的真实形态是多个节点协同工作控制平面负责集群大脑API、调度、控制器、etcd工作节点负责真正运行容器负载。今天的实验以 VirtualBox 为虚拟化底座。正如在 Linux 章节介绍 Vagrant 时提到的Vagrant 支持任何受支持的虚拟化工具这里我们选择 VirtualBox并使用仓库中 2022/Days/Kubernetes 目录下准备好的 Vagrantfile 与脚本。Vagrant 快速回顾管理虚拟机生命周期的 CLI 工具Vagrant 是一个命令行工具用于管理虚拟机VM的完整生命周期。我们可以用vagrant在多平台上创建、删除虚拟机包括 vSphere、VirtualBox甚至 Docker。它还有其他 Provider但本文选择 VirtualBox。Vagrant 的核心价值在于可重复的环境定义虚拟机的镜像box、网络、CPU/内存资源、初始化脚本全部写在一个Vagrantfile中任何人拿到它都能构建出一模一样的实验环境。这是后续自动化构建各类实验环境lab的基础。如果你从未部署过 Kubernetes 集群作者也建议先手动部署一次至少了解整个过程长什么样。值得一提的是随着每个 Kubernetes 版本的发布集群初始化流程越来越精简高效——从 VMware/ESX 时代手动部署 3 台 ESX 服务器需要一整天到现在同样的工作量可以在一小时内完成。准备 Kubernetes 实验环境获取仓库中的 Vagrantfile仓库 2022/Days/Kubernetes 目录下提供了本次实验所需的 Vagrantfile 和配套 shell 脚本。把该目录内容复制到本地某个工作目录然后在终端中进入该目录。安装 Vagrant本文作者使用 Windows PowerShell 在本地执行 Vagrant 命令。如果你尚未安装 Vagrant可以使用 arkade昨天安装 minikube 等工具时介绍过来安装arkade get vagrant该命令会下载并安装最新版本的 Vagrant。启动集群在包含 Vagrantfile 的目录中执行vagrant up如果一切配置正确终端中会出现类似本文开头第一张图的启动过程Vagrant 依次创建master、node01、node02三台虚拟机导入bento/ubuntu-21.10box并通过 VirtualBox provider 启动它们。整个实验的耗时通常为 530 分钟取决于你的机器配置。三节点集群拓扑1 个控制平面 2 个 Worker从上文第二张架构图可以看到本次实验的最终目标控制平面Control Plane包含 kube-apiserver、etcd、Controller Manager、Scheduler 等核心组件由 kubectl 管控两个工作节点Node每个节点上运行 kubelet、容器运行时container runtime和 kube-proxy。在规划中访问集群的 kubectl 通常从集群外部连接到 kube-apiserver而在本次 Vagrant 部署方案里我们还会在每个节点上都安装 kubectl因此可以从任意节点内部访问集群。这套架构与之前 第 49 天课程 讲解的 Kubernetes 组件章节可以相互印证。部署完成后的节点访问部署完成后可以从宿主机 SSH 进入任意节点vagrant ssh master默认用户名和密码为vagrant / vagrant。同样地也可以用vagrant ssh node01和vagrant ssh node02进入两个工作节点。进入节点后运行kubectl get nodes可以看到 3 个节点的集群及其状态master-node控制平面、worker-node01、worker-node02状态均为Ready。至此一个 3 节点集群1 个控制平面 2 个工作节点已经运行起来。深入 Vagrantfile网络、节点定义与资源分配仓库中的 Vagrantfile 完整内容如下NUM_WORKER_NODES2 IP_NW10.0.0. IP_START10 Vagrant.configure(2) do |config| config.vm.provision shell, inline: -SHELL apt-get update -y echo $IP_NW$((IP_START)) master-node /etc/hosts echo $IP_NW$((IP_START1)) worker-node01 /etc/hosts echo $IP_NW$((IP_START2)) worker-node02 /etc/hosts SHELL config.vm.box bento/ubuntu-21.10 config.vm.box_check_update true config.vm.define master do |master| master.vm.hostname master-node master.vm.network private_network, ip: IP_NW #{IP_START} master.vm.provider virtualbox do |vb| vb.memory 4048 vb.cpus 2 vb.customize [modifyvm, :id, --natdnshostresolver1, on] end master.vm.provision shell, path: scripts/common.sh master.vm.provision shell, path: scripts/master.sh end (1..NUM_WORKER_NODES).each do |i| config.vm.define node0#{i} do |node| node.vm.hostname worker-node0#{i} node.vm.network private_network, ip: IP_NW #{IP_START i} node.vm.provider virtualbox do |vb| vb.memory 2048 vb.cpus 1 vb.customize [modifyvm, :id, --natdnshostresolver1, on] end node.vm.provision shell, path: scripts/common.sh node.vm.provision shell, path: scripts/node.sh end end end逐段解读顶层变量NUM_WORKER_NODES2定义工作节点数量IP_NW10.0.0.与IP_START10定义内网网段与起始 IP三个节点将依次获得10.0.0.10master、10.0.0.11node01、10.0.0.12node02inline provisionVagrant 会在所有机器启动后先执行一段内联 shell更新 apt 索引并把三台主机的 IP/主机名映射写入/etc/hosts保证节点间能通过主机名互相解析box 定义config.vm.box bento/ubuntu-21.10指定基础镜像box_check_update true表示启动时检查 box 是否有新版本master 节点主机名master-node使用 VirtualBox 私有网络静态 IP10.0.0.10分配 4048 MB 内存、2 核 CPU并开启 NAT 模式下的 DNS host resolver解决虚拟机内 DNS 解析问题worker 节点通过(1..NUM_WORKER_NODES).each循环生成node01、node02两个节点定义主机名分别为worker-node01、worker-node02IP 依次递增每个节点分配 2048 MB 内存、1 核 CPUprovision 脚本分发所有 3 个节点都运行scripts/common.sh基础环境准备master 额外运行scripts/master.sh初始化集群两个 worker 额外运行scripts/node.sh加入集群。三个 Provision 脚本集群是如何长出来的Vagrantfile 中引用了三个 shell 脚本它们按职责分工完成从裸系统到可用集群的整个装配过程。common.sh为所有节点准备运行时与 kubeadm 工具链scripts/common.sh 会在全部 3 个节点上执行主要完成以下工作关闭 swap执行swapoff -a并注释/etc/fstab中的 swap 行确保重启后 swap 仍保持关闭kubelet 对 swap 敏感配置内核模块与 sysctl加载br_netfilter、overlay模块并写入net.bridge.bridge-nf-call-iptables、net.ipv4.ip_forward等参数使 iptables 能看到桥接流量这是容器网络正常工作的前提干净安装 Docker Engine 与 containerd先移除可能残留的旧组件docker、docker-engine、docker.io、containerd、runc添加 Docker 官方 GPG key 与 apt 源再安装docker-ce、docker-ce-cli、containerd.io随后用containerd config default生成默认配置并重启 containerd安装 kubeadm、kubelet、kubectl添加 Google Cloud 的 Kubernetes 签名 key 与 apt 仓库安装三件套后用apt-mark hold锁定版本防止意外升级破坏集群一致性。脚本第 4 行声明了KUBERNETES_VERSION1.23.3-00变量实际安装命令则直接安装仓库中的对应版本。从脚本结构看这套关闭 swap → 内核网络参数 → 运行时 → kubeadm 工具链的顺序正是 kubeadm 官方推荐的节点预检流程。master.shkubeadm init 初始化控制平面scripts/master.sh 只在控制平面节点master上运行核心动作预拉取镜像kubeadm config images pull提前下载初始化所需的容器镜像初始化集群sudo kubeadm init \ --apiserver-advertise-address$MASTER_IP \ --apiserver-cert-extra-sans$MASTER_IP \ --pod-network-cidr$POD_CIDR \ --node-name $NODENAME \ --ignore-preflight-errors Swap其中MASTER_IP10.0.0.10、POD_CIDR192.168.0.0/16与后面安装的 Calico 网络插件默认网段一致、NODENAME取主机短名master-node。--ignore-preflight-errors Swap用于跳过 swap 预检告警虽然 common.sh 已关闭 swap仍保留此参数以防万一。配置 kubectl 上下文将kubeadm init生成的/etc/kubernetes/admin.conf复制为$HOME/.kube/config并赋予当前用户读写权限使 master 上的 vagrant 用户可以直接使用 kubectl产出共享配置把admin.conf复制到/vagrant/configs/configVagrant 的共享目录所有节点可见并用kubeadm token create --print-join-command生成工作节点加入集群的命令写入/vagrant/configs/join.sh。仓库中生成的示例 configs/join.sh 形如kubeadm join 10.0.0.10:6443 --token token --discovery-token-ca-cert-hash sha256:hashtoken 与 CA 哈希为集群初始化时动态生成每次部署都会不同。装配集群插件安装Calico 网络插件kubectl apply -f calico.yaml为 Pod 提供跨节点网络安装Metrics Server并 patch 添加--kubelet-insecure-tls参数以适应本环境安装Kubernetes Dashboardv2.4.0并创建admin-userServiceAccount 与cluster-admin角色的 ClusterRoleBinding将 Dashboard 的访问 token 以 base64 解码后写入/vagrant/configs/token方便后续登录 Dashboard。node.shkubeadm join 加入工作节点scripts/node.sh 在两个工作节点上运行逻辑非常简单/bin/bash /vagrant/configs/join.sh -v它直接执行 master 生成的 join 脚本-v输出详细日志即通过kubeadm join 10.0.0.10:6443将节点注册进集群。随后脚本把共享的 kubeconfig 复制到vagrant用户目录用kubectl label node给节点打上node-role.kubernetes.io/workerworker-new标签最后重启 systemd-resolved 与 kubelet 使网络与节点状态生效。这样一个master 生成令牌与 CA 哈希 → worker 消费共享文件完成加入的设计正是多节点集群自动化装配的常见套路共享目录/vagrant充当了节点间的配置交换通道。仓库中的另一种变体Rancher 桥接网络仓库 Rancher 目录 下还提供了一份使用public_network桥接模式指定物理网卡替代private_network的 Vagrantfile 变体网段改为192.168.169.130起。如果你的实验需要让集群节点直接暴露在局域网、或需要跑 Rancher 类管理平台可以对比参考这份配置理解私有网络与桥接网络两种拓扑的差异。从本地工作台访问集群kubeconfig 与 Context到这一步我们已经在同一台机器上同时拥有了两个集群之前部署的 minikube 集群以及今天刚在 VirtualBox 上部署的三节点集群。Kubernetes 集群的访问配置endpoint、证书、context都保存在 kubeconfig 文件中理解它就能在多个集群之间自由切换。理解 kubeconfig 与 ContextContext上下文至关重要——从你的台式机或笔记本远程访问 Kubernetes 集群是日常必会的技能。默认情况下kubectl 使用~/.kube/configWindows 上为C:\Users\用户名\.kube\config保存集群的关键信息包括clusters集群列表及其 API server 地址与 CA 证书users客户端证书/私钥等身份信息contexts将某个集群 某个用户 某个命名空间组合成命名的上下文current-context当前生效的上下文。仓库中部署产出的示例 configs/config 就是一个标准 kubeconfigserver: https://10.0.0.10:6443context 名为kubernetes-adminkubernetes。平时操作多个集群本质就是切换current-context。获取并安装 kubeconfig 到本机有两种方式把集群的 kubeconfig 拿到本地从集群节点取回用scp从 master 节点下载/vagrant/configs/config或/etc/kubernetes/admin.conf直接打开一个到节点的 console 会话把文件内容复制到本地。无论哪种方式最终都是把这份配置复制到本机的$HOME/.kube/configWindows 为C:\Users\用户名\.kube\config覆盖或合并现有配置。如果你之前在节点内部通过 SSH 使用 kubectl现在就能从自己的工作站直接连接集群了。从工作台验证访问配置就位后在本地终端运行kubectl cluster-info kubectl get nodes第一条命令返回控制平面Control Plane与 CoreDNS 的访问地址第二条命令返回 3 个 Ready 状态的节点——正如本文开头第三张图展示的从 Windows 工作台得到的输出。这不仅打通了远程连接与控制还让我们能够在本地使用kubectl port-forward等方式做端口转发把集群内的某些服务暴露到 Windows 本地访问。对于需要在一台工作站上管理多个集群的场景核心思路就是维护好多个 context 并在~/.kube/config中灵活切换这也是 90DaysOfDevOps 作者在后续多集群实践如 EKS、AKS、GKE、Civo 等不同平台的集群部署系列中反复使用的技巧。本系列 Kubernetes 主题路线图至此Kubernetes 章节已经覆盖了单机minikube与多节点Vagrant kubeadm两种集群的搭建。后续课程将沿着这条路线继续深入Kubernetes 架构Architecturekubectl 常用命令Kubernetes YAML 编写Kubernetes IngressKubernetes ServicesHelm 包管理器持久化存储Persistent Storage有状态应用Stateful Apps小结本篇文章完整走通了 90DaysOfDevOps 第 52 天的核心实验用 Vagrantfile 一键拉起 3 台 Ubuntu 虚拟机通过 common.sh运行时与 kubeadm 工具链、master.shkubeadm init Calico Dashboard和 node.shkubeadm join自动装配出一个可用的三节点集群最后把 kubeconfig 拿到本地工作台用kubectl cluster-info与kubectl get nodes验证远程访问。整套流程体现了环境即代码的实践价值同一个仓库任何人都能复现同样的集群环境为后续深入 Kubernetes 架构、网络、存储与 Helm 等主题打下了可操作的实验基础。如需继续深入可参考 Kubernetes 官方文档以及社区中面向初学者的 Kubernetes 入门视频教程等公开资料下一步请继续 第 53 天课程。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps 实战基于 Vagrant VirtualBox 搭建三节点 Kubernetes 集群Day 5290DaysOfDevOps 实战基于 Vagrant VirtualBox 搭建三节点 Kubernetes 集群Day 52 本文对应 90Day文档/教程90DaysOfDevOps 实战使用 Vagrant VirtualBox 搭建多节点 Kubernetes 集群Day 5290DaysOfDevOps 实战使用 Vagrant VirtualBox 搭建多节点 Kubernetes 集群Day 52 本文是 90Days文档/教程Sequelize 贡献者完全指南从开发环境搭建、多数据库测试到 Pull Request 提交流程Sequelize 贡献者完全指南从开发环境搭建、多数据库测试到 Pull Request 提交流程 Sequelize 是一款支持 PostgreSQL、M文档/教程创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑