企业官网建设流程全解析

• 文档/教程

在 90DaysOfDevOps 的 Kubernetes 学习阶段，第 50 天首先回答一个最现实的问题：把 Kubernetes 集群跑在哪里？本文以 Day 50（西班牙语版 2022/es/Days/day50.md）为骨架，系统拆解裸金属（Bare-Metal）、虚拟化、本地桌面开发环境与云托管服务四大部署形态，并结合仓库中真实可用的 Vagrantfile 与 kubeadm 脚本，给出从"零成本学习环境"到"生产级架构"的完整选型思路与上手路径。读完后，你将能根据预算、运维能力与团队规模，独立判断该用 minikube、Kind、自建虚拟化集群还是 EKS/AKS/GKE，并知道如何在工作负载不变的前提下自由迁移。

选择平台的本质：消除 Kubernetes 的复杂度

Kubernetes 世界长期面临一个挑战——复杂度。一方面，"Kubernetes the hard way"式的手工搭建可以让你从零构建一个功能完整的集群，理解每一个底层细节，但这种方式极其极端，要求你亲手完成控制平面初始化、证书签发、网络插件安装等全部环节。

另一方面，越来越多的人希望去掉这种复杂度，直接运行一个托管式（managed）Kubernetes 集群。托管的代价是金钱，但收益同样明确：当使用托管服务时，你通常不需要操心底层节点架构，也无需了解控制平面（Control Plane）节点的内部运作——因为正常情况下你根本访问不到它们。

在这两极之间，还有本地开发发行版（local development distributions）：利用我们手头的笔记本或台式机，运行一个本地版 Kubernetes，让开发人员在真正目标平台上拥有完整的工作环境来运行他们的应用。

无论选择哪种形态，其共同基础是：它们都是 Kubernetes 的"一种口味"（a flavour of Kubernetes）。这意味着我们应该能够自由地把工作负载迁移到任何需要的地方，去适配自己的需求。因此，平台选择很大程度取决于已经做出的投资，也取决于对开发者体验的重视程度——那些跑在笔记本电脑上的本地 Kubernetes 环境，是零成本上手这项技术的绝佳途径。

四大部署形态逐一拆解

1. 裸金属集群（Bare-Metal Clusters）：从物理服务器起步

裸金属方案是指把 Linux 操作系统直接安装到若干台物理服务器上，由这些服务器组成集群（理论上也可以是 Windows，但在 Windows 环境下的容器与 Kubernetes 采用率并不高，更多是零星个例）。

如果你的企业已经做出CAPEX 决策（资本性支出）采购了物理服务器，那么裸金属可能正是你构建集群的方式。需要清醒认识的是：在管理与运维层面，这意味着你必须从零开始自己构建、自己管理一切——操作系统、容器运行时、kubeadm、网络插件、存储、监控、升级，全部亲力亲为。它把最多的控制权留给你，同时也把最多的责任留给你。

2. 虚拟化（Virtualisation）：测试、学习与企业级的平衡点

无论目标是测试学习环境，还是企业就绪（enterprise-ready）的 Kubernetes 集群，虚拟化都是绝佳路线。它的典型做法是：快速创建若干虚拟机（VM）作为集群节点，再把它们组合成集群。你同时获得虚拟化的底层架构、效率与速度，还能充分利用企业已有的虚拟化投入。

以 VMware 为例，它同时为虚拟机和多种形态的 Kubernetes 提供了成熟解决方案。仓库中 90DaysOfDevOps 的实际实践也印证了这条路线：作者自己搭建的第一个 Kubernetes 集群，就是基于Microsoft Hyper-V在一台旧服务器上运行的几台 VM 组成的。而仓库的 Kubernetes 目录 更给出了一个完整的虚拟化落地样本（详见下文第三节）。

3. 本地桌面选项（Local Desktop Options）：开发者的零成本环境

在桌面或笔记本上运行本地 Kubernetes 集群，是当下最流行的开发方式之一。正如前文所说，它让开发者无需维护多个昂贵或复杂的集群，就能直观看到自己的应用在 Kubernetes 上"长什么样"。

在众多本地工具中，作者个人使用最多的是minikube。它拥有出色的功能与插件（add-ons）体系，能彻底改变你"把东西跑起来"的方式。这也是作者目前最推荐的入门选择。

4. 托管 Kubernetes 服务（Managed Services）：把控制平面交出去

虚拟化既可以通过本地 Hypervisor 实现，也可以借助公有云上的 VM 充当节点。而这里讨论的托管 Kubernetes 服务，指的是来自大型云厂商（hyperscalers）以及 MSP（托管服务提供商）的现成产品——它们把一层层的管理与控制从终端用户手中抽离，最典型的就是移除控制平面的管理负担，这正是Amazon EKS、Microsoft AKS 与 Google Kubernetes Engine（GKE）在做的事。

选择托管服务意味着：你不用再关心控制平面的高可用、etcd 备份、apiserver 升级等底层运维，代价是费用更高，且对底层节点的可观测性受限。

仓库实战佐证：虚拟化路线的完整落地样本

仓库 2022/Days/Kubernetes 目录为"虚拟化 + kubeadm"路线提供了可直接复用的完整工程，与 Day 50 论述的虚拟化形态一一对应。

Vagrantfile：一主两从的虚拟机编排

Vagrantfile 定义了基于 VirtualBox 的一主（master）两从（worker）集群拓扑：

NUM_WORKER_NODES=2 IP_NW="10.0.0." IP_START=10 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_START+1)) worker-node01" >> /etc/hosts echo "$IP_NW$((IP_START+2)) worker-node02" >> /etc/hosts SHELL config.vm.box = "bento/ubuntu-21.10" ...

关键参数一览：

这个 Vagrantfile 正体现了 Day 50 所说的"把虚拟机作为节点、再把它们聚合成集群"——虚拟机（VM）即节点（Node）。

master.sh / node.sh：控制平面与工作节点的分工

scripts/master.sh 展示了控制平面初始化的核心调用链：

MASTER_IP="10.0.0.10" NODENAME=$(hostname -s) POD_CIDR="192.168.0.0/16" sudo 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

随后脚本把admin.conf复制为本地kubeconfig、生成工作节点的kubeadm join命令（kubeadm token create --print-join-command），并安装Calico 网络插件（kubectl apply -f calico.yaml）、Metrics Server 与 Kubernetes Dashboard。工作节点侧 scripts/node.sh 则执行/bin/bash /vagrant/configs/join.sh -v加入集群，并通过kubectl label node ... node-role.kubernetes.io/worker=worker-new标记角色。

而 scripts/common.sh 负责所有节点的共性准备：禁用 swap、加载br_netfilter与overlay内核模块、配置 sysctl（net.bridge.bridge-nf-call-iptables = 1等）、安装 containerd 与 Docker Engine，并以apt-mark hold kubelet kubeadm kubectl锁定 Kubernetes 1.23.3 版本。

这正是"Kubernetes the hard way"之外的另一种自建路径：用 kubeadm 把复杂度控制在可管理范围，同时保留对控制平面的完全可见性——这是托管服务无法提供的能力，也正是 Day 50 讨论"裸金属/虚拟化 vs 托管"时的关键权衡点。

本地开发首选：minikube 与 Kind

对于学习视角，作者的建议非常明确：首选 minikube，其次 Kind（Kubernetes in Docker）。为什么 minikube 更受青睐？因为它几乎把复杂度抽象掉了：

• 只需使用add-ons 插件就能快速搭建所需环境，用完即可"吹掉"（blow it away）；
• 支持运行多个集群；
• 几乎可以在任何地方运行，跨平台、与硬件无关（hardware agnostic）。

紧随其后的第 51 天（2022/Days/day51.md）正是这一建议的直接实践：通过minikube start一键在本机拉起首个集群。其默认 Docker Driver 会在本机运行一个"嵌套虚拟化"的单节点容器——控制平面节点与工作节点合二为一，与生产环境"控制平面与工作节点分离"的架构形成对照。minikube 还支持用--apiserver-port=6433固定 API 端口、--container-runtime=containerd（Docker 为默认、CRI-O 亦可用）以及--kubernetes-version指定版本等配置项，且可用minikube addons enable一键启用 CSI 主机路径驱动、卷快照等插件，替代繁琐的 Helm 部署流程。

对于仍想保留一点"自建感"、又不想管理虚拟机的开发者，Kind 则把每个节点建模为 Docker 容器，同样适合 CI 与本地多节点拓扑测试。

不容忽视的选项：OpenShift 与云平台

在以上所有类别之上，还有一个重要选项：Red Hat 的 OpenShift。它的特点是可以在上述所有主要云提供商上运行，无论集群部署在哪里，如今大概都能为管理员提供最好的整体易用性。

同样值得跟踪的云平台实践还包括：Amazon EKS、Microsoft AKS（含 Azure PowerShell 版）、Google GKE、AWS Bottlerocket + EKS 组合，以及 Civo Cloud 等新兴服务。这些选项共同构成了"托管服务"光谱——按需选择控制平面抽象程度与厂商绑定程度，核心工作负载（Deployment、Service、Ingress、StatefulSet 等 Kubernetes 原生资源）理论上均可跨平台迁移。

从学习到生产：你的第一台集群该怎么选

作者回顾自身学习旅程后给出的结论是：不必一开始就追求生产级架构，先低成本地把技术跑通。完整的选择逻辑可以概括为：

1. 零成本起步：用 minikube（首选）或 Kind，在本机迅速搭建、练习、销毁，熟悉 kubectl 与 Kubernetes 原生资源；
2. 接近生产的学习：用仓库的 Vagrantfile + kubeadm 在 VirtualBox 中搭建多节点集群，理解控制平面与工作节点分工、网络插件、Dashboard 等生产要素；
3. 企业生产：依据 CAPEX/OPEX 决策选择裸金属、虚拟化或 EKS/AKS/GKE 托管服务，并评估 OpenShift 作为统一管理面的可能性。

无论最终落在哪一层，都可以在这套选择之上继续 90DaysOfDevOps 的 Kubernetes 主题学习：架构（Architecture）、kubectl 命令、Kubernetes YAML、Ingress、Services、Helm 包管理器、持久化存储（Persistent Storage）与有状态应用（Stateful Apps）。仓库中 nginx-stateless-demo.yaml（Namespace + Deployment + Service 的无状态示例）与 statefulset.yaml（含 PVC 挂载、Secret 注入、readinessProbe 的 MongoDB 有状态示例）恰好为后续章节提供了可运行的实战素材。

平台选择只是起点，关键在于理解：所有这些都是 Kubernetes 的变体，工作负载的可移植性才是最终目标——选择一种形态把它跑起来，然后继续前进。

资源

• Kubernetes 官方文档（入门与概念权威来源）
• 90DaysOfDevOps 系列第 49 天《The Big Picture: Kubernetes》（2022/Days/day49.md）：容器编排与 Kubernetes 定位的全局视图
• 第 51 天《Deploying your first Kubernetes Cluster》（2022/Days/day51.md）：minikube 实战上手
• 仓库 2022/Days/Kubernetes 目录：Vagrantfile、kubeadm 脚本与全套示例 YAML

下一站见：第 51 天——用 minikube 部署你的第一个 Kubernetes 集群。

• 文档/教程