乐趣区

关于rancher:选择-K3s-还是-RKE2一文读懂

jiezi

K3s 和 RKE2 是 SUSE Rancher 容器平台的两个 Kubernetes 发行版，都能够运行生产就绪的集群，然而它们实用的用例不同，两者都有独特的性能。

本文将介绍这两个我的项目的相同点和差异性，帮您理解如何正当选用 RKE2 和 K3s，来满足容器化工作负载的安全性和合规性。

K3s 和 RKE2

K3s 仅应用一个不到 70MB 的二进制文件来提供生产就绪的 Kubernetes 集群。K3s 十分笨重，很适宜在边缘 IoT 设施、低功耗服务器和开发工作站上运行 Kubernetes。

RKE2 也能运行生产就绪的集群。它与 K3s 一样简略易用，而且重视安全性和合规性。RKE2 是从 RKE 我的项目演变而来的，也称为 RKE Government，这个名称也反映了它实用于要求最刻薄的畛域。但它的利用范畴不仅限于政府机构，而是所有器重安全性和合规性的组织的现实抉择，因而咱们将其倒退成了当初的 RKE2。

K3s 和 RKE2 的相似之处

K3s 和 RKE2 都由 Rancher 齐全反对，都是云原生计算基金会 (CNCF) 认证的 Kubernetes 发行版。尽管二者的指标用例不同，但它们的启动和操作形式相似，都能够通过 Rancher Manager 部署，而且都能应用行业标准的 containerd 运行时运行容器。

可用性

K3s 和 RKE2 的装置十分不便，而且启动速度都十分快。

只需应用一条命令并期待大概 30 秒，就能够在新主机上启动 K3s 集群：

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

该服务已注册并启动，能够立刻运行 kubectl 命令与集群进行交互：

 $ k3s kubectl get pods

RKE2 也相似，能够应用一个简略的装置脚本来下载其二进制文件：

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

RKE2 默认不启动服务。能够运行以下命令，从而在 server（control plane）模式下启动 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

易用性

除了可用性，K3s 和 RKE2 还十分易用，能够通过在每个节点上反复运行装置脚本来降级集群：

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

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

您须要反复提供原始装置命令中的标记。

能够应用 Rancher 的 system-upgrade-controller 来反对主动降级。装置 controller 后，能够通过申明创立 Plan 对象，该对象形容了如何将集群迁徙到新版本。Plan 是由 controller 提供的自定义资源定义（CRD）。

备份和复原数据是另一个常见的 Kubernetes 挑战。K3s 和 RKE2 在这方面也十分相似。快照会主动写入并保留一段可配置的工夫。您能够运行以下命令轻松地通过快照复原集群：

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

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

部署模型

K3s 和 RKE2 的单节点部署模型雷同。它们将所有依赖项捆绑到一次下载中，因而不须要具备很多 Kubernetes 教训就能部署一个失常运行的集群。

它们还反对离线环境，因而都能装置在与物理网络隔离的主机中。咱们在 Release artifacts 中提供了离线镜像，将镜像传输到主机后，运行装置脚本将疏导您的集群。

高可用性和多节点

K3s 和 RKE2 都是为生产环境运行而设计的。开发中也常常应用 K3s，K3s 被誉为现实的单节点集群。它具备弱小的多节点治理性能，能支持物联网设施群。

两个我的项目都能够运行高可用的 control plane。您能够将 control plane 组件的正本散布在多个 Server 节点上，并应用内部数据存储而不是嵌入式数据存储。

K3s 和 RKE2 的差别

K3s 和 RKE2 都应用单个二进制 Kubernetes，反对高可用设置而且易于备份，两者的许多命令都能够调换。然而，一些要害的差别会影响它们的应用场景，这也是咱们把这两个发行版辨别为两个独立我的项目的起因。

RKE2 更靠近上游 Kubernetes

K3s 已通过 CNCF 认证，但 K3s 在某些方面还是与上游 Kubernetes 不同的。尽管嵌入式 etcd 实例是古代版本中的可用选项，然而 K3s 应用 SQLite 而不是 etcd 作为默认数据存储。K3s 还附带了其余实用程序，例如 Traefik Ingress controller。

RKE2 更靠近规范 Kubernetes，晋升一致性是其次要个性之一。因而，您针对其余发行版开发的工作负载也能牢靠地在 RKE2 中运行。它升高了当 K3s 与上游 Kubernetes 不统一时可能产生的危险。RKE2 主动应用 etcd 进行数据存储，并去掉了 K3s 中蕴含的非标准组件。

RKE2 应用嵌入式 etcd

K3s 中的规范 SQLite 数据库更紧凑，能够在小型集群中优化性能。相比之下，RKE2 默认应用 etcd，因而更统一，让您能间接集成其余须要 etcd 数据存储的 Kubernetes 工具。

尽管 K3s 能够配置 etcd，但须要手动关上该选项。RKE2 是围绕它设计的，因而能升高配置谬误和性能不佳的危险。

K3s 还反对应用 MySQL 和 PostgreSQL 作为代替的存储解决方案，因而能够应用现有的关系数据库工具来治理 Kubernetes 数据，例如进行备份和保护。RKE2 仅实用于 etcd，不反对基于 SQL 的存储。

RKE2 更重视平安

边缘操作是 K3s 的特长，而 RKE2 最大的劣势是安全性。

  • 针对 CIS Benchmark 的强化

    RKE2 发行版的默认配置兼容 CIS Kubernetes Hardening Benchmark v1.23（RKE2 v1.25 及更早版本中为 v1.6）。RKE2 的默认值能让集群以起码的手动操作达到规范要求。

    您依然须要增强节点上的操作系统级别管制，其中包含利用适当的内核参数并确保 etcd 数据目录受到爱护。

    在启动 RKE2 时，能够通过将 profile 标记设置为 cis-1.23 来强制应用平安配置。如果操作系统没有失去适当的强化，RKE2 将退出并提醒谬误。

    除了配置操作系统之外，还必须设置适合的网络策略和 Pod 平安准入规定，从而爱护集群的工作负载。您能够将平安准入控制器配置为应用合乎 CIS Benchmark 的配置文件，这将避免不合规的 Pod 部署到集群中。

  • 定期扫描威逼

    RKE2 发行版的安全性会在构建流水线时进行保护。咱们会应用 Trivy 容器破绽工具定期扫描组件以查找新的通用破绽披露 (CVE)。因而，能够认为 RKE2 自身不存在可能让攻击者进入环境的威逼。

  • 合乎 FIPS 140-2 规范

    K3s 不足正式的平安认证，而 RKE2 合乎 FIPS 140-2 规范。该项目标 Go 代码是应用 FIPS 验证的加密模块而不是 Go 规范库中的版本编译的。该发行版的每个组件（Kubernetes API Server、kubelet、捆绑的 kubectl 二进制文件等）都是应用 FIPS 兼容的编译器编译的。

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

什么时候应用 K3s

如果您须要运行在边缘的高性能 Kubernetes 发行版，K3s 是首选解决方案。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 连贯多个网络接口，因而非常适合 telco 配送核心以及领有多个不同生产设施的工厂等用例。在这些状况下，应用不同的网络适配器提供弱小的网络反对至关重要。K3s 附带了 Flannel 作为内置的 CNI 插件，能够装置不同的 CNI，但所有配置都必须手动执行。RKE2 的默认发行版为常见的网络解决方案提供了集成选项。

论断

K3s 和 RKE2 都是风行的 Kubernetes 发行版，它们在多个方面互相重叠。它们的部署简略、保护便捷，而且性能和兼容性都很高。

尽管专为微型和远边缘用例而设计，但 K3s 并不局限于这些场景。它还宽泛用于开发、实验室或资源受限的环境中。然而，K3s 并不专一于安全性，因而您须要爱护和强化您的集群。

RKE2 具备 K3s 的可用性，并将其利用于齐全合规的发行版。它专一于安全性、与上游 Kubernetes 的关联，以及政府机构等受监管环境的合规性。因为 RKE2 内置了高级网络插件（包含 Multus）反对，因而它实用于数据中心和近边缘用例。

您的抉择取决于集群运行的地位以及要部署的工作负载。如果想为器重平安的工作负载应用强化的发行版，或者有 FIPS 140-2 合规要求，那么就能够选用 RKE2，它将帮忙您建设和保护平安基线。如果您的工作负载对安全性的要求不高，或者是边缘工作负载，那么 K3s 则是一个不错的代替计划，能让您专一于应用程序自身而不是运行的环境。

这两个发行版都能够由 Rancher 治理并与您的 DevOps 工具箱集成。您能够应用 Fleet 等解决方案通过 GitOps 策略大规模部署应用程序，而后返回 Rancher 仪表板监控工作负载。

退出移动版