【译】RKE2 和 K3s 怎么选？

译者注

按照近2个月的实验经验，在与Rancher的兼容性，以及稳定性上看RKE2 > K3s > RKE1，K3s在安装Longhorn的时候碰到了CSI无法正确部署的问题，同样的主机环境，RKE2一次性成功，更别说RKE1在节点初始化就碰到了问题。

最终的方案是两节点K3s配置外部PostgresSQL数据库做高可用，安装Rancher的local集群，作为管理集群，应用集群选择RKE2，开始愉快的玩耍吧。

一、概述

K3s 和 Rancher Kubernetes Engine（RKE2）是 SUSE Rancher 容器平台的两个 Kubernetes 发行版。这两个项目均可用于运行生产就绪集群；但是，它们针对不同的用例，因此具有独特的特性。

本文将解释这两个项目之间的异同。您将了解何时使用 RKE2 而不是 K3s 有意义，反之亦然。选择正确的选项非常重要，因为它会影响您部署的容器化工作负载的安全性和合规性。

二、K3s 和 RKE2

K3s 通过一个不到 60MB 的二进制文件提供了一个生产就绪的 Kubernetes 集群。由于 K3s 非常轻量级，它是在物联网设备、低功耗服务器和开发人员工作站的边缘运行Kubernetes的绝佳选择。

同时，RKE2 也是一个运行生产就绪集群的替代项目。它提供了与 K3s 类似的简单性，同时增加了额外的安全性和一致性层，包括符合美国联邦信息处理标准（FIPS）140-2，可用于美国联邦政府和 DISA STIG 合规性。

RKE2 由最初的 RKE 项目发展而来。它也被称为 RKE Government，反映了它适用于要求最严格的部门。不过，受益的不仅仅是政府机构–该发行版是所有优先考虑安全性和合规性的组织的理想选择，因此它仍然主要作为RKE2 进行营销。

三、K3s 和 RKE2 的相似之处

K3s 和 RKE2 都是 Rancher 完全支持的轻量级云原生计算基金会（CNCF）认证的 Kubernetes 发行版。尽管它们的目标用例不同，但这两个平台在启动和运行方式上有一些有意的相似之处。两者都可以使用 Rancher Manager进行部署，并且都使用行业标准的 containerd 运行时运行容器。

3.1. 可用性

K3s 和 RKE2 都具有良好的可用性和快速的安装体验。

在新主机上启动 K3s 集群只需一条命令和大约30秒的等待时间：

$ curl -sfL https://get.k3s.io | sudo sh -

服务已为您注册并启动，因此您可以立即运行 kubectl 命令与集群交互：

$ k3s kubectl get pods

RKE2 的情况也不差。类似的直接安装脚本可用于下载其二进制文件：

$ curl -sfL https://get.rke2.io | sudo sh -

RKE2 默认不启动服务。运行以下命令在服务器（控制平面）模式下启用并启动 RKE2：

$ sudo systemctl enable rke2-server.service
$ sudo systemctl start rke2-server.service

你可以在 /var/lib/rancher/rke2/bin 找到绑定的kubectl二进制文件。默认情况下，它不会被添加到你的 PATH 中；一个 kubeconfig 文件被存放在 /etc/rancher/rke2/rke2.yaml 中：

$ export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
$ /var/lib/rancher/rke2/bin/kubectl get pods

3.2. 操作简便

除了可用性之外，K3s 和 RKE2 的操作也很简单。您可以通过在每个节点上重复安装脚本来升级使用这两个项目创建的集群：

# K3s
$ curl -sfL https://get.k3s.io | sh -

# RKE2
$ curl -sfL https://get.rke2.io | sh -

您应该重复您在原始安装命令中提供的任何标志。

使用 Rancher 的系统升级控制器（system-upgrade-controller）支持自动升级。安装控制器后，您可以声明式地创建描述如何将群集迁移到新版本的 Plan 对象。计划是控制器提供的自定义资源定义（CRD）。

备份和恢复数据是 Kubernetes 的另一个常见挑战。K3s 和 RKE2 在这一领域也互为镜像。快照会自动写入并保留一段可配置的时间。通过运行以下命令，您可以轻松地从快照中还原集群：

# K3s
$ k3s server \
    --cluster-reset \
    --cluster-reset-restore-path=/var/lib/rancher/k3s/server/db/etcd-old-

# RKE2
$ rke2 server \
    --cluster-reset \
    --cluster-reset-restore-path=/var/lib/rancher/rke2/server/db/etcd-old-

3.3. 部署模式

K3s 和 RKE2 共享其单一二进制部署模型。它们将所有依赖捆绑到一个下载文件中，使您能够以最少的 Kubernetes 经验部署一个正常运行的集群。

这些项目还支持空气封装环境，以适应与网络物理隔离的关键机器。发布的工件中提供了空气封装的映像。一旦您将映像传输到您的机器上，运行常规安装脚本即可启动您的集群。

3.4. 高可用性和多节点

K3s 和 RKE2 设计用于在生产环境中运行。K3s 作为理想的单节点集群，在开发中也经常使用。它具有强大的多节点管理功能，能够支持物联网设备群。

这两个项目都能以高可用性运行控制平面。您可以在多个服务器节点上分发控制平面组件的副本，并使用外部数据存储代替嵌入式数据存储。

四、K3s 和 RKE2 的区别

K3s 和 RKE2 都提供单二进制 Kubernetes、高可用性和简易备份，两者之间的许多命令都可以互换。然而，一些关键差异会影响它们的使用场合和时间。正是这些特性证明了这两个发行版作为两个独立项目存在的合理性。

4.1. RKE2 更接近上游 Kubernetes

K3s 通过了 CNCF 认证，但在一些方面与上游 Kubernetes 存在差异。它使用 SQLite 而不是 etcd 作为默认的数据存储，尽管在现代版本中，嵌入式 etcd 实例是一个可选项。K3s 还捆绑了额外的实用工具，例如 Traefik Ingress控制器。

RKE2 更接近标准 Kubernetes，将一致性作为其主要特性之一。这让您有信心，为其他发行版开发的工作负载将在 RKE2 中可靠运行。它降低了 K3s 与上游 Kubernetes 不一致时可能出现的不便的风险。RKE2 自动使用 etcd 进行数据存储，省略了 K3s 中的非标准组件。

4.2. RKE2 使用嵌入式 etcd

K3s 中的标准 SQLite 数据库有利于紧凑性，并能优化小型集群的性能。相比之下，RKE2 默认使用 etcd，创造了更符合标准的体验，允许您直接与其他需要 etcd 数据存储的 Kubernetes 工具集成。

虽然 K3s 可以配置 etcd，但这是一个需要开启的选项。RKE2 就是围绕它设计的，这降低了配置错误和性能不佳的风险。

K3s 还支持 MySQL 和 PostgreSQL 作为替代存储解决方案。这些解决方案可让您使用现有的关系数据库工具管理 Kubernetes 数据，例如备份和维护操作。RKE2 仅适用于 etcd，不支持基于 SQL 的存储。

4.3. RKE2 更注重安全性

RKE2 更加注重安全。边缘操作是 K3s 的专长，而 RKE2 则将安全作为其最大的优势。

4.3.1. 针对 CIS 基准进行了加固

该发行版的配置兼容 CIS Kubernetes 加固基准 v1.23（RKE2 v1.25及更早版本为v1.6）。RKE2 应用的默认值允许您的集群以最少的手动工作达到标准。

您仍有责任加强节点上的操作系统级控制。这包括应用适当的内核参数，并确保 etcd 数据目录得到正确保护。
您可以通过将配置文件标志设置为 cis-1.23 来启动 RKE2，从而强制执行安全配置。如果操作系统未经过适当加固，RKE2 将以致命错误退出。

除了配置操作系统外，您还必须设置适当的网络策略和 Pod 安全准入规则，以确保集群工作负载的安全。安全准入控制器可配置为使用符合 CIS 基准的配置文件。这将防止不合规的 Pod 部署到您的集群。

4.3.2. 定期扫描威胁

RKE2 发行版的安全性由其构建管道维护。使用Trivy容器漏洞工具，定期对组件进行新的常见漏洞和暴露（CVE）扫描。这确保了 RKE2 本身不会隐藏可能让攻击者进入您的环境的威胁。

4.3.3. 符合 FIPS 140-2 标准

K3s 缺乏任何正式的安全认证。RKE2 符合美国政府用来批准加密模块的 FIPS 140-2标准。

该项目的 Go 代码使用 FIPS 验证的加密模块编译，而不是 Go 标准库中的版本。该发行版的每个组件，从Kubernetes API 服务器到 kubelet 和捆绑的 kubectl 二进制文件，都是用 FIPS 兼容编译器编译的。

FIPS 授权意味着 RKE2 可以部署在政府环境和其他要求可验证加密性能的环境中。当您使用内置组件（如 containerd 运行时和 etcd 数据存储）时，整个 RKE2 堆栈都是合规的。

五、何时使用 K3s

当您需要在边缘运行一个高性能的 Kubernetes 发行版时，K3s 应该是您的首选解决方案。对于单节点开发集群以及 CI 管道和其他构建工具中使用的短暂环境，它也是一个不错的选择。

在您的主要目标是通过单一二进制文件部署 Kubernetes 和所有依赖项的情况下，该发行版最有意义。它轻量级、快速启动且易于管理，因此您可以专注于编写和测试您的应用程序。

六、何时使用 RKE2

只要安全至关重要，您就应该使用 RKE2，例如在政府服务和其他高度受监管的行业，包括金融和医疗保健行业。如前所述，完整的 RKE2 发行版符合 FIPS 140-2 标准，并通过 CIS Kubernetes Benchmark 进行了加固。它也是唯一通过 DISA STIG 认证的 Kubernetes 发行版，这意味着它被批准用于最严格的美国政府环境，包括国防部。
RKE2 经过全面认证，并与上游 Kubernetes 紧密结合。它省略了非标准 Kubernetes 或不稳定的 alpha 特性的 K3s 组件。这增加了您的部署在不同环境中互操作的可能性。它还降低了由于手动加固 Kubernetes 集群时的疏忽而导致不符合要求的风险。

近边缘计算是 RKE2 优于 K3s 的另一个主要用例。RKE2 支持多个 CNI 网络插件，包括 Cilium、Calico 和 Multus。Multus 允许 pod 连接多个网络接口，非常适合电信配送中心和拥有多个不同生产设施的工厂等用例。在这些情况下，使用不同的网络适配器提供强大的网络支持至关重要。K3s 将 Flannel 作为其内置的 CNI 插件；您可以安装不同的提供商，但所有配置必须手动执行。RKE2 的默认发行版为常见的网络解决方案提供了集成选项。

七、结论

K3s 和 RKE2 是两个流行的 Kubernetes 发行版，它们在多个方面相互重叠。它们都提供了简单的部署体验、无摩擦的长期维护以及高性能和兼容性。

虽然 K3s 专为微小和前沿用例而设计，但它并不局限于这些场景。它也广泛用于开发、实验室或资源有限的环境。不过，K3s 并不注重安全性，因此您需要确保集群的安全并强制执行集群。

RKE2 继承了 K3s 的可用性精神，并将其应用到完全兼容的发行版中。它专为安全而定制，与上游 Kubernetes 紧密结合，并符合政府机构等监管环境的合规性要求。RKE2既适用于数据中心，也适用于近端环境，因为它内置了对包括 Multus 在内的高级网络插件的支持。

您应该选择哪一种取决于您的集群将在何处运行以及您将部署的工作负载。如果您希望为安全关键型工作负载提供加固的发行版，或者需要符合 FIPS 140-2 标准，则应使用 RKE2。它将帮助您建立并维护健康的安全基线。对于不那么敏感的情况和边缘工作负载，K3s 仍然是一个积极支持的替代方案。它是一个包含电池的项目，当您想专注于您的应用程序而不是运行它们的环境时。

这两种发行版都可由 Rancher 管理，并与您的 DevOps 工具箱集成。您可以使用 Fleet 等解决方案，利用 GitOps策略大规模部署应用，然后前往 Rancher 仪表板监控您的工作负载。

Translated with DeepL

原文地址：https://www.suse.com/c/rancher_blog/when-to-use-k3s-and-rke2/