RKE 和 RKE2 的安装
安装 RKE 时需要做一些准备。必须提供一个包含基本配置的 yaml 文件，或者直接运行二进制文件，并回答其中的问题，从而生成相应的 yaml 文件。对我而言，我不太清楚这些问题是在询问哪些信息。我只能反复多次运行安装程序来查看结果，以此来确定对应的情况。不过在成功安装后，这其实不算什么大问题。我们可以部署一个高可用集群，并通过换个 yaml 文件来完成版本和配置更新。
而 RKE2 的安装流程更加直观。可以直接运行脚本来安装一个节点，之后再用 token 来添加更多节点。另外，还可以使用二进制文件配置集群节点。为了尽量简化安装流程，RKE2 的多数配置都使用了合理的默认值，但也可以通过配置文件来自定义部署集群。
![]()
图 1–RKE 集群配置文件示例
在评估 RKE 和 RKE2 时，最重要的考量因素就是它们的安装方法以及它们如何与 Rancher 结合使用。如果你正在测试对比这两种发行版，很可能是因为你已经开始使用 Rancher，或者有这方面的计划。
RKE 和 RKE2 在 Rancher 中的部署方法完全不同。RKE 采用非标准化的开源部署方法。而部署 RKE2 和 K3s 使用的是开源项目 Cluster API(https://github.com/kubernetes-sigs/cluster-api)，这一开源项目正在逐渐成为 Kubernetes 集群部署的统一标准。除此之外，它还有其他多项优势。
Rancher 现已支持在多个平台部署 RKE 和 RKE2 集群。使用 Cluster API 部署 RKE2 和 K3s 为我们提供了一个新的维度。即使对于 Rancher 不支持的开箱即用的基础设施提供程序，也可以使用 Cluster API 及其驱动程序在 Rancher UI 中创建自定义提供程序。之后即可使用 Rancher 的管理和自动化功能，并且无论采用哪种基础设施提供程序，都可以通过 Rancher 的 API 来管理集群的整个生命周期。
RKE 与 RKE2 的主要区别
RKE 和 RKE2 之间最大的区别在于容器运行时。RKE 需要 Docker 作为容器运行时，而 RKE2 依靠的是 Containerd，Containerd 已经成为行业标准的容器运行时。CNCF 于 2020 年 12 月宣布，他们将放弃将 Docker 作为 Kubernetes 的默认运行时，改用 Containerd 作为默认容器运行时。另一个重要差异是，RKE2 使用 Kubelet 管理的静态 Pod 作为控制平面组件，而 RKE 中的控制平面组件由 Docker 管理。
CNI 插件
两个发行版都完全符合 CNCF 认证要求，不过除了容器运行时之外，它们之间还有一些差异。首先，RKE 可选择的 CNI 插件集成与 RKE2 不同，包括：Canal、Flannel、Calico 和 Weave。而 RKE2 可以使用的是 Cillium、Calico、Canal 和 Multus。
Cillium 和 Multus 之间有很大区别，这些不同对于使用 RKE2 的电信通讯和多网卡用例尤其明显。而且，如果不支持 Multus，就无法为一个 Pod 添加多个网卡。Cillium 具备出色的网络连接性能，以及丰富的安全防护和合规功能，这对于电信通讯应用来说相当重要。
安全防护
RKE2 原名 RKE Government，设计初衷是供美国政府项目部署使用。安全防护在这类项目中的重要意义不言而喻，所以 RKE2 尤其注重开箱即用的安全性与合规性。
RKE2 的配置能够最大限度简化通过 CIS Kubernetes 基准测试所需的配置工作，确保加密模块的 FIPS 140-2 合规性，并针对集群中使用的镜像使用 Trivy 定期扫描完整生命周期漏洞 (CVE)。
RKE 是标准的 Kubernetes 发行版，没有特别强调安全防护。
这又是一个显著的差异。由于 RKE2 使用 K3s 作为基础，所以具备其简单化、模块化和操作简便的特性以及部署模型，将 RKE 与 K3s 二者的优势集于一身。值得一提的是，K3s 是为资源有限的环境打造的轻量级发行版，设计目的在于简化操作，由此让我们能在边缘场景中管理成千上万个单节点集群。
结论
RKE2 被视为 RKE 的下一个迭代版本。凭借注重安全防护的配置、轻松简便的操作和更加优化的 CNI 插件集成，对于电信通讯、网络性能要求更高的 App 和看重安全防护与合规性的环境而言，RKE2 都将是理想的选择。
当然，RKE 也是稳定的、经过 CNCF 认证的 Kubernetes 发行版，同样适用于各类生产环境。
