Rancher RFO 正式 GA

Rancher發表於2022-12-26

Rancher RFO GA

RFO 是 Rancher For openEuler 的縮寫，旨在面向 openEuler 打造 Rancher 基礎平臺。其中最核心的工作是打造一款面向 openEuler 生態的 Kubernetes 發行版。它基於上游 RKE2 的技術棧，構建物採用 openEuler base image，致力於滿足國內更加註重的安全合規標準，對 openEuler LTS 版本擁有優秀的相容性。

SUSE 在尤拉開源社群中成立了 RFO SIG，以社群協作方式運作產品迭代，並將 RFO 發行版的工作成果進行開源（https://gitee.com/rfolabs/rfo）。

RFO 發行版的主要願景如下：

  • 完整可溯源的工程化。確保核心元件的構建記錄和端到端測試結果均可溯源。
  • 產品化開箱即用。確保 RFO 的安裝部署可以快速上手，並支援從 Rancher Prime 配置部署。
  • 充分依託 openEuler 生態。確保核心元件的構建使用 openEuler 生態體系，依託 openEuler container image 進行最終打包。
  • 軟體供應鏈安全與合規。確保核心元件的分發產物不可篡改，並致力於提供等保加固的 Kubernetes 叢集環境。
  • 多樣性算力支援。提供面向 AMD64 和 ARM64 以及 RISC-V 等多樣性算力的 Kubernetes 基礎設施。

RFO SIG 於 2022 年 9 月初在尤拉開源社群成立，歷經 3 個月的工程迭代，我們正式推出 RFO 發行版的 GA 版本，歡迎試用並在 Rancher 社群和尤拉開源社群進行反饋。目前有以下已測試的版本可供使用：v1.23.14+rfor1/v1.24.8+rfor1/v1.25.4+rfor1 ，後續我們也會長期跟蹤 Kubernetes 的上游版本演進。

快速上手

基於 RFO v1.24.8+rfor1 版本以及 openEuler 22.03-LTS 進行快速上手演示。

安裝準備

安裝準備步驟需要在所有主機上執行：

1. 檢視 OS 版本：

cat /etc/os-release

輸出：

NAME="openEuler"
VERSION="22.03 LTS"
ID="openEuler"
VERSION_ID="22.03"
PRETTY_NAME="openEuler 22.03 LTS"
ANSI_COLOR="0;31"

2. 配置 NetworkManager 進行忽略 Canal CNI 的 veth 介面

touch /etc/NetworkManager/conf.d/rfo-canal.conf
cat >> /etc/NetworkManager/conf.d/rfo-canal.conf << EOF
[keyfile]
unmanaged-devices=interface-name:cali*;interface-name:flannel*
EOF
systemctl disable nm-cloud-setup.service nm-cloud-setup.timer
systemctl reload NetworkManager

3. 停止 openEuler 防火牆服務，RFO 中預設的 Canal CNI 與 Firewalld 網路棧有衝突，需要禁用 Firewalld

systemctl stop firewalld
systemctl disable firewalld

安裝Server

1. 使用 install 指令碼安裝 RFO：

curl -sfL https://gitee.com/rfolabs/rfo/raw/rfo-master/install-rfo.sh | INSTALL_RFO_VERSION="v1.24.8+rfor1" sh -
該指令碼只能透過 root 使用者或 sudo 執行

安裝結果如下：

[INFO]  using v1.24.8+rfor1 as release
[INFO]  downloading checksums at https://rfolabs.oss-cn-shenzhen.aliyuncs.com/rfo/releases/v1.24.8%2Brfor1/sha256sum-amd64.txt
[INFO]  downloading tarball at https://rfolabs.oss-cn-shenzhen.aliyuncs.com/rfo/releases/v1.24.8%2Brfor1/rfo.linux-amd64.tar.gz
[INFO]  verifying tarball
[INFO]  unpacking tarball file to /usr/local

2. 啟用 rfo-server 服務

systemctl enable rfo-server

3. 啟動 rfo-server 服務

systemctl start rfo-server.service

4. （可選）檢視 rfo-server 服務日誌

journalctl -u rfo-server -f

執行此安裝程式後：

  • rfo-server 服務將被安裝。rfo-server 服務將被配置為在節點重啟後或程式崩潰或被殺時自動重啟。
  • 其他的實用程式將被安裝在/var/lib/rancher/rfo/bin/。它們包括 kubectl, crictl, 和 ctr. 注意，這些預設不在你的路徑上。
  • 還有兩個清理指令碼會安裝到 /usr/local/bin/rfo 的路徑上。它們是 rfo-killall.sh和rfo-uninstall.sh。
  • 一個 kubeconfig 檔案將被寫入/etc/rancher/rfo/rfo.yaml。
  • 一個可用於註冊其他 server 或 agent 節點的令牌將在 /var/lib/rancher/rfo/server/node-token 檔案中建立。
注意：如果你要新增額外的 server 節點，則總數必須為奇數。需要奇數來維持選舉數。

安裝 Agent

1. 執行安裝程式

curl -sfL https://gitee.com/rfolabs/rfo/raw/rfo-master/install-rfo.sh | INSTALL_RFO_VERSION="v1.24.8+rfor1" INSTALL_RFO_TYPE="agent" sh -

2. 啟用 rfo-agent 服務

systemctl enable rfo-agent.service

3. 配置 rfo-agent 服務

mkdir -p /etc/rancher/rfo/
vim /etc/rancher/rfo/config.yaml

config.yaml 的內容。

server: https://<server>:9345
token: <token from server node>

其中 token 可以在 server 節點中執行 cat /var/lib/rancher/rfo/server/node-token 命令獲取。

rfo server 程式透過埠 9345 監聽新節點的註冊。正常情況下，Kubernetes API 仍可在埠 6443 上使用。

4. 啟動服務

systemctl start rfo-agent.service

5. （可選）檢視 rfo-agent 服務日誌

journalctl -u rfo-agent -f

訪問叢集

在安裝完成 rfo-server 節點後，即可以在 server 節點中使用內建的 kubectl 以及 kubeconfig 配置訪問叢集：

export KUBECONFIG=/etc/rancher/rfo/rfo.yml
export PATH=/var/lib/rancher/rfo/bin:$PATH
kubectl get pods --all-namespaces
helm ls --all-namespaces

或在指令中指定 kubeconfig 檔案位置：

kubectl --kubeconfig /etc/rancher/rfo/rfo.yml get pods --all-namespaces
helm --kubeconfig /etc/rancher/rfo/rfo.yml ls --all-namespaces

若希望在叢集外部訪問叢集，則可以複製 /etc/rancher/rfo/rfo.yml 配置檔案到你位於叢集外部的機器上，作為 ~/.kube/config。然後將檔案中 127.0.0.1 替換為你的 RFO 伺服器的 IP 或主機名。kubectl 現在可以管理你的 RFO 叢集了。

功能特點

精簡部署

RFO 基於 RKE2 進行重新打包製作而成，具有 RKE2 所有的功能特點，吸取了開發和維護輕量級 Kubernetes 發行版 K3s 的經驗教訓，並將其應用於構建一個具有 K3s 易用性的企業級發行版。這意味著，RFO 在最簡單的情況下是一個單一的二進位制檔案，需要在所有參與 Kubernetes 叢集的節點上安裝和配置。一旦啟動，RFO 就能夠引導和監督每個節點上的角色合適的 agent，同時從網路上獲取所需的內容。以下為 RFO 架構示意圖：

RFO系統架構

以下元件為 RFO 在專案中使用的 Kubernetes 元件，其中大部分經過重新打包並使用 openEuler base image 進行分發

在使用 install.sh 指令碼進行安裝時，rfo 將會以 linux system service 的方式安裝到系統中，使用 systemd 作為 RFO Supervisor。其餘方式（包括下載 rfo binary 直接啟動）並不推薦，某些場景下會沒有 RFO Supervisor 角色監控 RFO 執行狀態，導致 kubelet 等程式常駐後臺執行。

一般情況下，RFO 以安裝包的方式進行分發，安裝包中只包含 rfo 二進位制本體、systemd service 配置檔案以及解除安裝指令碼。其餘元件將在 RFO 啟動後，根據啟動節點的角色進行拉取並安裝啟動。

備份恢復

在 RFO 執行的時候，你可以使用 etcd-snapshot 子命令來進行 etcd 快照管理。功能包括：

  • 使用本地目錄或 s3 作為快照儲存後端
  • 對當前 etcd 資料建立快照
  • 對叢集進行重置並從快照中恢復資料到當前或新節點中
  • 定時備份

Helm 整合

RFO 內建 Helm Controller，它使用 HelmChart 自定義資源定義（CRD）來管理 Helm chart。

HelmChart 資源定義捕獲了你通常傳遞給helm命令列工具的大部分選項。下面是一個例子，說明你如何從預設的 chart 資源庫部署 Grafana，覆蓋一些預設的 chart 值。注意，HelmChart 資源本身在kube-system名稱空間中，但 chart 的資源將被部署到monitoring名稱空間。

apiVersion: helm.cattle.io/v1
kind: HelmChart
metadata:
  name: grafana
  namespace: kube-system
spec:
  chart: stable/grafana
  targetNamespace: monitoring
  set:
    adminPassword: "NotVerySafePassword"
  valuesContent: |-
    image:
      tag: master
    env:
      GF_EXPLORE_ENABLED: true
    adminUser: admin
    sidecar:
      datasources:
        enabled: true

另外 RFO 支援透過 HelmChartConfig 資源來自定義部署，允許覆蓋作為 HelmCharts 部署的打包元件（如 Canal、CoreDNS、Nginx-Ingress 等）的值。HelmChartConfig資源必須與其對應的 HelmChart 的名稱和名稱空間相匹配，並支援提供額外的valuesContent，作為一個額外的值檔案傳遞給helm命令。

注意：HelmChart spec.set 值覆蓋 HelmChart 和 HelmChartConfig spec.valuesContent設定。

例如對上文例子中的 Grafana helm chart 進行自定義 Grafana image 的 tag，可以建立一個 Kubernetes 資原始檔，並用以下內容填充它，並使用 kubectl apply -f <manifest filename> 進行應用：

apiVersion: helm.cattle.io/v1
kind: HelmChartConfig
metadata:
  name: grafana
  namespace: kube-system
spec:
  valuesContent: |-
    image:
      tag: 9.3.2

證照輪換

RFO 中的證照預設在 12 個月後到期。如果證照已經過期或剩餘時間少於 90 天，可以使用 certificate 子命令對證照進行輪換，當 RFO 重新啟動時，證照將被輪換。

systemctl stop rfo-server

你也可以透過傳遞 --service 標誌來輪換單個服務，例如：rfo certificate rotate --service api-server。

Secret 加密

RFO 支援透過子命令 secrets-encrypt 開啟對 Secret 進行靜態加密，開啟後會自動進行以下操作：

  • 生成一個 AES-CBC 金鑰
  • 用生成的金鑰生成一個加密配置檔案：
{
  "kind": "EncryptionConfiguration",
  "apiVersion": "apiserver.config.Kubernetes.io/v1",
  "resources":
    [
      {
        "resources": ["secrets"],
        "providers":
          [
            {
              "aescbc":
                {
                  "keys":
                    [{ "name": "aescbckey", "secret": "xxxxxxxxxxxxxxxxxxx" }],
                },
            },
            { "identity": {} },
          ],
      },
    ],
}
  • 將該配置作為 encryption-provider-config 傳遞給 Kubernetes APIServer

一旦啟用，任何建立的 secret 都將用這個金鑰進行加密。請注意，如果你禁用加密，那麼任何加密的 secret 將無法讀取，直到你使用相同的金鑰再次啟用加密。

安全可信

RFO 設計上與 Openeuler 緊密結合，在安全合規性上與 Openeuler 系統一致；並在持續整合流水線中，基於 Openeuler 容器映象執行 sonobuoy 測試，保證 RFO 發行版相容 CNCF 認證的 Kubernetes 發行版功能要求。

維護原則與釋出週期

RFO 的維護與釋出週期與 RKE2 以及 Kubernetes 版本生命週期一致，並遵循以下原則：

  • RKE2 小版本將會根據改動內容，在 RKE2 release 後一週內進行跟進；如出現的改動與 RFO 無關，則跳過小版本釋出
  • RKE2 大版本目前會跟進 Kubernetes 大版本進行維護，在 RKE2 release 後兩週內進行跟進

針對 openEuler OS 的更新，遵循以下原則：

  • 只針對 openEuler LTS(long term support)版本釋出對應的 RFO 版本，目前經驗為 2 年一個新 LTS 版本，在新版本釋出後 RFO 會在最近一個 RFO Release 進行跟進
  • 當 openEuler 出現致命或高等級系統漏洞的情況下，釋出 RFO 小版本進行跟進

RFO 除 RKE2 原生的功能外，目前以測試整合 openEuler 作業系統為目標進行維護，並計劃後續新增以下支援：

  • ARM64 平臺支援
  • 內建 iSula 執行時支援

後續規劃

後續規劃主要圍繞構建物安全可信認證以及擴充構建物分發途徑開展。

構建物安全可信認證主要包括以下方面，確保核心元件的分發產物不可篡改，並致力於提供等保加固的 Kubernetes 叢集環境：

  • 針對分發的容器映象，進行映象簽名
  • 針對分發的 RFO charts，進行 helm charts 簽名

擴充構建物分發途徑主要包括以下方面：

  • 支援離線映象製作以及離線部署
  • 構建 RFO 以及 kube-explorer RPM 包並透過 openEuler 的軟體源進行分發

相關文章