家庭实验室最适合使用哪种 Kubernetes 发行版？

家庭实验室最佳的 Kubernetes 发行版是 K3s 或 MicroK8s。

3节点家庭实验室的Kubernetes发行版对比

为我们的家庭实验室选择最佳的 Kubernetes 方案

我正在比较自托管的Kubernetes变体，这些变体适用于基于Ubuntu的homelab，包含3个节点（每个节点16GB RAM，4个核心），重点在于安装和维护的简便性，以及对持久卷和LoadBalancers的支持。

场景： 我们有一个包含三个Ubuntu节点（每个节点16GB RAM，4个CPU核心）的homelab。高可用性（HA）和ARM支持不是优先事项。我们想要一个易于安装、维护成本低的Kubernetes集群（单节点或3节点），并支持**持久卷（PV）和LoadBalancer（LB）**服务（这样需要存储或外部IP的云原生应用可以顺利运行）。我们将专注于没有HA或ARM CPU兼容性要求的3节点集群选项。

kubernetes homelab

下面我们将比较流行的轻量级 [Kubernetes(https://www.glukhov.org/zh-cn/post/2024/10/kubernetes-cheatsheet/ “最常用和有用的k8s命令列表和描述 - k8s速查表”) 发行版 – K3s, MicroK8s, Minikube, 和 kubeadm（原生Kubernetes） – 并分析它们在关键标准上的表现（功能、安装/维护、PV/LB支持、资源需求、集群设置和工具）。我们还将根据homelab场景给出一些选择建议。

K3s（Rancher的轻量级Kubernetes）

主要功能： K3s 是一个CNCF认证的Kubernetes发行版，设计用于最小资源使用（它可以运行在低至512 MB RAM的设备上）。它将整个Kubernetes控制平面打包成一个单一的二进制文件和进程，使用轻量级组件（例如，默认使用SQLite数据存储而不是etcd，使用flannel进行网络）。它包括一些合理的默认设置，如内置的入口控制器（Traefik）和简单的服务负载均衡器。K3s去除了遗留/alpha功能以减少臃肿。

安装与维护的简便性： 非常简单 – 我们可以通过一个单行脚本（curl ... | sh）或通过K3sup等工具安装它。服务器默认组件开箱即用。添加节点非常简单（使用服务器提供的令牌运行K3s代理）。升级很容易（替换二进制文件或使用安装脚本安装新版本）。不需要单独设置etcd（除非选择多主HA设置）。K3s设计为安装后需要极少的调整，这使其在物联网和homelab中很受欢迎。
持久卷支持： 内置。 默认情况下，K3s附带Rancher的local-path StorageClass，它为每个PVC在主机文件系统上动态分配PV。这意味着任何PVC都会自动在节点上创建一个hostPath卷以满足需求。这是一个单节点存储解决方案（每个卷在一个节点的磁盘上），但对有状态应用开箱即用。对于更高级的存储，可以添加像Rancher的Longhorn（分布式块存储）这样的组件，K3s支持这些组件，但对于homelab，默认的local-path提供者通常就足够了。
LoadBalancer支持： 内置。 K3s包含一个名为ServiceLB（以前称为“Klipper LB”）的轻量级控制器，允许类型为LoadBalancer的服务在主机上获得IP/端口，而无需任何外部云提供商。当我们创建一个LoadBalancer服务时，K3s会在每个节点上部署一个名为svc-...的小型LB Pod的DaemonSet，它们使用主机端口将流量转发到服务。本质上，K3s重用节点的IP（内部或外部）作为LB IP，并使用LB Pod中的iptables路由将流量发送到服务的ClusterIP。这无需任何配置 – 服务不会保持“pending”状态（与裸金属上的原生K8s不同）。权衡是LB的外部IP将是我们的节点之一的IP（或所有节点），我们必须确保端口是空闲的。对于大多数homelab用途（在HTTP/HTTPS端口上暴露几个服务），这完全没问题。如果需要，我们可以禁用内置的LB并手动安装MetalLB，但大多数用户坚持使用方便的默认设置。
资源需求： 非常低。K3s甚至可以在低端硬件上运行。官方要求服务器节点至少512 MB RAM和几百MB磁盘空间。实际上，小型集群可能只需几百MB内存用于控制平面。其二进制文件小于100 MB。CPU开销很小（K3s在空闲时使用的CPU略高于MicroK8s，但差距不大）。我们的节点（每个16 GB）远超过运行K3s所需的资源。
单节点与多节点： 适用于两者。K3s可以运行单节点（所有控制平面和工作负载在一个机器上）或多节点。对于3节点设置，我们可能运行1个服务器（主节点）和2个代理，甚至可以将所有3个节点作为HA使用（由于HA不是目标，这里不需要）。使用令牌加入代理节点非常简单。K3s的默认SQLite数据存储适用于单服务器；对于多服务器HA，我们将切换到嵌入式etcd（K3s可以在启动多个服务器节点时自动完成此操作）。
CLI与UI工具： 我们与K3s的交互方式与任何Kubernetes相同 – 通过kubectl。K3s包含自己的kubectl构建（我们可以运行k3s kubectl ...或通过指向K3s的kubeconfig使用标准的kubectl）。除了安装命令外，没有特殊的K3s特定CLI – 它有意保持极简。没有内置的Web UI（上游Dashboard默认未安装）。然而，我们可以像任何标准集群一样手动部署Kubernetes Dashboard或其他工具。如果需要完整的UI，可以安装Rancher（由同一家公司开发的GUI管理工具），但Rancher本身不属于K3s。本质上，K3s提供核心k8s API，我们根据需要添加额外功能（如入口、存储等 – 其中一些如前所述已打包）。

MicroK8s（Canonical的低运维Kubernetes）

主要功能： MicroK8s 是Canonical的轻量级Kubernetes发行版，以snap包形式提供。它通过单个命令安装一个完全符合规范的Kubernetes集群（上游二进制文件），设计用于单机或小型集群的易用性（“低运维”）。它强调“开箱即用”的方法 – 我们可以启用一些可选功能，只需简单命令即可。MicroK8s默认采用原生Kubernetes体验（所有标准API），但为常见需求提供了便捷的附加功能。它支持单节点和多节点部署（我们可以通过“加入”节点形成集群），甚至有HA模式用于控制平面（使用Dqlite – 一种分布式SQLite – 当我们有3个主节点时）。

安装与维护的简便性： 同样非常容易 – 只需在Ubuntu机器上运行snap install microk8s --classic即可设置一个Kubernetes节点。它是一个包含所有组件的单一包。MicroK8s通过Ubuntu的snap系统维护，这意味着更新是原子的并且可以自动进行（我们可以跟踪Kubernetes版本的通道）。这种自动更新能力在这些选项中是独特的 – 我们可以选择通过snap刷新获取安全补丁和小升级。通过microk8s命令管理MicroK8s，它有子命令用于启用/禁用功能。总体而言，它非常低摩擦：无需管理容器或虚拟机（在主机上原生运行），也无需配置外部etcd（使用内部数据存储）。维护主要是需要时更新snap并使用microk8s.status进行监控。
持久卷支持： 通过附加功能可用。 默认情况下，MicroK8s不会自动分配PV，直到我们启用**“hostpath-storage”附加功能。启用此功能（通过microk8s enable hostpath-storage）会创建一个默认的StorageClass，从主机上的一个目录分配卷。这本质上是一个动态的hostPath提供者，概念上与K3s的local-path类似。一旦启用，任何PVC都会绑定到MicroK8s节点上的hostpath PV。（在多节点MicroK8s集群中，hostpath PV将位于一个节点上 – 适合测试或homelab使用，但不是分布式存储）。MicroK8s还提供Mayastor**和其他存储附加功能，如果我们想要跨节点的更高级存储，但为了简单起见，hostpath存储工作良好。注意： 附加功能默认未启用（以保持精简），因此我们需要启用它以使PVC正常工作。Canonical指出这不适合生产HA使用（因为它不是复制的），但对于homelab来说是完美的。
LoadBalancer支持： 通过附加功能可用。 MicroK8s不捆绑默认的负载均衡器，但它提供MetalLB作为简单的附加功能。运行microk8s enable metallb:<start-IP>-<end-IP>会以Layer 2模式部署MetalLB，并让我们指定一个IP池用于LoadBalancer服务。一旦启用，任何类型为LoadBalancer的服务将自动从该范围获得一个IP（并MicroK8s将通过LAN上的ARP广播它）。这在裸金属上提供了类似云的体验。（如果我们不启用MetalLB，LoadBalancer服务将保持pending状态，因为MicroK8s本身不实现一个 – 与上游Kubernetes一样。）在homelab中，MetalLB非常简单，让我们可以访问本地网络上的服务。我们需要在网络中选择一个空闲的子网或IP范围。MicroK8s的启用命令使设置变得轻松，但它仍然是一个单独的步骤。（与K3s开箱即用的LB不同，但有使用节点IP/端口的限制。）许多MicroK8s用户在初始设置中简单启用MetalLB以获得功能性的LB。
资源需求： MicroK8s相当轻量，尽管略高于K3s。它原生运行所有核心服务（API服务器、控制器、调度器、kubelet、etcd或Dqlite）。空闲时的使用通常为控制平面约500–600 MB RAM，具体取决于启用的附加功能。Canonical指出基线内存约为540 MB。空闲时CPU使用率低，我们的16 GB节点有大量余量。磁盘空间需求小（snap约200 MB加上etcd数据）。总的来说，MicroK8s可以在中等硬件上运行（甚至提供给树莓派使用），在我们的场景中，这些机器轻松容纳它。如果启用了多个附加功能（仪表板、监控等），资源使用将相应增加。
单节点与多节点： MicroK8s适用于两者。我们可以用它来创建单节点集群（例如，在开发机器或一个服务器上），或通过“加入”节点创建多节点集群。MicroK8s文档提供了一个添加节点的命令（我们从第一个节点获取加入令牌并在其他节点上使用它）。在没有HA的多节点设置中，一个节点将是主控制平面。在3个节点中，我们还可以启用ha-cluster模式（通过在3个节点上运行Dqlite使控制平面HA），但在我们的情况下不需要HA。无论是单节点还是三节点，体验都是相同的Kubernetes API。多节点MicroK8s比K3s的方法稍新，但现在非常稳定。如果我们要一个由几个Ubuntu盒子运行k8s的“微型云”，并且希望以最小的努力实现，MicroK8s是一个不错的选择。
CLI与UI工具： MicroK8s附带了**microk8s命令行工具，非常方便。例如，microk8s enable <addon>可以切换各种服务（DNS、入口、存储、metallb、仪表板等），microk8s status可以显示正在运行的内容。它还包含嵌入式的kubectl：我们可以使用microk8s kubectl ...（或设置别名），它与集群通信 – 这很好，因为我们不需要配置kubeconfig。对于UI，MicroK8s提供Kubernetes Dashboard作为附加功能（microk8s enable dashboard），它将部署标准的Web UI。一旦启用，我们就可以访问它（它运行在端口10443或通过代理）。MicroK8s本身没有自定义的GUI – 它依赖于Kubernetes Dashboard或其他工具 – 但启用它的简便性是一个优势。总的来说，MicroK8s强调对常见任务的一条命令体验和“开箱即用”的理念，抽象了许多复杂性（代价是隐藏了一些内部细节）。这使其非常**适合那些希望在homelab中使用Kubernetes集群而无需手动设置每个组件的人。

对比K3s与MicroK8s： 两者在目标和功能上都非常相似 – 轻量、易用、支持多节点。K3s在添加额外功能时更倾向于“DIY”（依赖Helm图表或手动清单来实现未包含的内容），而MicroK8s通过其CLI提供内置的附加功能。MicroK8s在底层更接近“原生”Kubernetes（上游组件，仅打包为snap），而K3s使用一些自定义二进制文件和一个服务处理所有内容。两者都是homelab的良好选择；选择通常取决于偏好：如果更喜欢Ubuntu/snaps和集成感，MicroK8s非常出色；如果更喜欢极简主义并可能需要更多手动控制，K3s非常优秀。（我们将在最后提供建议。）

Minikube（单节点本地 K8s）

主要功能： Minikube 主要是一个用于在本地运行 Kubernetes 的工具（通常在开发者的 PC 或笔记本电脑上运行），而不是在多个机器上运行的传统集群。它在我们机器上的虚拟机或容器中创建一个单节点 Kubernetes 集群。Minikube 以其对环境的广泛支持而闻名——它可以在 Linux、macOS、Windows 上运行，并支持各种虚拟化平台（VirtualBox、KVM、Hyper-V、Docker 驱动等）。它由 Kubernetes SIGs 维护，通常用于测试和学习。虽然 Minikube 可以被配置为多节点模式，但本质上它是为单节点集群设计的（Minikube 的“多节点”模式实际上只是在同一主机上使用容器运行时启动多个节点——这对于模拟集群很有用，但不适合在不同的物理机器上运行）。

安装与使用便捷性： Minikube 在单机上非常容易上手。我们安装 minikube 二进制文件，确保我们有虚拟机驱动（或 Docker），然后运行 minikube start。这将设置一个本地虚拟机/容器并在其中启动 Kubernetes。这可能是首次运行 Kubernetes 集群最简单的方式。CLI（minikube）提供了与虚拟机交互的命令（启动、停止、删除）以及启用附加组件的命令。由于 Minikube 是为本地使用而设计的，它不是一个“长期运行”的守护进程——我们通常在需要时启动它，在完成时停止它，尽管我们可以在家庭实验室服务器上让它持续运行。维护和升级很容易：只需更新 minikube 的版本并重新启动集群（Minikube 也可以通过一个标志更新其运行的 Kubernetes 版本）。然而，一个限制是 Minikube 设计上是单节点的（添加更多节点意味着在同一主机上启动额外的虚拟机实例，而不是加入真正的独立主机）。因此，在 三个独立的物理节点 上使用 Minikube 实际上意味着运行三个独立的单节点集群，这可能不是我们想要的。Minikube 在 开发和测试 一台机器上表现出色，但它并不是用于管理跨多个物理服务器的集群。
持久卷支持： 内置（hostPath）。 Minikube 集群会自动包含一个默认的 StorageClass，它使用 hostPath 提供程序。事实上，Minikube 运行一个小控制器，当请求 PVC 时，它会在虚拟机内部动态创建 hostPath PV。这意味着我们可以创建 PersistentVolumeClaims，并且它们将通过 Minikube 虚拟机的文件系统（通常在 /tmp/hostpath-provisioner 或类似路径下）得到满足。这开箱即用——无需配置即可使用基本的 PV。例如，Minikube 的默认“standard”StorageClass 映射到节点上的 hostPath 存储。一个注意事项是，如果我们重启或删除 Minikube 虚拟机，这些 hostPath 卷可能会丢失（Minikube 会尝试在重启时保留某些目录，例如 /data、/var/lib/minikube、/tmp/hostpath*）。但总的来说，在非生产环境中这是可以接受的。如果我们想模拟更多，Minikube 还有一个 CSI hostpath 驱动附加组件，它支持快照并在多节点模式下运行，但更适合实验。总之，Minikube 默认通过 hostPath 支持 PV，这对于家庭实验室测试有状态应用是足够的。
负载均衡支持： 通过隧道（或 MetalLB 附加组件）支持。 在云环境中，LoadBalancer 服务会获得一个带有外部 IP 的云负载均衡器。在 Minikube 中，显然没有云提供商，所以 Minikube 提供了两种机制：
- Minikube 隧道： 我们可以在一个单独的进程中运行 minikube tunnel，它将在我们的主机上创建一个网络路由，并为我们的 LoadBalancer 服务分配一个 IP。本质上，它使用我们的主机作为“外部 LB”。当我们创建一个 LoadBalancer 服务时，Minikube 会显示一个“外部 IP”（通常来自集群的子网），并且 minikube tunnel 进程会将该 IP 路由到服务。这需要隧道进程持续运行（通常需要 root 权限来创建路由）。这是一个手动步骤，但 Minikube 会在没有运行隧道的情况下提醒我们（“External-IP pending” 直到我们启动隧道）。
- MetalLB 附加组件： 新版本的 Minikube 也包括一个 MetalLB 附加组件。我们可以运行 minikube addons enable metallb 并配置一个 IP 范围（Minikube 会提示我们）。这实际上是在 Minikube 集群内部部署 MetalLB，它会像在任何裸金属 Kubernetes 上一样处理 LoadBalancer 服务。这是一个更“集群内”的解决方案，并且在初始设置后不需要单独的隧道进程。
两种方法都有效，选择哪一种取决于我们。为了快速暴露一个服务，minikube tunnel 快速且临时。对于更持久的设置，可以启用 MetalLB 附加组件，使 LB 获得真实 IP（例如，我们可能在使用桥接网络的 Minikube 上分配一个范围如 10.0.0.240-250）。请记住，Minikube 通常是单节点的，因此实际上“负载均衡器”并不是在多个节点之间进行负载均衡，它只是为单个节点的服务提供外部访问。这对于开发是足够的。在家庭实验室中，如果我们只使用我们节点中的一个并在其上运行 Minikube，我们可以使用这些方法来访问我们的应用。但如果我们想利用所有 3 个节点，Minikube 的负载均衡方法并不适合这种场景。
资源需求： Minikube 本身很轻量，但由于它通常运行一个完整的单节点 Kubernetes（在虚拟机中），资源使用情况与一个正常的小型集群类似。推荐的最小资源是 2 GB 内存和 2 个 CPU 用于虚拟机。默认情况下，Minikube 通常为其虚拟机分配 2 GB 内存。在我们的情况下，每台机器有 16 GB 内存，这非常轻松。空闲状态下的 Minikube（Kubernetes）可能使用约 600 MB 内存。需要考虑的一点是，Minikube 将在我们的操作系统之上运行——要么作为虚拟机通过虚拟化平台，要么作为 Docker 容器——这会增加一些开销。在家庭实验室服务器上，我们可以使用“none”驱动运行 Minikube（它直接在主机上安装 Kubernetes 组件）。然而，“none”（也称为裸金属）驱动本质上类似于在该节点上使用 kubeadm，需要手动清理，因此不太受欢迎。大多数人使用虚拟机或 Docker 驱动。总之，我们家庭实验室中的任何节点都可以轻松运行 Minikube。唯一的限制是 Minikube 不会使用所有 3 个节点的资源——它将被限制在它运行的单个主机上（除非使用实验性的单主机多节点）。
单节点与多节点： 主要是单节点。 Minikube 适合在一台机器上运行单节点集群。它确实有一个功能可以模拟多个节点（例如，使用 Docker 驱动运行 minikube start --nodes 3 会在一个主机上启动 3 个 Kubernetes 节点作为容器），但这是用于测试的。我们不能使用 Minikube 在 3 台独立的物理服务器上创建真正的多节点集群。如果我们有 3 台机器，我们必须运行 3 个独立的 Minikube 实例（不在一个集群中）。这不是真正的集群体验（它们不会互相了解）。因此，如果我们的目标是利用所有三个节点在一个 Kubernetes 集群中，不建议使用 Minikube——它更适合我们只有一台机器（我们的 PC 或一台服务器）并想在其上运行 K8s 的场景。它也是学习 Kubernetes 基础知识和进行本地开发的绝佳工具。
CLI 与 UI 工具： minikube CLI 是主要的接口。我们使用它来启动/停止集群，它还有一些快捷方式：例如，minikube dashboard 会启用 Kubernetes Dashboard 并在我们的浏览器中为我们打开它。minikube addons enable <addon> 可以启用各种可选组件（ingress、metallb、metrics-server 等）。Minikube 会自动设置 kubectl 访问（它会在我们的 kubeconfig 中配置一个名为“minikube”的上下文）。对于 UI，如前所述，Kubernetes Dashboard 可以通过 dashboard 命令轻松访问。Minikube 没有自己独特的 Web UI；它依赖于标准工具。调试 Minikube 也很容易，因为我们可以通过 minikube ssh 进入节点虚拟机（如果需要）。总体而言，对于单节点场景，工具非常用户友好。

Kubeadm（在我们自己的节点上运行原生 Kubernetes）

主要功能： Kubeadm 不是一个“发行版”，而是创建 Kubernetes 集群的官方工具。使用 kubeadm 意味着我们在自己的机器上部署标准的上游 Kubernetes 组件。它本质上是我们“自己构建”集群的方式，遵循最佳实践但不包括发行版中包含的额外功能。Kubeadm 会设置一个控制平面节点（运行 etcd、API 服务器、控制器管理器、调度器）并将工作节点加入其中。结果是一个完全标准的 Kubernetes 集群，与我们在云虚拟机上获得的一样。这种方法给我们提供了完全的控制和灵活性——我们可以选择网络插件、存储提供程序等——但也需要最多的初始手动工作和知识。它通常用于生产环境或学习环境以了解 Kubernetes 内部结构。

安装与维护的便捷性： 与其他工具相比，kubeadm 是最繁琐的。我们必须手动安装依赖项（如 containerd、kubeadm、kubelet、kubectl）在每个节点上。然后在主节点上运行 kubeadm init，并在工作节点上使用它提供的令牌运行 kubeadm join。我们还需要在初始化后设置 CNI（网络插件）（如 Calico、Flannel 等），因为 kubeadm 默认不会安装一个。所有这些步骤都有良好的文档记录（这个过程不是难，但步骤很多）——本质上，kubeadm 会给我们一个起始集群，但期望我们处理附加组件。维护方面，我们负责升级（kubeadm 确实有一个升级命令，但我们必须手动排空节点、更新二进制文件等），以及监控 etcd 健康状况、证书续订等。简而言之，kubeadm 是 强大但手动的。它通常被称为“困难的方式”（尽管不如从源代码构建那么困难）。对于喜欢学习的家庭实验室爱好者，kubeadm 是深入了解 Kubernetes 的绝佳方式。但如果我们优先考虑“容易且维护成本低”，kubeadm 将比 K3s/MicroK8s 更加繁琐。每次升级或更改都需要动手操作。话虽如此，一旦设置好，它就是真正的 Kubernetes 集群：一个没有隐藏抽象的标准 Kubernetes 集群。
持久卷支持： 默认不支持（必须手动添加）。 通过 kubeadm 安装的集群本质上是一个空白的 Kubernetes——它不会默认包含 StorageClass 或动态提供程序。在云环境中，云提供商通常会提供一个默认的 StorageClass（例如 AWS EBS 等），但在家庭实验室的裸金属环境中，我们必须安装自己的解决方案。常见的方法包括：
- HostPath 提供程序： 我们可以复制 K3s/Minikube 的做法，安装类似 Rancher Local Path 提供程序（它是一个小控制器 + StorageClass，用于创建 hostPath PV）。这是一个简单的附加组件（只需一个 YAML 清单），并为我们提供本地动态存储。
- NFS 或 NAS： 一些家庭实验室用户设置一个 NFS 服务器（或使用 NAS），然后使用静态 PV 或 NFS CSI 驱动进行配置。
- OpenEBS/Longhorn/Ceph： 如果我们想要跨节点的分布式存储，可以部署 Longhorn 或 Ceph RBD 通过 Rook，但这些需要更多的资源和复杂性。
关键点是，kubeadm 不会“解决”存储问题——我们必须决定并配置它。如果优先考虑简便，最简单的路径是部署一个 hostPath 提供程序或使用 NFS。例如，Rancher 的 local-path 提供程序 可以通过几个 kubectl apply 命令安装，并会模拟 K3s 的行为（在任意节点的 /var/lib/rancher/ 下创建卷）。但这是一个手动步骤。在我们完成之前，任何创建的 PVC 都会处于“Pending”状态，因为 Kubernetes 没有默认的提供程序。因此，虽然 kubeadm 确实支持持久卷（它是完整的 Kubernetes），但 动态 PV 的支持程度取决于我们投入的设置努力。
负载均衡支持： 默认不支持（必须手动添加）。 这里的情况类似：在传统的本地集群中，我们没有内置的 LoadBalancer 实现。如果我们在一个普通的 kubeadm 集群上创建一个类型为 LoadBalancer 的服务，它将一直处于 pending 状态，直到我们部署一个控制器来处理它。常见的解决方案是 自行安装 MetalLB。MetalLB 可以通过清单或 Helm 图表安装——我们会配置一个 IP 范围，然后它会为 LoadBalancer 服务分配这些 IP（就像在 MicroK8s 中一样）。许多关于在 kubeadm 集群上安装 MetalLB 的指南都存在。另一个一些人使用的替代方案是 kube-vip 用于控制平面 VIP 和服务负载均衡，但 MetalLB 对于服务来说更简单。本质上，使用 kubeadm 我们有自由（或负担）设置适合我们需求的任何负载均衡机制。如果我们不设置任何东西，我们只能使用 NodePort 服务进行外部访问。在家庭实验室中，安装 MetalLB 高度推荐——它简单直接，并为我们提供类似云的负载均衡服务 IP 功能。但再次强调，这是一项我们必须执行的额外步骤（与 K3s 的开箱即用或 MicroK8s 的简单启用不同）。
资源需求： 标准 Kubernetes 比精简版本稍微重一些。每个节点将运行 kubelet 和 kube-proxy，主节点将运行 etcd 和控制平面组件。一个单控制平面节点可以在 2 GB 内存下运行，但如果我们打算在其上运行 Pod，通常我们可能希望多一些内存以获得舒适度。Padok 指南建议主节点 2 GB，工作节点 2 GB 最小。在我们的情况下（每节点 16 GB），这没问题。空闲的 etcd 和 API 服务器可能各自使用几百 MB 内存。在运行时，kubeadm 集群与 MicroK8s 之间的差异不大——毕竟，MicroK8s 就是这些相同的组件。差异只是默认运行的内容（MicroK8s 可能默认启用 DNS 和存储，而 kubeadm 上我们则需要安装这些）。因此，从资源角度来看，kubeadm 可以根据我们的配置变得非常轻量或非常重。如果没有安装任何额外内容，它可能非常轻量。在典型设置（例如我们添加 CoreDNS、Dashboard 等）下，预计系统开销将使用约 1 GB 内存。我们有大量内存，因此资源不是问题。它更多是关于管理它所需的人力和资源，而不是 CPU/内存。
单节点与多节点： Kubeadm 可以 两者都支持，具有完全的灵活性。我们可以初始化一个单节点集群（甚至可以告诉 kubeadm 让单节点运行工作负载，通过取消标记主节点）。或者我们有一个主节点并加入两个工作节点（一个常见的 3 节点设置）。我们甚至可以设置 3 个主节点和 3 个工作节点，等等——任何拓扑结构。在我们的情况下，一个可能的 kubeadm 设置是 1 个控制平面节点和 2 个工作节点（因为不需要高可用性，我们不需要多个主节点）。这给了我们一个功能齐全的 3 节点集群。多节点的流程有良好文档记录：本质上，是在所有节点上安装 Kubernetes，初始化一个，加入其他节点。结果与托管集群或其他发行版提供的结果相同：我们的 3 个节点会出现在 kubectl get nodes 等命令中。因此，kubeadm 确实满足了“可以使用所有 3 个节点”的要求。
CLI 与 UI 工具： 使用 kubeadm，唯一的特殊 CLI 是 kubeadm 本身，用于设置和（稍后）升级步骤。日常使用中，使用 kubectl 来管理集群。除了 Kubernetes 提供的之外，没有集成的管理 CLI。对于 UI，没有默认包含的内容——我们可以手动部署 Kubernetes Dashboard 或任何其他工具（就像任何集群一样）。本质上，kubeadm 给我们一个空白的 Kubernetes 画布。我们决定在上面绘制什么——包括安装方便工具如 Dashboard、Ingress 控制器、StorageClass 等。许多第三方仪表板（如 Lens、Octant 等）也可以连接到 kubeadm 集群，如果我们想要 GUI 管理体验，但这些是外部工具。总之，使用 kubeadm，我们获得的是纯 Kubernetes 环境——最大灵活性，但也需要像生产集群一样设置一切。
Kubespray 参见如何使用 Kubespray 安装 Kubernetes。

并排比较表

以下是对四种选项在关键点上的比较摘要：

方面	K3s (轻量级 Rancher K8s)	MicroK8s (Canonical “低运维” K8s)	Minikube (单节点开发 K8s)	Kubeadm (原生 Kubernetes)
安装	一行安装脚本（单个二进制文件）。作为单个系统服务运行。设置非常快速。	通过 Ubuntu 上的 snap 用一条命令安装。所有组件都包含在内。使用 `microk8s join` 可轻松进行集群。	安装 minikube CLI，然后使用 `minikube start` 启动本地 VM/容器。跨平台且对新手友好。	每个节点上手动安装 kubeadm、kubelet 等。运行 `kubeadm init` + `kubeadm join`，并需要先决条件。涉及多个步骤（运行时、网络插件等）。
维护与升级	手动升级（替换二进制文件或使用安装脚本安装新版本）。由于是单个二进制文件，因此很简单；几乎没有需要管理的内容。没有自动更新。	通过 snap 刷新进行更新（可以自动）。通过 `microk8s` CLI 管理附加组件和集群服务。通常运维需求低；提供自动升级功能。	删除/重新创建集群对开发来说很容易。通过更新 minikube 版本并重启集群进行升级。适用于临时使用（不太关注原地升级的持久性）。	用户负责所有升级。使用 `kubeadm upgrade`，但必须排空节点、处理 etcd 备份等。完全控制，但需要自己完成工作（没有自动更新）。
K8s 版本	与上游版本基本一致（通常用于边缘发布）。符合 CNCF 标准。某些功能默认禁用（alpha/旧版）。	跟随上游版本发布（snap 渠道为 1.27、1.28 等）。符合 CNCF 标准。本质上是原生 K8s 二进制文件。	我们可以在启动时选择 Kubernetes 版本（例如 `minikube start --kubernetes-version=v1.27`）。默认为最新稳定版本。	我们可以安装任何版本（安装特定的 kubeadm/kubelet 版本）。完全上游 Kubernetes – 我们决定版本和升级时间。
默认功能	内置默认功能：Flannel CNI、CoreDNS、Traefik 入口、服务负载均衡、本地存储类、metrics-server 等。（如果不需要，都可以禁用）。功能所需的最小配置。	默认功能最少：DNS 通常开启，其他功能可选。通过一条命令添加入口（NGINX）、MetalLB、hostpath 存储、仪表板等附加组件。可以在 3+ 节点上启用 HA 模式。	VM 内置：通常包括 Docker/containerd 运行时、Kubernetes 以及默认附加组件如 StorageProvisioner 和 DNS。附加组件（入口、仪表板等）可通过 CLI 开启或关闭。默认不支持多节点。	简洁：除了核心 Kubernetes 之外没有其他内容。没有入口、默认存储或负载均衡、没有仪表板，直到我们安装它们。我们选择 CNI 插件（必须安装一个用于网络）。本质上是一个 DIY 集群。
持久卷支持	是 – 开箱即用。包含 Rancher local-path 动态提供程序，可在节点上为任何 PVC 创建 hostPath PV。默认 StorageClass “local-path” 自动使用本地磁盘。	是 – 易于添加。启用 `hostpath-storage` 以获得用于动态 PV 的默认 StorageClass（使用 hostPath）。启用之前没有默认 PV 提供程序。附加组件不适合多节点生产环境，但适合家庭实验室。	是 – 开箱即用。默认 StorageClass 使用 minikube VM 内的 hostPath 提供程序。PVC 由一个简单的控制器在节点文件系统上创建 hostPath PV 来满足。在某些目录中，数据在重启后仍然保留。	否（手动）。没有默认提供程序 – 集群最初没有 StorageClass。用户必须安装存储解决方案（例如 local path 提供程序、NFS、Ceph 等）。基本方法：应用一个 hostPath 提供程序 YAML 来模仿 K3s/Minikube 的行为。直到那时，PVC 仍处于挂起状态。
负载均衡支持	是 – 内置 ServiceLB。 K3s 的 servicelb 控制器（Klipper）监视 LoadBalancer 服务并在节点上部署 pod 以暴露它们。使用节点的 IP 和主机端口转发流量。无需配置即可开箱即用。适合小型集群；使用节点的内部/外部 IP 进行服务。	是 – 通过 MetalLB 附加组件。启用 `metallb` 并指定一个 IP 范围进行分配。在裸金属上提供真正的 Layer-2 负载均衡器。默认未启用。启用后，每个 LoadBalancer 服务将从我们的 IP 池中获得一个唯一 IP。需要一些初始配置（IP 范围）。	是 – 通过隧道或 MetalLB。没有云负载均衡器，但我们可以运行 `minikube tunnel` 为 LoadBalancer 服务分配一个外部 IP（在主机上创建路由）。或者在 minikube 中启用 MetalLB 附加组件以自动分配 LB IP。默认情况下，LB 服务将显示“pending”直到我们使用这些方法之一。	否（手动）。没有内置负载均衡器。通常手动安装 MetalLB 以实现裸金属负载均衡功能。一旦设置好 MetalLB（或其他 LB 控制器），LoadBalancer 服务即可工作。没有它，LB 服务将无限期处于 pending 状态。
网络（CNI）	默认 = Flannel（覆盖网络）。K3s 也支持替换 CNI（如有需要）。默认部署 CoreDNS 用于集群 DNS。Traefik 入口默认包含（可以禁用）。	默认 = Calico（对于 HA 模式下的最新版本）或一个简单的默认设置。（MicroK8s 历史上使用 flannel；现在倾向于使用 Calico 以实现严格隔离）。默认启用 CoreDNS。可通过附加组件启用 NGINX 入口（`microk8s enable ingress`）。	默认 = kubenet/bridge（取决于驱动；通常使用简单的 NAT 网络）。默认运行 CoreDNS。如需，可以启用 NGINX 入口附加组件。网络限于单个 VM；NodePort 可通过 `minikube ip` 访问。	CNI 的选择。 Kubeadm 不安装任何 CNI 插件 – 我们必须部署一个（Calico、Flannel、Weave 等）。我们有完全的控制权。大多数指南在 kubeadm init 之后应用 Calico YAML。CoreDNS 默认由 kubeadm 安装为集群 DNS。入口控制器 – 选择并自行安装（例如通过 YAML/ Helm 安装 NGINX 或 Traefik）。
多节点集群	是。专为多节点设计。通过令牌轻松加入。可以使用外部数据库或嵌入式 etcd 进行多主节点。非常适合 2-3+ 节点的家庭实验室。不需要额外依赖 – K3s 内置了自己的集群功能。	是。支持多个 MicroK8s 节点（使用 `microk8s join`）。可以启用 HA 模式（3+ 主节点，Dqlite）。非常容易形成集群，特别是如果所有节点都运行 Ubuntu + snap。	否（物理）。设计为单节点。可以在一台机器上模拟多节点（多个节点在 Docker 容器中），但不能在一个集群中跨越多个物理主机。使用单独的 Minikube 实例创建单独的集群。	是。完全支持多节点（这就是它的目的）。我们可以有 1 个主节点 + 多个工作节点，甚至多个主节点（尽管 kubeadm HA 设置更复杂）。集群大小没有内置限制。
资源开销	非常低。控制平面 ~<0.5 GB 内存空闲。控制平面单进程带来小的占用空间。在 CPU 上高效（尽管根据某些报告，空闲时可能比 MicroK8s 使用略多的 CPU）。适合低功耗或有大量备用容量的环境。	低。控制平面空闲时 ~0.5–0.6 GB 内存。比 K3s 稍高的基础内存，但保持稳定。使用 Ubuntu snap（可能有一些开销）。仍然比完整 Kubernetes 轻量。	中等。VM 默认分配 2 GB（空闲时使用 ~0.6 GB）。运行完整的单节点 Kubernetes，加上 VM 层。在 16 GB 系统上不是问题，但本质上消耗了小型集群在一台机器上的资源。	中等。一个主节点加一个工作节点在添加典型附加组件后可能使用 ~1 GB 空闲。每个额外节点仅增加少量开销（仅 kubelet、代理）。与在类似大小的云 VM 中运行 Kubernetes 相似。在 3 个节点上，每个有 16 GB，开销在上下文中可以忽略不计。
CLI 工具	使用 `k3s` 进行安装和作为 `kubectl` 的包装器（或使用标准 `kubectl`）。没有单独的管理 CLI（K3s 主要是“设置后忘记”）。一些辅助脚本（例如 `k3s-killall.sh`）。如果需要，可以添加 Rancher 的 GUI。	丰富的 `microk8s` CLI：例如，`microk8s enable/disable <addon>`、`microk8s status`。还包括 `microk8s kubectl`。设计用于简化常见任务（无需直接编辑系统清单即可完成基本操作）。	`minikube` CLI 用于启动/停止集群、管理配置和附加组件以及获取信息（IP、服务 URL、日志）。还提供便捷命令，如 `minikube dashboard`。通过 `kubectl` 与集群交互（minikube 上下文的配置自动设置）。	仅 `kubeadm` 用于初始设置和升级。日常操作通过标准 `kubectl` 和其他 Kubernetes 工具进行。除了引导之外，没有特定发行版的 CLI。你将使用原始 Kubernetes 命令和可能的系统工具进行维护。
UI / 仪表板	默认不包含。可以手动安装 Kubernetes 仪表板或使用外部工具（除非我们单独添加 Rancher，否则没有 Rancher 特定的内容）。K3s 的重点是无头操作。	默认不包含，但可通过一条命令启用：`microk8s enable dashboard` 部署标准仪表板 UI。通过 `microk8s dashboard-proxy` 轻松访问集群。还与 Canonical 的 Lens GUI 集成良好（如果需要，Lens 可直接访问 MicroK8s）。	默认未启用，但 `minikube dashboard` 命令将为我们部署并打开仪表板 Web UI。这是为了本地开发的便利 – 一条命令，我们就有了一个 GUI 来查看工作负载。	不包含。如果我们想要，可以安装仪表板（应用 YAML）。否则，使用 CLI 或第三方仪表板应用。在家庭实验室中，可能会安装仪表板并创建 NodePort 或使用 `kubectl proxy` 查看它。Kubeadm 不关心 UI。

来源： 上述数据综合自官方文档和用户指南：例如，内存占用来自 MicroK8s 自己的比较，K3s 默认存储来自 K3s 文档，K3s 服务负载均衡行为来自 K3s 文档，MicroK8s 附加组件详情来自 Canonical 文档，Minikube PV 和隧道来自 Kubernetes 文档，以及一般经验报告。（参见参考文献以获取完整引用。）