選擇 K3s 還是 RKE2？一文讀懂！

Rancher發表於2023-01-11

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 儀表板監控工作負載。

相關文章